FSM Mobile Sync Now Uses External ID for Idempotency Keys

What changed

FSM mobile sync now uses the native External ID field on NetSuite records to store its idempotency key, replacing the previous approach of custom idempotency fields. As of FSM version 2026.05.2, the old custom idempotency fields are no longer populated.

A new custom record type, customrecord_nx_idempotency (Field Service Idempotency), tracks in-flight requests. The lifecycle works as follows:

1. Before creating or updating a record, FSM checks customrecord_nx_idempotency for an active entry matching the request's idempotency key.
2. If an active (unexpired) match exists, FSM rejects the request with error ARTICLE_SYNC_PENDING. The mobile app retries after the 60-second pending window expires.
3. If the matching record is expired (>60 seconds old), FSM deletes it and retries the operation.
4. If no match is found, FSM creates a new idempotency record and proceeds with the create/update. The same key is written to the target record's External ID field, prefixed with fsm_.
5. Idempotency records in customrecord_nx_idempotency are purged after 24 hours.

This runs automatically on all mobile tabs that create records, including custom tabs. No configuration is required.

Why this matters

The External ID field is commonly used by integrations (SuiteTalk, CSV imports, SuiteScript N/record with type: record.SubmitConfig) to deduplicate or upsert records. FSM now writes values prefixed with fsm_ into this field on every record it creates or updates via mobile sync. If your integration or script also sets External ID on the same record types FSM manages (work orders, service tasks, time entries, etc.), you may encounter conflicts or unexpected overwrites.

What to do

1. Audit External ID usage. Search your integration maps, CSV imports, and SuiteScript code for any logic that reads or writes the External ID on record types FSM creates during mobile sync. Look for setValue({fieldId: 'externalid', ...}) or SOAP/REST upsert calls keyed on externalId.
2. Check for collisions. If your integrations set External ID on the same records, verify that FSM's fsm_-prefixed values won't conflict. Consider whether you need to move your integration key to a custom field or coordinate with the FSM prefix.
3. Remove references to old custom idempotency fields. If you built any scripts, workflows, or saved searches that reference the legacy custom idempotency fields, update or remove them—FSM no longer populates those fields as of version 2026.05.2.
4. Review saved searches on customrecord_nx_idempotency. The record is self-cleaning (24-hour TTL), but if you need visibility into sync issues, you can search this record for ARTICLE_SYNC_PENDING patterns or monitor idempotency key volume.
5. Test mobile sync in Sandbox. Push a Sandbox refresh and verify that FSM mobile sync creates records without duplicates and that your integrations still populate External ID as expected on shared record types.

Open questions

The documentation does not specify exactly which standard record types FSM writes External ID values to during sync. If you run FSM with heavy integration traffic, inspect a few recently synced records in your Sandbox to confirm which types carry the fsm_ prefix before relying on External ID for upserts.