FSM Program Processing and Case Closure
Field Service Management (FSM) Program processes project requests for case changes and case requests for missing tasks. For the generation stages and prerequisites, see FSM Program.
Requesting Processing
Saving a project can request Program processing when FSM finds calculated changes. Saving an explicit Field Service Update Program request also schedules processing. The project field is custentity_nx_program_update. The case field is custevent_nx_program_update. Forms may shorten the label to Update Program.
The following table describes the work requested from projects and cases.
|
Request Saved On |
Requested Work |
|---|---|
|
Project |
Assess the project Program for eligible case additions and removals. |
|
Case |
Assess that case for missing child tasks. This does not directly set the parent project's Update Program request. |
Creating a case can request task generation when applicable case rules find missing tasks. Editing an existing case does not automatically recalculate its task Program. A saved update request is needed to process its missing tasks.
Both requests use the shared Program background processing. Scheduling it from a case does not make an unchecked project request eligible. A case request can create missing tasks even when that case is already Closed. Use it when child task generation is intended.
The rolling horizon is recalculated when Program is assessed. The passage of time alone does not guarantee another execution or the creation of more cases.
Manually Closed Cases
A case does not have to be completed through FSM Mobile to request the next project Program work. FSM reviews the project's Program when a typed case linked to that project changes to the Closed stage through FSM record processing. If that calculation finds eligible additions or removals, FSM sets the project's Update Program request and schedules processing.
With the standard mapping, next-case progression uses the case's Field Service End Date (custevent_nx_end_date). Field Service End Date differs from the native Date Closed (enddate) field in NetSuite. A manual status change can populate Date Closed and leave Field Service End Date empty.
Completion outside FSM Mobile: A manual save, workflow, or script can use the closure path. Save the actual Field Service End Date and applicable completion time with the change to Closed. The completion values must be saved and available when FSM reviews the closure, and the update must run FSM's case processing. For a workflow, set the completion values before the record is submitted. Do not rely on an after-submit action to supply the completion values after the closure review has already run. When eligible Program changes are found, this path requests project processing without a separate manual project checkbox action. Recording an end date does not guarantee another occurrence is due.
In a next-only Program, a matched case with no Field Service End Date can continue to block the next occurrence after it has been marked Closed. If no other addition or removal qualifies, the closure assessment finds no changes. The project request can remain unchecked, and that path requests no Program execution. Advance or all-case creation rules can find other eligible work, so manual closure does not have one universal result across all Programs.
Completion date added after closure: Adding the Field Service End Date to a case that is already Closed does not repeat the Closed-stage transition. Confirm and record the actual completion date and applicable time, then save Update Program on the project to request reassessment. Use this explicit project request if the closure review ran before the completion values were available. Also use it if the closing update did not run FSM's closure processing. A project request does not bypass missing completion data, other unfinished matched cases, rule boundaries, or processing errors. It can clear without creating the next case if no action qualifies. Checking Update Program on the case is not a substitute for that project request.
Status automation can populate Field Service End Date and time from qualifying completed tasks when it closes the case. It does not generally backfill those values after a case is already Closed. For the related behavior, see FSM Case and CRM Task Status Automation.
To find work needing review, identify Closed cases with missing Field Service End Dates and examine their parent projects' calculated rows, requests, and errors. A missing completion date is a review candidate. It does not prove that another service occurrence is due. Check the actual resulting case records after reassessment.
Background Processing and Results
Field Service Scheduled : Program (customdeploy_nx_program) processes saved requests. It handles eligible project requests before case requests. Project processing can remove qualifying tasks and cases or create missing cases. Case processing creates missing tasks.
A checked Update Program box indicates requested work. It does not prove that an execution is currently running.
FSM clears a record's request after assessment finds no remaining eligible changes. The request can also clear when required inputs are missing or no rules apply. A cleared box therefore does not prove that all expected records exist.
Verify record generation by checking the resulting case and task records, their relationships, and execution information. A completed execution does not establish that every individual action succeeded. The calculated Program subtab and an Add/Remove Program banner are also insufficient proof of completion.
For shared execution, monitoring, and deployment information, see FSM Script Reference.
Errors and Outstanding Work
Program processing can create Field Service Error Records when an action fails. An active, unrecovered Program error can exclude a project and its linked cases from further Program assessment. This exclusion applies to an error associated with the project or one of its cases or tasks.
Other eligible work can continue. Actions that succeeded before a failure remain separate from work still outstanding. Case and task generation is not a single all-or-nothing operation. The absence of a Program banner does not prove success, because error exclusion can prevent the affected work from appearing in that assessment.
For field and error-state definitions, see FSM Error Record. For shared execution and retry behavior, see FSM Script Reference.