Source Key
What It Is
A source key is how a producing system identifies a record it sends to Rhythm. The producer might know a membership number or an identifier from the customer’s previous system, while Rhythm has a different destination identity. The mapping between them allows later work to ask which destination record belongs to the producer’s input rather than guessing from a name or address.
That mapping is scoped to the workspace, producer and record kind. It retains the destination record and evidence about the producer’s applied delivery. Repeated input can therefore be interpreted according to the requested operation and revision. The same visible key from another producer does not automatically identify the same record.
This concept is broader than a column on an import form. It supports recurring delivery, dependency resolution, correction and reconciliation across several jobs. Staff do not normally maintain the mapping as a catalogue; they encounter it through those tasks.
What It Is Not
A producer key is not a Rhythm display number, and it is not inherently the record’s stored external identifier. Imports can default that external identifier from the key, but the mapping and record value remain distinct. Nor is a mapping a duplicate-detection judgment. A different key can identify a new destination record even when Product would consider it another representation of the same person.
How It Is Used
Integrations provide keys in their input and use supported lookups to inspect the resulting records. Implementation staff use keyed references when datasets depend on records loaded elsewhere in a package. Administrators encounter the same identity model in file-based insert, upsert and update work.
Good use establishes a stable producer namespace and revision convention before recurring delivery begins. Insert, whole-record replacement and patching have different repeat-input behavior. Treating them as identical can hide an intended update or replace information unexpectedly. Staff also need to decide whether the producer may overwrite local corrections rather than allowing the delivery tool to make that authority choice implicitly.
Its Facets
Producer identity. The source-system namespace distinguishes independent feeds and keeps similar keys from accidentally sharing a mapping.
Delivery revision. Revision tokens help determine whether input is old or repeated. Their ordering must match the producer’s intended sequence; opaque text does not necessarily sort like numbered versions.
Replacement policy. This records whether recurring input should protect a later staff correction or permit the producer to replace it. Explicit expected versions can provide a sharper condition for a particular write.
Producer-written version. The mapping remembers the destination version associated with the producer’s write, providing context for later concurrency checks.
Keyed references. Records can describe parents, organizations and other dependencies using identities the producer already knows. Missing references explain blocked input rather than requiring fabricated destination identifiers.
How It Relates
Data jobs use mappings during keyed processing. Successful creation retains the mapping with its record, while rejected creation leaves the producer identity available for correction. Reconciliation reads the current destination record rather than reconstructing an immutable import snapshot. Reset clears loaded mappings; deletion and supported merge behavior affect their destinations.
What It Could Become
Product still needs to decide how new-key imports participate in duplicate detection. Membership also needs executable mapping infrastructure before its declared operations can load structure. Clearer revision and overwrite-policy guidance would help integrations reconcile deliveries without relying on assumptions about identity or ordering.