FSM Notification Processing Lifecycle

Field Service Management (FSM) processes requested notifications in the background. For report preview, prerequisites, and record relationships, see FSM Service Reports and Notifications.

The Field Service Scheduled : Notification deployment (customdeploy_nx_notification) processes requested notifications. Record handlers request execution when pending requests are saved and when notification records are created. A request field indicates outstanding work, not that an execution is currently running.

The following table describes processing stages and their recorded evidence.

Stage	Processing Action	Evidence and Interpretation
Request accepted	A manual action or matching automatic rule adds a pending request to the source record.	Event Pending Notifications (`custevent_nx_notification_pending`) holds service-record requests. Employees use `custentity_nx_notification_pending`.
Request represented	Processing creates a field service notification record for each newly queued request. After the pending requests have corresponding records, processing clears the source field.	An empty pending field can precede sending. It does not prove that notification processing succeeded.
Email processing	Processing selects notification records without a linked message, resolves the current definition and source data, and generates the email and attachments.	An unlinked notification is outstanding processing. It is not a record-level running indicator.
Sent message linked	FSM sends the email, or finds a recent message for the same request, and links that message to the notification.	A link to a sent message record is evidence of the send operation. It does not prove receipt or reading.

Stage

Processing Action

Evidence and Interpretation

Request accepted

A manual action or matching automatic rule adds a pending request to the source record.

Event Pending Notifications (custevent_nx_notification_pending) holds service-record requests. Employees use custentity_nx_notification_pending.

Request represented

Processing creates a field service notification record for each newly queued request. After the pending requests have corresponding records, processing clears the source field.

An empty pending field can precede sending. It does not prove that notification processing succeeded.

Email processing

Processing selects notification records without a linked message, resolves the current definition and source data, and generates the email and attachments.

An unlinked notification is outstanding processing. It is not a record-level running indicator.

Sent message linked

FSM sends the email, or finds a recent message for the same request, and links that message to the notification.

A link to a sent message record is evidence of the send operation. It does not prove receipt or reading.

Before sending, FSM checks recent messages for the same request identifier. This check can prevent a repeat send of that request. It is not a one-email-per-record rule: separate requests can send separate emails for the same case or task. See FSM Notification Configuration for the lookback setting and its limits.

Where a record displays Sending Notification, the indicator reports outstanding notification work. It can remain when an action is blocked and does not prove that an email message is currently being sent.

If the source case, task, project task, or employee no longer exists, processing does not send its notification. It records Message ID 0 to stop that request being selected as unlinked work. This value is not a sent message.

Errors and Outstanding Work

Preview generation, queue submission, and background sending can fail independently. Missing email definitions, inaccessible template or attachment files, incompatible template data, PDF rendering errors, and invalid addressing can prevent the affected operation from completing.

If the native button's queue request fails, it displays the configured error message. A request accepted earlier can still fail during later email processing.

Scheduled failures can create field service error records. A matching active, unrecovered error blocks the corresponding notification action in later executions. The standard notification actions do not specify a delayed automatic retry. Other eligible notifications can continue. For shared execution status and error handling, see FSM Script Reference. For error fields and state meanings, see FSM Error Record.

Sending and linking are separate steps. An email message may already have been sent when the subsequent message lookup or link fails. A missing message link therefore does not establish that the email was never sent. The same-request duplicate check can find the earlier message if that request is processed again.

Errors and Outstanding Work

Related Topics