TOOLS. SYSTEMS. BETTER DECISIONS.
Stack & Method
HomeData and integrations
Subject guide

Data and integrations

Moving records is a mapping problem before it becomes a scheduling problem. Define field ownership and what happens when records disagree.

A notebook beside blue data-ownership and progress cards.
Original editorial scene in the Stack & Method setting. Generated imagery; not evidence of product or recipe testing.

Choose stable identities before mapping fields

Write down the source identifier, destination identifier and how the pair is retained. A display title or email address can change and may not be unique. If no reliable identity exists, make that a design problem to resolve rather than compensating with a loose text match. Record the publication or tenant boundary alongside the identity when multiple destinations use the same integration.

Assign ownership one field at a time

A source system need not own every field on a destination record. Decide which fields are copied, calculated, locally edited or intentionally omitted. State what an empty value means: unknown, clear the field, or leave the destination unchanged. Keep that decision separate from deletion. A mapping table should make a conflict visible before a scheduled job overwrites someone’s work.

An illustrative article field map
FieldAuthority and write rule
Article IDSource identity; retained in the destination mapping.
Approved bodyCopy only the approved source revision.
Local campaign noteDestination-owned; leave unchanged.
Canonical pathApply the publication’s agreed URL rules.

Retain progress through a partial batch

Define a checkpoint at a unit that can be explained and reconciled. If record three fails after the first two succeed, the recovery process needs to recognize those completed writes. A batch-level success flag is not enough to describe mixed results. Keep failed and unknown states distinct, and retain the source revision that produced each destination change.

Reconcile before declaring the systems aligned

Compare the fields the integration actually owns against a known source revision. Account for intended transformations instead of comparing raw objects blindly. An HTTP success or a matching record count does not prove that the mapped fields are correct. Decide how to surface discrepancies and who may resolve them; a reconciliation report should not silently choose new business values.

Keep these details together.

  • Identifiers and field mappings
  • Deletion and merge rules
  • Reconciliation after partial failure

Go a little deeper.

Workflow Library ↗
Data and integrations: Choose stable identities before mapping fields; Assign ownership one field at a time; Retain progress through a partial batch
READ THE DETAILS

Keep going with data and integrations

Questions to start with

How to handle webhook retries?

Keep a stable event or work identifier and record what happened on the first attempt. Distinguish a confirmed rejection from an unknown result after a timeout. Check the receiving service’s documented idempotency behavior before sending another write. A retry should reconcile with the original work, not silently create a second copy.

Stripe: provider-specific idempotent requests ↗

All guides · All questions