FSM Case and CRM Task Status Automation
Field Service Management (FSM) manages the Status (status) field on cases and customer relationship management (CRM) tasks. Configured rules determine when FSM opens or closes a related case and which case status to apply.
This topic covers cases and CRM tasks. It does not describe project task or project status automation. For information about the records, see FSM Case Record and FSM CRM Task Record.
How It Works
Start and Complete capture the current date and time in different task fields: Field Service Start (custevent_nx_task_start) and Field Service End (custevent_nx_task_end). Both fields store a date and time with a time zone. FSM Mobile saves the timestamps locally and sends the saved values to NetSuite during synchronization. When a confirmation dialog is displayed, the task timestamp is captured when the action is confirmed. The entered service-activity time is saved separately and can differ from that timestamp.
The Track Service Time feature controls whether FSM Mobile displays a service-time confirmation dialog. For the task to wait for time processing before reaching Completed status in NetSuite, its Task Type (custevent_nx_task_type) must also have a Service Time Item (custrecord_nx_task_type_time_service).
The Start and Complete flows in this topic show normal progression from Not Started to In Progress to Completed. The case-review steps assume a related case eligible for status processing. See How Status Updates Work for the request and eligibility details, and Changing Task Status Back for restarting a task.
Start Flows
Start changes a Not Started task to In Progress during synchronization. With Track Service Time enabled, the confirmation dialog also records a service-activity start.
Both flows synchronize Field Service Start, change a Not Started task to In Progress, and request related case review.
The following diagram compares the Start flows with Track Service Time disabled and enabled:
The enabled Start flow applies with or without a Service Time Item on the Task Type. Starting the task does not wait for scheduled time processing.
Complete Flows
The three paths distinguish direct completion from completion that waits for time processing. With Track Service Time enabled, the confirmation dialog and service-activity entry still apply when the Service Time Item is missing.
When both the feature and Service Time Item apply, synchronization checks Field Service Log Activity Time (custevent_nx_time_log_activities) to request time processing. Its effect on scheduled completion is described under Task Completion Eligibility.
With time tracking disabled, completion occurs during synchronization. With time tracking enabled and a Service Time Item, completion waits for time processing followed by status processing. With time tracking enabled and no Service Time Item, completion occurs during synchronization.
The following diagram compares the three Complete flows:
FSM Mobile shows completion from the locally captured timestamp. This can precede the NetSuite Completed status, particularly in the path that requires time processing. Completion of that path does not by itself establish that a time record was created. Time-record creation also depends on the service-activity data. See FSM Service Time Tracking.
After a task status change, the related case is reviewed according to Case Status Rules in this topic.
Key Behaviors
This section describes how the feature responds to different conditions and actions.
Changing Task Status Back
Changing a task's Status alone leaves its actual start and end timestamps in place. Those values still drive the FSM Mobile display and subsequent status updates. When restarting a task, the retained timestamps must match the intended state.
The following table describes timestamp changes and the effects of retained values.
|
Intended Task Status |
Timestamp Changes |
Retained Timestamp Effects |
|---|---|---|
|
In Progress after completion |
Clear Field Service End. Retain Field Service Start if the task should remain started. |
Status processing sets an In Progress task back to Completed when its end timestamp is populated and Field Service Log Activity Time is cleared. |
|
Not Started |
Clear both Field Service Start and Field Service End. |
A later FSM Mobile synchronization that submits a retained start timestamp can change a Not Started task to In Progress. FSM evaluates a retained end timestamp first. That timestamp can instead complete a task that does not qualify for Track Service Time. |
If the Field Service Log Activity Time box is still checked, the task can remain In Progress until time processing clears it. With a retained end timestamp, it then qualifies for completion again. See Task Completion Eligibility for the full scheduled check.
The changes occur when the relevant synchronization or scheduled processing runs. The scheduled status processor does not change a Not Started task to In Progress solely because its Field Service Start field is populated. That start transition occurs in the FSM Mobile synchronization path.
Clearing task timestamps does not reverse existing time records or earlier case updates. The related case remains subject to Case Status Rules in this topic. Verify the task's timestamps and NetSuite status after synchronization and outstanding processing.
Case Status Rules
For automatic opening, not started means that the case's current status is in the configured list of case status IDs. The core list contains 1, the standard NetSuite Not Started status. You can configure the list to include one or more account statuses.
With the core rules and standard NetSuite case statuses, FSM changes a Not Started case (1) to In Progress (2) when a related CRM task is In Progress.
A task closing formula is evaluated against a completed CRM task and returns the case status ID to apply to its related case. The task remains Completed. The default formula returns Closed (5) when the task's Close Case (custevent_nx_case_closed) box is checked. Otherwise, it returns no status and that task does not qualify for this closing rule.
Automatic case closure after all related tasks are complete is disabled by default. For exact settings, formula definitions, and setup choices, see Configuring FSM Case and CRM Task Status Automation.
The following table summarizes the conditions and results of each case status rule.
|
Rule |
Conditions |
Result |
|---|---|---|
|
Automatic case opening |
The current case status is in the configured not-started list, a related task is In Progress, and the case opening formula returns a case status ID. |
Sets the case status to the ID returned by the case opening formula. |
|
Case closure from a completed task |
A completed task's closing formula returns a case status ID. Other related tasks can remain incomplete. |
Sets the case status to the formula result from the selected completed task. |
|
Automatic case closure |
At least one related task is Completed, no related task is Not Started or In Progress, and the case closing formula returns a case status ID. |
Sets the case status to the ID returned by the case closing formula. |
FSM evaluates automatic case opening first. If the opening rule doesn't apply and the case's Stage (stage) isn't Closed, FSM evaluates the closing rules. Closure from a completed task takes precedence over automatic case closure. If no rule applies, the case status stays unchanged.
The rules use case status internal IDs. Account status names and IDs can differ from the standard NetSuite values. Verify that the configured rules refer to the intended account statuses. For the standard status mapping, see Support Case.
A case with no related tasks doesn't qualify for automatic case closure.
Case End Date and Time
When a closing rule applies, FSM updates the case's Field Service End Date (custevent_nx_end_date) and Field Service End Time (custevent_nx_end_time) fields using the selected task.
FSM uses the selected task's Field Service End date and time. If that value is empty, it uses the task's scheduled end date and time (enddate).
FSM orders related tasks by Start Date (startdate), with the latest start date first. It selects a task according to the closing rule:
-
Case closure from a completed task - Selects the first completed task in that order whose task closing formula returns a case status ID.
-
Automatic case closure - Selects the first completed task in that order.
FSM converts the selected date and time to the case's Field Service Time Zone (custevent_nx_time_zone) if processing uses a different time zone.
Processing Model and Lifecycle
This section explains when processing occurs and what can affect its progress and results.
How Status Updates Work
Scheduled processing completes eligible tasks and evaluates case status requests.
The Update Status (custevent_nx_status_update) box requests status processing. Saving a case with this box checked schedules the Field Service Scheduled : Status (customdeploy_nx_status) deployment to process the request. A checked box indicates requested work. It does not prove that a script is currently running.
When you save a status change on a task with a Task Type value, FSM checks its Update Status box to request processing. During processing, FSM marks the related case for a status update and clears the task's Update Status box.
When time processing clears the task's Field Service Log Activity Time box, FSM schedules status processing.
FSM processes a case's status request when the case has a Case Type (custevent_nx_case_type) value and the Update Status box is checked. It evaluates the related tasks against the configured opening and closing rules. When FSM submits the case update, it clears the case's Update Status box, even when no rule changes the status.
Task Completion Eligibility
Scheduled status processing sets a task to Completed when all of the following conditions apply:
-
Its status is In Progress.
-
Its Field Service End field contains a completion timestamp.
-
Its Field Service Log Activity Time box is cleared.
This check does not require Track Service Time to be enabled or a Service Time Item to be present. It also explains why a task with a retained end timestamp can return to Completed after a status reversal.
Recognizing Processing Results
Check the affected records as well as the script execution. A completed execution does not by itself establish that every requested action succeeded.
The following table lists observable evidence for each processing result.
|
Processing Result |
Observable Evidence |
|---|---|
|
CRM task start |
Field Service Start contains the captured date and time. After synchronization, a previously Not Started task has a NetSuite status of In Progress. |
|
CRM task completion |
The NetSuite task status is Completed. A populated end timestamp alone does not prove this result. |
|
Task status-request processing |
The task's Update Status box is cleared. Check the related case separately. Clearing the task's request does not prove that the case status changed. |
|
Case status-request processing |
The case's Update Status box is cleared. Check its status and, when a closing rule applies, its Field Service End Date and Field Service End Time. A cleared request can also mean that no configured rule changed the status. |
Use execution monitoring and logs for the status deployment to distinguish requested work from a running execution. For shared monitoring and deployment information, see FSM Script Reference.
Errors and Outstanding Work
Errors can delay NetSuite task completion and related case updates beyond the normal Start and Complete flows in this topic. When completion requires time processing, an error can leave Field Service Log Activity Time checked and postpone the task's eligibility for Completed status.
Status processing checks for an active, unrecovered error matching the deployment and the individual action. If the action is not eligible for retry, FSM skips it. A skipped action can leave a task In Progress or prevent a case status request from being set or cleared. It can also prevent updates to the case status and end fields.
Other eligible actions can still run. The task and case updates are separate actions, so some results can occur even when another action remains blocked. If all remaining actions are blocked by errors, processing can stop with outstanding work.
Some task actions become eligible for retry only after a delay and only for particular errors. A retry requires a later status execution. Elapsed time does not guarantee that an execution will run or that the action will succeed. Case actions do not share that delayed-retry eligibility. See Field Service Error Record for error information and state meanings, and FSM Script Reference for shared execution and retry behavior.
Configuration Effects
Configuration can change which current case statuses qualify for opening and the status returned by an opening or closing formula. It can also determine whether an individual completed task can close a case before other tasks finish.
For the exact settings, defaults, examples, and verification steps, see Configuring FSM Case and CRM Task Status Automation. That topic includes the setup for requiring all related tasks to be complete before closing a case.
For Track Service Time setup, see Setting Up the Track Service Time Feature.