FSM Recurring Cases with Program Tasks
Field Service Management (FSM) uses recurrence to create case occurrences and Program rules to create the related tasks. For recurrence concepts and constraints, see FSM Case and Task Recurrence.
The combined business process has two stages. Recurrence creates the case occurrence, then Program processing assesses that case and creates its tasks. The stages have separate requests, processing, and errors. A case can exist with missing or partially created tasks. Recurrence can continue generating cases even when Program work is blocked.
Program task values are supplied by the applicable Program rules and task defaults. A task does not automatically inherit its case's assignee. Rules can explicitly derive a task value from case data where configured. Correcting the recurrence case template therefore does not necessarily correct a fixed task assignee in a Program rule.
A newly created case requests Program processing when its data and applicable rules calculate tasks to add. A case with no matching additions can therefore be created without a pending Program request. Adding rules later does not automatically request calculation for those existing cases.
An ordinary edit to an existing case without a pending Program request does not automatically request Program recalculation. Updating a Program rule or changing a recurring case must not be assumed to repair or replace the tasks already created for existing cases.
The case's Update Program checkbox requests assessment when the case is saved. This per-case request is for adding missing tasks under the current rules. It does not update matching existing tasks or remove obsolete or excess tasks. See What the Program Feature Automatically Sets or Controls.
Case Program matches existing tasks by type and start-date/time order. It does not match by an exact intended occurrence date or a saved association to each rule row. Partial deletion can therefore change which existing task satisfies a rule row. A later request can add an unmatched row without restoring the deleted task's original date or identity. Deleting a child task alone does not request Program on the parent, and Program records no permanent exclusion for that deletion.
For example, suppose the rules require two tasks of the same type on 1 and 2 November. If the first task is deleted, the remaining 2 November task can match the first desired row. The second desired row is then missing, so Program can add another task on 2 November rather than restore 1 November. Deletion alone does not automatically request Program on the parent case. A later valid request can expose this behavior.
The standard existing-task matching lookup is limited to the first 1,000 results. Large task sets need a completeness check before treating Program assessment as a reconciliation of all existing work.
The recurrence end condition controls case occurrences. It does not truncate task dates calculated by Program for a retained case. Tasks beyond the case-series cutoff can remain, or be added again by a later valid Program request if the applicable rules still require that work. Ending case recurrence also does not stop any independently configured Project Program that creates cases.
The two features also have different status boundaries. Recurrence's Not Started restriction for updating parent occurrences does not restrict Program's selection of flagged cases. A closed case with a pending Program request can still be assessed for task creation.
For a service outcome that requires tasks, verify both the case occurrence and its required child tasks. The recurrence Instances list reports the parent series, not completion of the combined business process.