Configuring FSM Case and Task Recurrence

Configure recurrence availability, copied fields, and the generation horizon for your account. Set each series' recurrence pattern on the case or task form. For information about recurrence behavior and processing, see FSM Case and Task Recurrence.

Make these changes in the field service configuration record. Before editing the JSON, prepare an inactive revision and validate it using Updating and Validating FSM Configuration.

See the following sections:

• Properties and Defaults

• Default JSON

• Changing Recurrence Availability and Copied Fields

• Dependencies and Customization Limits

• When Changes Apply

Properties and Defaults

The following table lists recurrence settings and their defaults.

All settings in this table belong under recurrence.

Property or Setting	Accepted Value	Default	Units	Effect
enabled	Boolean	false	Not applicable	Enables both Case and CRM Task recurrence interfaces.
taskFields, caseFields	Arrays of field mappings with format suffixes	[]. No custom additions. Standard copied fields still apply.	Not applicable	Adds fields to the copied values for the corresponding record type.
taskChangedFieldsMap	Map object	Standard comparison mappings for native and Field Service time and estimated time.	Not applicable	Supplies comparable search representations for task fields.
caseChangedFieldsMap	Map object	Standard comparison mappings for native and Field Service start and end times.	Not applicable	Supplies comparable search representations for case fields.
creationRange.interval	Positive whole-number interval, stored as a string	"90"	Chosen unit	Sets how far ahead unfinished series can be generated.
creationRange.unit	"days", "weeks", "months", "years"	"days"	Calendar unit	Specifies the calendar unit for the generation horizon. It does not set the series repetition pattern.

For generation purposes, an unfinished series still needs expected occurrences. This status does not indicate whether its cases or tasks are complete.

Core Copied Fields

The following tables list the fields copied before any custom taskFields or caseFields additions. The [] defaults indicate no custom additions. Standard fields are still copied, but the mappings do not clone the complete source record. Recurrence calculates occurrence dates from the pattern.

The following table lists the standard CRM task mappings.

Exact Field Mapping	Copied Value
company[integer]	Native Company reference
priority[string]	Native Task priority
assigned[integer]	Native assignee reference
custevent_nx_customer[integer]	Field Service Customer reference
custevent_nx_task_type[integer]	Field Service Task Type reference
custevent_nx_task_team[array]	Field Service Task team selections
custevent_nx_task_asset[integer]	Field Service Task Asset reference
custevent_nx_time_zone[integer]	Field Service Time Zone reference
custevent_nx_start_time[time]	Field Service Start Time
custevent_nx_end_time[time]	Field Service End Time

The following table lists the standard case mappings.

Exact Field Mapping	Copied Value
company[integer]	Native Company reference
priority[integer]	Native Case priority
assigned[integer]	Native assignee reference
custevent_nx_customer[integer]	Field Service Customer reference
custevent_nx_case_asset[integer]	Field Service Case Asset reference
custevent_nx_case_type[integer]	Field Service Case Type reference
custevent_nx_start_time[time]	Field Service Start Time
custevent_nx_time_zone[integer]	Field Service Time Zone reference

The lists differ: task priority uses [string], and case priority uses [integer]. The standard case list excludes task team and Field Service End Time mappings. To copy other required existing fields, add those fields to the appropriate custom list as shown in the following examples.

Use custom lists to add fields. Adding a standard field again does not reliably replace its format and can create duplicate mappings. This topic does not provide instructions for replacing standard field formats through taskFields or caseFields. For information about format syntax, see Mapping Formats.

Changed-Field Comparison Maps

Recurrence uses taskChangedFieldsMap and caseChangedFieldsMap to read search values for change comparison and propagation. These maps are separate from the copied-field lists. A comparison entry does not make a field eligible for copying. Each map key must match the changed-field name being read. If no entry matches, recurrence uses that field's own mapping.

The standard time entries use Formula Text to cast each source value as a timestamp with local time zone. Each entry formats the timestamp with the time-format string supplied by the execution context, then converts the text to lowercase. These comparison values differ from the [time] format in copied-field lists.

The following table compares task and case search fields for each comparison key.

