DocumentationExperience Cloud KCS

Campaign: proposition synchronisation in interaction distributed architecture

Last update: September 8, 2026

In a distributed Adobe Campaign Interaction architecture, the Marketing or control instance manages the offer catalog, while one or more dedicated Interaction execution instances process inbound interactions and generate offer propositions.

Because propositions are generated on the execution instances, the resulting nms:propositionRcp records must be synchronized back to the control instance. The synchronization is performed by the OOTB propositionSynch workflow, which creates direction-specific technical workflows. These workflows use instance-specific proposition-ID ranges and date-based checkpoints to transfer only the relevant records.

This article explains the synchronization process, workflow structure, configuration options, proposition-ID offset calculation and checkpoint logic.

Description description

The distributed Interaction architecture has three logically separate processes:

Offer catalog deployment

  • The control instance owns the design-time offer catalog.
  • The offerMgt workflow deploys approved offers, offer spaces, and live environments to the execution instances.

Proposition generation

  • An inbound interaction is routed to an execution instance, commonly through a load balancer.
  • The execution instance evaluates eligibility rules and generates the proposition.
  • The proposition is written asynchronously to nms:propositionRcp by the Interaction runtime.

Proposition synchronization

  • The propositionSynch workflow creates technical workflows that copy proposition data between the control and execution instances.
  • Synchronization uses an FDA or execution-instance external account.
  • The technical workflows filter data using both:
  • The proposition-ID range assigned to the relevant execution instance.
  • A lastModified time window.

The offerMgt workflow and the proposition synchronization workflows are therefore complementary but different: offerMgt distributes the offer catalog, while propositionSynch distributes proposition history and status data.

  1. The propositionSynch orchestration workflow

The main propositionSynch workflow does not necessarily perform the entire data copy itself. Its role is to:

  • Read the configured execution-instance external accounts.
  • Determine the source and target instances.
  • Create or trigger the technical proposition-copy workflows. Their labels will be “Copy of ‘nms:propositionRcp’ from marketing instance to ‘EXT**’.” and “Copy of ‘nms:propositionRcp’ from instance ‘EXT**’ to marketing instance.” (EXT** being the internalName of the external account used to connect to the interaction execution instance).
  • Store the generated workflow identifiers in the option NmsInteraction_SynchWorkflowIds.
  • The workflow names are generated from source, target, and proposition schema information. A typical mapping would be for example:

{
  “wkf_0_95501_nms:propositionRcp”: 111401,
  “wkf_95501_nms:propositionRcp”: 111403
}

The values 111401 and 111403 are the primary keys of the technical workflows.

A successful execution of the main propositionSynch workflow does not guarantee that propositions were synchronized. The generated child workflows must also be inspected because the child workflow may:

  • Return no records due to an incorrect proposition-ID range.
  • Fail because of an incompatible schema.
  • Fail while parsing the synchronization date range.
  • Fail because the external account or database permissions are incorrect.
  1. Execution-to-control synchronization

This path retrieves propositions generated by an execution instance and writes or updates them on the control instance.

The query normally filters on:

  • Non-zero proposition ID.
  • The proposition-ID range assigned to the execution instance.
  • The lastModified date range.
  • The relevant offer, offer-space, environment, and proposition fields.
  • A simplified form of the filter is:

WHERE propositionId < > 0
  AND propositionId > = CELL_OFFSET * executionInstanceId
  AND propositionId < CELL_OFFSET * (executionInstanceId + 1)
  AND lastModified > = synchronizationStart
  AND lastModified < synchronizationEnd


3. Control-to-execution synchronization

The reverse path copies applicable proposition data from the control instance to an execution instance.

Depending on the workflow and schema configuration, this path may additionally filter by:

  • The source instance identifier.
  • The target execution instance.
  • The offer environment or internal-name prefix.
  • The relevant execution-instance identifier.

Proposition-ID Offset Counting

Offset formula

In a distributed Interaction deployment, the proposition ID is partitioned by execution instance.

The documented formula is:

Proposition ID =
    CELL_OFFSET * Execution Instance ID
    + PROP_ID_IN_APIs

The standard value used by the synchronization workflow is:

CELL_OFFSET = 72057594037927936

This value is equal to 256.

PROP_ID_IN_APIs represents the local proposition identifier generated for the individual interaction or Propose API call. The execution-instance identifier determines the larger ID range in which that proposition is stored.

The execution-instance identifier is therefore a partition or slot identifier, not a count of propositions.

Partition ranges
The workflow uses a half-open interval:

CELL_OFFSET * instanceId
    < = propositionId
    < CELL_OFFSET * (instanceId + 1)

For example, execution instance 3 owns the range:

Start: 72057594037927936 * 3
     = 216172782113783808

End:   72057594037927936 * 4
     = 288230376151711744

A proposition with local ID 1056 generated on execution instance 3 would therefore have an expected ID of:

(72057594037927936 * 3) + 1056
= 216172782113784864

Another example from the internal provisioning material is:

(72057594037927936 * 2) + 1090
= 144115188075856962

The synchronization workflow excludes proposition ID 0 and retrieves only records that fall inside the selected execution-instance range.

Why an incorrect instance ID prevents synchronization

The value of NmsExecutionInstanceId must match the execution-instance identifier configured in the corresponding external account. This option may not be visible in the Client Console so if you don’t have it please reach out to Adobe Support to have it checked directly in the database.

If the option is empty or contains an incorrect value, the Propositions will be therefore generated with small IDs instead of IDs in the range beginning at CELL_OFFSET * X. The synchronization workflow will correctly search the range for the given interaction instance, but the generated propositions will be outside that range. The workflow can run successfully while returning no proposition rows.

Resolution resolution

Resolution for incorrect proposition-ID ranges

Use the following procedure when propositions are generated but are not retrieved by the synchronization workflow:

  1. Identify the execution instance that generated the proposition.

  2. Read the execution-instance identifier from the corresponding external account.

  3. Verify that NmsExecutionInstanceId on the execution instance has the same value.

  4. Calculate the expected proposition-ID range:

lowerBound = CELL_OFFSET * executionInstanceId
upperBound = CELL_OFFSET * (executionInstanceId + 1)
Inspect a recently generated proposition ID.

  1. Confirm that the ID satisfies:

lowerBound < = propositionId < upperBound

  1. If the option is missing or incorrect, reach out to Adobe Support.

  2. Re-run the relevant technical synchronization workflow.

  3. Confirm that the proposition is now selected and written to the control instance.

recommendation-more-help
experience-cloud-kcs-help-kbarticles