FSM Track Service Time: Background Scripts Now Modify Task Records Sequentially — All FSM Accounts Affected

What changed

The Track Service Time feature adds background scripts that fire after a mobile field-service user marks a task complete. These scripts modify the Task record in two sequential phases and create a linked Time Bill record automatically.

Phase 1 — Task marked in-progress

• Status → In Progress
• Field Service End → timestamp of task completion from the mobile device
• Field Service Log Activity Time → checked (true)

Phase 2 — Time Bill created, Task completed

• A Time Bill record is created and associated with the Task.
• Status → Completed
• Date Completed → date of task completion
• Field Service Log Activity Time → cleared (false)

Why this matters for customizations

This applies to all FSM accounts, not only those with Track Service Time enabled. The sequential background scripts change the Task record's Status field twice (first to In Progress, then to Completed) in rapid succession. Any of the following could be affected:

• User Event scripts (beforeSubmit / afterSubmit) deployed on the Task record — they will fire for each status transition, meaning your logic may execute on an intermediate state (In Progress) that is not user-initiated.
• Workflows with state transitions triggered by Status changes on Task records.
• Custom actions or scheduled scripts that depend on the Field Service Log Activity Time checkbox or Field Service End field values — these are written and then cleared within the same background sequence.

Manual revert behavior

To move a Completed task back to In Progress via the UI, you must clear the Field Service End date field before saving. If you leave the timestamp in place and change the status to In Progress, the background script will immediately revert it to Completed on save. On the mobile side, the technician will see the task re-appear as In Progress and must tap Complete again, which restarts the entire two-phase cycle and records a new completion timestamp.

What to do

1. Audit User Event scripts on Task. Search your account for any beforeSubmit or afterSubmit deployments on the Task record type. Confirm they handle the intermediate In Progress status set by the background script — not just user-initiated status changes. Add an execution-context check (runtime.executionContext) if you need to distinguish background-script updates from UI or REST-driven changes.
2. Review Workflows on Task. Any workflow with a transition triggered by Status = In Progress or Status = Completed will fire during this sequence. Verify that firing twice (once per phase) does not cause duplicate emails, duplicate record creates, or other side effects.
3. Check saved searches and alerts. Saved searches that trigger on Field Service Log Activity Time = true may catch the transient checked state between Phase 1 and Phase 2. Adjust filters or add a delay condition if needed.
4. Test in Sandbox. The release note does not specify the exact script type (likely a Map/Reduce or Scheduled script running in the background). Enable Track Service Time in your Sandbox, complete a task from the mobile app, and inspect the System Notes on the Task record to see the exact field-change sequence and execution context. This will tell you what runtime.executionContext value to filter on.
5. Note the release version is not stated in the source. Oracle does not specify which release introduced this change. Verify availability in your account's release notes or feature list under Setup > Company > Enable Features > CRM > Field Service Management.