Private ReadonlybundledBundled definitions used when the consuming application has not loaded the definitions into its own store.
Private ReadonlydefaultBuilt-in matching key defaults for objects that require a specific key configuration, keyed by normalized (lower case, namespace-less) SObject type. An empty array marks the object as key-less causing records to always be inserted.
Private ReadonlyexportPrivateextraExtra matching key files registered through setMatchingKeyFiles.
Private OptionalfileMatching keys loaded from matchingKeyFiles; reset when new files are registered.
Private ReadonlyfsPrivate ReadonlyloggerPrivate ReadonlyresolvedResolved matching keys by normalized SObject type, selected definition scope and schema-fallback behavior.
Private ReadonlysalesforceStatic ReadonlydefaultDefault matching key files loaded from the working directory when present.
PrivateorgPrivategetGet the matching key fields configured for an object checking each source in order of precedence: matching key files, consumer export definitions, org matching keys, built-in defaults and finally bundled export definitions.
Optionalscope: stringThe configured fields or undefined when no source defines a key for the object
PrivategetDetermine the matching key fields for an object without matching key configuration:
a required unique field, the DeveloperName field or the object's name field.
PrivategetPrivategetGet the master-detail relationship fields of an object. Custom master-detail fields report a
relationshipOrder; standard master-detail-like relationships are required cascade-delete lookups.
Get the matching key for the specified SObject type. Resolution is cached per object and selected export-definition scope and schema-fallback behavior.
Fields configured through one of the matching key sources are validated against the object describe and returned using their API name; configuring a field that does not exist on the object is an error. Master-detail relationship fields of the object are always part of the returned matching key.
SObject type with or without (placeholder) namespace prefix
Optionalcontext: MatchingKeyContextOptional export-definition scope and schema-fallback behavior
The matching key for the object; fields is empty for key-less objects, either
explicitly configured as such or because no matching key could be determined.
Pre-loads the matching keys from the org and the registered matching key files so subsequent matching key resolutions do not require additional callouts. Idempotent; safe to call multiple times.
PrivateisPrivateloadPrivateloadPrivatequeryPrivateresolveOptionalcontext: MatchingKeyContextSet the matching key files to load in addition to the default matching-keys file in the
working directory. Files are JSON or YAML objects mapping an SObject type to an array of
matching key field names:
Product2: [ ProductCode ]
"%vlocity_namespace%__PriceList__c": [ Name ]
Matching keys from files take precedence over keys defined in export definitions and in the org; entries in later files override earlier files. Replaces previously set files and resets already resolved matching keys so new resolutions reflect the specified files.
Paths of the matching key files to load
PrivatevalidateValidate that each of the configured matching key fields exists on the object and resolve them to their proper API names.
PrivatevalidateValidate the fields of a matching key loaded from the org dropping fields that do not exist or are not accessible. Unlike configured matching keys org matching keys are not treated as an error when invalid as they are managed in the org and may reference fields the current user cannot access.
Central service that manages matching key fields for SObject types. Matching keys determine which fields uniquely identify a record and are used for looking up existing records during deployment (upsert fields), for generating datapack source keys during export and for building export queries.
Matching keys are loaded from the following sources; the first source that defines a key for an object wins:
matching-keys.json/.yamlby default, see setMatchingKeyFiles)matchingKeyFieldsorautoGeneratedMatchingKey)DRMatchingKey__mdtrecordsWhen no source defines a key the service falls back to a required unique field, the
DeveloperNamefield or the object's name field. Objects that link to a parent through a master-detail relationship always include the relationship field(s) in their matching key so child records are matched within their parent. When no matching key can be determined at all the object is treated as key-less: records are always inserted on deployment and exported with generated source keys. Top-level datapacks require a matching key which is enforced by the deployment and export flows.