Comparison Key	Task Search Field	Case Search Field	Standard Comparison Representation
starttime	starttime	startdate	Lowercase time text using the context's time format
custevent_nx_start_time	custevent_nx_start_time	custevent_nx_start_time	Lowercase time text using the context's time format
endtime	enddate	enddate	Lowercase time text using the context's time format
custevent_nx_end_time	custevent_nx_end_time	custevent_nx_end_time	Lowercase time text using the context's time format
estimatedtime	estimatedtime	No standard entry	Hours-and-minutes text derived from the native decimal-hour value
estimatedtimeoverride	estimatedtimeoverride	No standard entry	Duration-override comparison key; hours-and-minutes text is the intended representation. No validated default literal is supplied here.

The native search columns differ from some comparison keys. Task endtime reads enddate, whereas case starttime reads startdate. Preserve these distinctions when changing a comparison map. The time entries use the execution context's time-format value. A fixed JSON time-format literal cannot represent the default in every context.

For estimatedtime, the standard formula constructs hours followed by a colon and a two-digit rounded minute component. For example, 1.5 hours appears as 1:30. For the partial static default, see Static Estimated-Time Comparison Default. For formula syntax and mappings that read and write different fields, see Using Formulas in Maps and Reading and Saving Different Fields.

Default JSON

This fragment shows the standard defaults for the properties included. Omitted properties retain inherited values.

            {
  "recurrence": {
    "enabled": false,
    "taskFields": [],
    "caseFields": [],
    "creationRange": {
      "interval": "90",
      "unit": "days"
    }
  }
} 

          

Static Estimated-Time Comparison Default

This partial fragment shows the exact static default for estimatedtime. It includes only that comparison entry, so other recurrence settings retain inherited values. The fragment does not include a validated override for estimatedtimeoverride. Because the time entries depend on the execution context, this fragment does not replace those entries with fixed literals.

              {
  "recurrence": {
    "taskChangedFieldsMap": {
      "estimatedtime": "formulatext:trunc({estimatedtime}) || ':' || to_char(round(mod({estimatedtime}*3600,3600)/60),'FM00')"
    }
  }
} 

            

Changing Recurrence Availability and Copied Fields

Note:

Before using these examples, replace the custom field IDs and case and task type IDs with valid values from your account.

Enable recurrence, extend the horizon to 120 days, and add an illustrative task text field:

            {
  "recurrence": {
    "enabled": true,
    "taskFields": [
      "custevent_example_access_notes[string]"
    ],
    "creationRange": {
      "interval": "120",
      "unit": "days"
    }
  }
} 

          

Use an existing field and its compatible format. Retain other custom additions in taskFields, because the custom array replaces the previous custom array. The standard copied-field list remains. The preceding sections list the standard copied fields and comparison-map requirements. For general mapping syntax, see Mapping Search Results.

To hide both recurrence interfaces, set recurrence.enabled to false.

Example: Copy Task Instructions and a Custom Integer Value

Use Task recurrence when individual CRM tasks repeat. This fragment is based on an existing account configuration. It copies the task message and an account-specific custom field to later task occurrences.

              {
  "recurrence": {
    "enabled": true,
    "taskFields": [
      "message[string]",
      "custevent20[integer]"
    ]
  }
} 

            

The following table illustrates the two mapping formats.

Mapping	Copied Value	Illustrative Value
message[string]	The task's message text, such as service instructions.	Inspect the panels and record any damage.
custevent20[integer]	The value of an existing custom field using integer formatting.	123

The format suffix tells FSM how to read and write the value. It does not create the NetSuite field or change its type. custevent20 is specific to the source account, so use an existing compatible field in your account. An integer-formatted field may hold a whole-number value or a List/Record option's internal ID. The suffix alone does not establish the value's business meaning. For a List/Record field, the value must identify an available option.

This example copies the task instructions and custom value to later task occurrences. For example, a weekly inspection task can repeat with the same values. Select the illustrative weekly pattern on the task form. Neither taskFields entry sets the repetition frequency. This example uses Task recurrence directly and does not require a Case Program rule.

Retain other required entries when changing taskFields, because the custom array replaces the previous custom array. Standard copied fields still apply. The fragment retains the inherited generation horizon, which is 90 days when no account override is present.

The added fields are also eligible for the series' normal forward propagation. Status restrictions and individual field exemptions still apply. See Individual changes and forward propagation.

Example: Create Three Program Tasks for Each Recurring Case

Use Case recurrence for the repeating service cycle and Program for the visits within each Case. This example copies the technician, team, working times, and visit interval to each generated case. Program uses those values to calculate three CRM tasks.

