fc.api.fulfilment.uniqueness (ongoing release)
Setting
Changed on:
17 July 2026
| Setting Area | Workflow, Orders |
|---|---|
| Supported context levels: | ACCOUNT |
Overview
The`fc.api.fulfilment.uniqueness` setting controls how the platform assigns a unique reference to each fulfillment at creation.The platform validates the assigned unique reference against its uniqueness constraint. Depending on the configured value, the platform generates it using one of the following strategies:- random UUID
- deterministic hash
- fulfillment reference (
`ref`)
Values
| Data Type | Values |
|---|---|
| STRING | Default Value:
|
Detailed technical description
Unique Reference Assignment
When a fulfillment entity is created, its unique reference is populated according to the value of the`fc.api.fulfilment.uniqueness` setting. It evaluates the stored value in this order:`REF_ONLY`- if the value matches`REF_ONLY`(case-insensitive), the fulfillment's`ref`is copied to unique reference`DISABLED`- if the value is`null`,`DISABLED`, or any unrecognized string, a random UUID is assigned`ENABLED`- the system computes a deterministic hash from:`order.id`,`fromLocation.id`,`shipmentType`,`deliveryType`, destination address fields (`name`,`street`,`city`,`state`,`country`,`postcode`,`type`), and each fulfillment item's`orderItem.id`and`requestedQuantity`(sorted by`orderItem.id`).
If`fromLocation`,`toLocation`, or fulfillment items are absent, a random UUID is used instead
Fulfillment Deduplication
The platform always validates the assigned unique reference against its uniqueness constraint.Whether duplicate fulfillment creation is prevented depends on how the unique reference is generated:`DISABLED`assigns a random UUID, so every fulfillment receives a different unique reference`ENABLED`assigns a deterministic hash, so equivalent fulfillments receive the same unique reference`REF_ONLY`uses the fulfillment reference as the unique reference, so fulfillment creation attempts with the same reference receive the same unique reference
Explanation trough a Re-Sourcing Example
When two concurrent re-sourcing attempts start from the same loaded order state, the reference Order Module workflow assigns fulfillment references using a deterministic, index-based scheme. Both attempts compute identical`ref` values for the new fulfillments. With `REF_ONLY` configured, those references are copied to the unique reference. The uniqueness constraint then rejects the second attempt - no duplicate fulfillments are created and no additional inventory is reserved.Per-Entity Opt-Out
When the setting is`ENABLED`, individual fulfillments can bypass the hash-based check by setting the `ENABLE_DUPLICATE_ENTITY` attribute to `TRUE` in the fulfillment's attributes JSON array. Each element in the array must have a `name` field and a `value` field. When the system finds an element where `name` equals `ENABLE_DUPLICATE_ENTITY` and `value` parses as `true`, a random UUID is assigned for that fulfillment and the deterministic hash is skipped.Configuration example
1POST {{fluentApiHost}}/graphql
2
3mutation CreateSetting {
4 createSetting(input: {
5 name: "fc.api.fulfilment.uniqueness",
6 valueType: "STRING",
7 value: "REF_ONLY",
8 context: "ACCOUNT",
9 contextId: 0}) {
10 id
11 name
12 }
13}Update example
1POST {{fluentApiHost}}/graphql
2
3mutation updateSetting {
4 updateSetting(input: {
5 id: 5001464,
6 name: "fc.api.fulfilment.uniqueness",
7 valueType: "STRING",
8 value:"DISABLED",
9 context: "ACCOUNT",
10 contextId: 0}) {
11 id
12 name
13 }
14}