FSM Mobile Duplicate Creation Protection

Idempotency in Field Service Management (FSM) helps prevent duplicate NetSuite record creation from repeated FSM Mobile requests. FSM Mobile uses an idempotency key, a unique identifier for an entry, to identify requests for that entry. These requests include retries after interrupted synchronization and overlapping creation requests.

How It Works

FSM protects record creation in two stages. A temporary reservation controls overlapping requests with the same key. The FSM identity stored in External ID lets standard record synchronization recognize an earlier creation.

Reserve the Creation Request

When you save an entry for the first time, FSM Mobile generates an idempotency key and saves the entry locally. The key identifies the entry and accompanies its creation request to NetSuite.

Before processing the creation request, FSM creates a temporary field service idempotency record to reserve the key. An active reservation blocks an additional creation request with the same key.

The reservation initially expires after 60 seconds. FSM releases the reservation by expiring it when request processing finishes. A later creation request can replace an expired reservation. The 60-second expiration applies to the temporary reservation, not to the key stored in the target record's External ID field.

The following panels show alternative reservation outcomes for requests using the same entry's key:

FSM reserves an available key or rejects a request when an active reservation exists for that key.

Create or Update the Target Record

For records that use standard record synchronization, FSM stores the key in the target record's External ID field with the fsm_ prefix. If a later creation request finds a record of the same type with that key, FSM updates that record with the submitted values. FSM does not create another record.

The following flows show successful synchronization after the request reserves its key. The panels compare creating a target record when no matching record exists with updating a matching existing record.

After reserving the key, FSM creates a target record or updates a matching record, then returns its NetSuite record ID.

The following table describes how standard record synchronization handles repeated creation requests.

Request Condition	FSM Behavior
An active reservation exists for the same key.	FSM rejects the additional creation request with the `ARTICLE_SYNC_PENDING` error and returns the reservation expiration.
No active reservation exists, and a record of the same type already has the key.	FSM updates the existing record with the submitted values.
No active reservation exists, and no record of the same type has the key.	FSM creates a record with the key in its External ID field.

Request Condition

FSM Behavior

An active reservation exists for the same key.

FSM rejects the additional creation request with the ARTICLE_SYNC_PENDING error and returns the reservation expiration.

No active reservation exists, and a record of the same type already has the key.

FSM updates the existing record with the submitted values.

No active reservation exists, and no record of the same type has the key.

FSM creates a record with the key in its External ID field.

The field service idempotency record stores the temporary reservation. Its existence alone does not establish that the target record was created successfully. After successful synchronization, FSM Mobile uses the NetSuite record ID returned in the response.

The Field Service Scheduled : Idempotency deployment (customdeploy_nx_idempotency) removes expired field service idempotency records. For shared execution details and monitoring, see FSM Script Reference.

Limitations and Constraints

Duplicate creation protection depends on the request's key and the resource's creation and synchronization behavior.

Scope of Duplicate Creation Protection

The standard FSM Mobile resource endpoint reserves the key automatically when a creation request includes an idempotency key. Matching an earlier target record by External ID also depends on the resource using standard record synchronization.

Protection is based on the key, not on matching field values. Separately created entries receive separate keys, even when the entries contain the same values.

Custom tab coverage depends on the creation request and the server synchronization behavior used by the resource. A custom tab's label or record type alone does not establish equivalent protection.

Configuration

This section describes the configuration and identity dependencies and the changes to idempotency fields.

Configuration and Identity Dependencies

Duplicate creation protection is automatic for requests that meet the conditions in Scope of Duplicate Creation Protection. Standard record synchronization does not require a separate custom idempotency field or an idempotencyField setting.

Matching repeated creation requests depends on retaining the FSM identity stored in the target record's External ID field. If a customization replaces or removes that identity, a later creation request may no longer recognize the earlier record.

For FSM Mobile resource definitions, permissions, and field mappings, see FSM Mobile Resource Properties Reference. Custom resource coverage remains subject to the creation and synchronization conditions in the Scope of Duplicate Creation Protection section.

Idempotency Field Changes

As of FSM version 2026.05.2, standard FSM Mobile record creation uses the native External ID field instead of the old custom idempotency fields. This behavior applies regardless of when the NetSuite account was created. The old custom fields remain in the FSM SuiteApp for compatibility and visibility.