The following simplified fragment is based on an existing account configuration. Case type 14, Task type 1, and the listed custom fields are account-specific. Use the appropriate types and existing fields for your account. The fragment includes selected copied fields and one Program rule. When combining it with your configuration, retain other required field entries and Program rules. Custom arrays replace the corresponding previous arrays.

              {
  "recurrence": {
    "enabled": true,
    "caseFields": [
      "custevent_nx_assignedtechnician",
      "custevent_nxc_team[array]",
      "custevent_nxc_task_start_time[time]",
      "custevent_nxc_task_end_time[time]",
      "custevent_nxc_task_interval"
    ]
  },
  "program": {
    "caseMap": {
      "team": "custevent_nxc_team[array]",
      "starttime": "custevent_nxc_task_start_time[time]",
      "endtime": "custevent_nxc_task_end_time[time]"
    },
    "caseRules": [
      {
        "project": [
          true,
          false
        ],
        "case": [
          14
        ],
        "offset": 0,
        "interval": "${ supportcase.custevent_nxc_task_interval || 1 }",
        "unit": "day",
        "total": 3,
        "task": {
          "type": 1,
          "assigned": "${ supportcase.custevent_nx_assignedtechnician }",
          "custevent_nx_task_team": "${ supportcase.team }",
          "starttime": "${ supportcase.starttime }",
          "endtime": "${  supportcase.endtime }"
        }
      }
    ]
  }
} 

            

The settings work together as follows:

• recurrence.caseFields preserves the custom technician, team, working-time, and interval values on later Case occurrences. It does not copy the original case's child tasks.

• program.caseMap reads the copied team and time fields as supportcase.team, supportcase.starttime, and supportcase.endtime. The technician and interval fields are referenced directly by their field IDs.

• The Program rule applies to Case type 14. Its project: [true, false] condition allows a match with or without a resolved Project type.

• total: 3 calculates three required Tasks of type 1. With offset: 0 and unit: "day", the first task falls on the case's Field Service Start Date. The other two follow at the interval stored in custevent_nxc_task_interval. A blank interval uses this rule's one-day fallback. Use a positive whole-number day interval.

• The Task values explicitly take assignment, team, and working times from the Case data. Assignment to the native Case assignee alone is not the source used by this rule.

For a case dated November 1, 2026, an interval of 7 produces the dates in the following table. This example assumes no existing matching tasks.

Task	Date	Assignment and Working Times
First visit	November 1, 2026	From the copied case values
Second visit	November 8, 2026	From the copied case values
Third visit	November 15, 2026	From the copied case values

Choose the Case recurrence pattern on the Case form. That pattern determines when the next case occurs. The Program interval determines the spacing of tasks within each case. The three-task count and seven-day interval do not set the case recurrence pattern. Child tasks do not require a separate recurrence pattern.

Creating a case with matching task additions requests Program processing. Existing matching Tasks are retained rather than recreated or updated by a later assessment. Changing copied Case values or this rule therefore does not rewrite already-created Tasks. The Case recurrence end condition also does not truncate Program Task dates on a retained Case. See FSM Case and Task Recurrence for the combined processing and change boundaries.

For Program rule-property definitions, see Changing Program Rules.

Using Case and Task Recurrence Together

An account can configure both caseFields and taskFields inside the same recurrence object. To combine the two preceding examples, retain both field lists under the shared enabled: true setting and keep the applicable Program rule. Each list supplies copied values for its own record type. Each recurring Case or Task still has its own series pattern.

Case recurrence with Program creates Tasks within each Case occurrence. Task recurrence creates later occurrences of a Task itself. Configuring both copied-field lists does not automatically give Program-created child Tasks an independent Task recurrence pattern. You do not need taskFields to create those Program tasks. Program rules and task defaults supply the values.

Dependencies and Customization Limits

Important:

Setting recurrence.enabled to false hides the recurrence interfaces but does not delete series definitions or occurrences. This setting does not confirm that existing series have stopped generating. Ending or deleting a series is a separate operation.

Each series' occurrence count or end date still limits generation. Additional copied fields do not clone every related record. Case child tasks require separately configured Program rules.

Preserve required comparison formats when overriding mappings. The case and task field lists are distinct. Neither list is a switch to show the interface for only one record type.

When Changes Apply

The recurrence interfaces reflect the enablement setting when a form loads. FSM applies copied-field and generation settings during subsequent series assessments. Changing these settings alone does not rewrite every existing occurrence.

Related Topics

• FSM Configuration
• Configuring FSM Program
• FSM Searches and Field Mapping
• FSM NetSuite View Configuration
• FSM Record Model Configuration

General Notices