FSM Schedule Board Configuration

Schedule Board configuration controls the records loaded onto the board, the information displayed for those records, and the available grouping, filtering, sorting, and color options. It also supplies defaults for the displayed hours, date views, refresh interval, and editing time step.

Configure these properties in the "routes/scheduler" object. A Schedule Board resource represents a person or another configured resource displayed on the board. Eligibility determines whether the resource can receive assignments. It differs from an FSM Mobile resource, which defines an FSM Mobile page or supporting data.

This topic covers:

• Configuration Areas

• Core Defaults and User Preferences

• Display and Refresh Properties

• Date Views

• Resource and Event Data

• Grouping, Filtering, and Sorting

• Colors and Status Presentation

• Calendars and Location Data

• Editing and Assignment Constraints

• Performance Reference

Configuration Areas

The following paths start within "routes/scheduler".

Configuration Area	Purpose
start, end	Default hours displayed on the board.
unit	Time step used when adjusting event dates and times.
refresh	Interval for refreshing board data.
onsite	Distance threshold used for the on-site comparison.
groups	Mapped resource properties used to group rows.
views	Named date ranges available as board views.
resource	Searches and mappings for resource rows and their assignment eligibility.
event	Searches and mappings for time-based records.
calendar	Work-calendar data and exceptions.
resourcepanel	Resource-panel filter and sort options.
assignedpanel	Assigned-event filter and sort options.
unassignedpanel	Unassigned-event filter and sort options.
colour	Color groups, palettes, and the default group.
eventstatus	Labels and icons for mapped event statuses.
administrators	Role IDs used to enable board editing controls. This does not replace NetSuite permissions or record-specific eligibility.

For information about merging, activation, validation, and Preview, see FSM Configuration. For search filters and read/write mapping syntax, see FSM Searches and Field Mapping.

Core Defaults and User Preferences

For inherited configuration values, see How Custom Configuration Combines with Core Configuration.

Schedule Board also saves user preferences in browser storage and reapplies the saved preferences after loading its configuration. Saved preferences can therefore override defaults such as displayed hours, the selected view, time zone, panel choices, and color selections.

Changing a default does not reset existing browser preferences.

Display and Refresh Properties

The following table lists display and refresh properties, accepted values, and standard defaults.

Property	Accepted Value	Standard Default	Effect
start	Number representing an hour from 0 to 24.	9	Supplies the default beginning of the displayed day.
end	Number representing an hour from 0 to 24, later than start.	17	Supplies the default end of the displayed day. Keep a display range of at least one hour.
unit	Positive number of milliseconds.	900000 (15 minutes)	Supplies the rounding step for event-time adjustments and the fallback duration used by those adjustments.
refresh	Positive interval in milliseconds.	60000 (one minute)	Controls periodic refresh of the board's data. It does not save pending scheduling changes.
onsite	Nonnegative distance in kilometers.	0.5	Supplies the threshold used to compare event and assignee coordinates for on-site presentation. It does not collect location data.
groups	Array of mapped resource-property names.	["regiontext"]	Groups resource rows using those properties, in the specified order.

Displayed hours do not change an employee's work calendar or establish when the employee is available. Changing unit does not establish a new standard duration for every task.

The following complete JSON fragment sets the displayed hours to 8:00 a.m. - 6:00 p.m. and the refresh interval to 90 seconds. Add its properties to the existing custom configuration rather than replacing unrelated configuration.

            {
  "routes/scheduler": {
    "start": 8,
    "end": 18,
    "refresh": 90000
  }
} 

          

A shorter refresh interval can increase request frequency. Measure performance under comparable conditions to determine whether more frequent refreshes improve performance. See FSM Performance and Data Collection for measurement and data capture.

Standard default JSON for these properties:

            {
  "routes/scheduler": {
    "start": 9,
    "end": 17,
    "unit": 900000,
    "refresh": 60000,
    "onsite": 0.5,
    "groups": [
      "regiontext"
    ]
  }
} 

          

Date Views

Each property under views defines a named view. Its property name is the view ID.

View Property	Purpose
label	Text displayed for the view.
unit	Unit used for date offsets. The standard views use "days".
start	First date offset relative to the selected date.
end	Last date offset relative to the selected date.
default	Marks the view to use when no matching user-selected view applies.

The standard views cover 1, 3, 7, 15, and 31 days. The 7-day view is the standard default. For example, its offsets are start: -3 and end: 3.

The following fragment adds a 5-day view and makes it the configuration default. It also removes the default designation from the inherited 7-day view. Other inherited views remain available.

            {
  "routes/scheduler": {
    "views": {
      "seven": {
        "default": false
      },
      "five": {
        "label": "5 Days",
        "unit": "days",
        "start": -2,
        "end": 2,
        "default": true
      }
    }
  }
} 

          

Keep one intended default view. A saved selection of another available view can still take precedence.

Resource and Event Data

Resource Definitions

The standard resource.employee definition searches employee records. It selects active employees with an FSM region and, where applicable, applies subsidiary visibility restrictions.

Its map supplies resource information such as:

• id and label

• region and regiontext

• skill and skilltext

• jobtitle

• calendar

• editable and eligibility as a project resource

• location and contact information

The board uses these mapped property names. The names do not necessarily match NetSuite field IDs.

Preserve the properties required by grouping, filters, calendar display, assignment, and other retained behavior when extending the map.

Adding Additional Resources

Add a separately named search under resource to load an additional set of rows. A new definition does not inherit resource.employee's map, active-employee criteria, or subsidiary restrictions. Supply its own selection criteria and the properties needed by the retained board behavior.

Customer configurations include generic resource searches alongside employee searches. The following example is adapted from a customer search restricted to one generic resource. It keeps the additional rows read-only: editable: false prevents assignment dragging onto them. Project Management and the native Work Calendar are prerequisites for this example.

Note:

Account-specific values: 17918 is the generic resource ID and 7 is the region ID in the archived example. Replace them with the intended records in your account. Include only resources appropriate for the board's viewers. This search does not inherit the employee search's user.view restriction. Region selection and grouping are display controls, not access restrictions.

              {
  "routes/scheduler": {
    "resource": {
      "genericresources": {
        "record": "genericresource",
        "filters": [
          ["internalid", "anyof", 17918],
          "and",
          ["isinactive", "is", "F"]
        ],
        "map": {
          "id": "internalid",
          "label": "formulatext:'GR: '||{entityid}",
          "title": "entityid",
          "jobtitle": "formulatext:'Generic Resource'",
          "region": "formulatext:'7'",
          "regiontext": "formulatext:'Generic Resources'",
          "skill": "custentity_nx_skill[]",
          "skilltext": "formulatext:nvl2({custentity_nx_skill}, replace({custentity_nx_skill}, ',', '<br>'), '')",
          "calendar": "formulatext:nvl2({workcalendar}, 'workcalendar-'||{workcalendar.id}, '')",
          "project": true,
          "editable": false
        }
      }
    }
  }
} 

            

The existing employee definition remains inherited. With the default groups: ["regiontext"], the additional records appear under Generic Resources when included by the resource-panel filters. Their names start with GR:. Their mapped calendar supplies calendar shading. Existing project task assignments to those resource IDs can be displayed. The example does not enable new assignments to those rows.

Use resource IDs that match the corresponding event assignments and remain unique across the complete resource collection. The board stores resources by ID. If two definitions return the same ID, the definitions do not create independent rows, and mapped values can overwrite one another. Keep calendar consistent with an available calendar definition. Setting project: true supplies an eligibility attribute. It does not establish that every event can save against that record type. In particular, a generic resource row does not establish an employee assignee or person who uses FSM Mobile for a CRM task.

When adding resource-panel filters, include their mapped columns in every applicable resource definition, using matching option IDs. This example maps region and skill for the standard filters and regiontext for row grouping. The Case Type filter and color examples apply to events and do not require a Case Type field on a generic resource row. Extend the relevant event maps if you add an event type. Do not use employee-only fields or joins in a generic resource search.

Adding Resource Information to the Board

Add content to existing display properties in resource.employee.map. Adding an arbitrary property to the map does not create a new visible line automatically.

This customer-derived example replaces the employee subtitle with the employee's supervisor and explicitly retains the job title and phone mappings:

              {
  "routes/scheduler": {
    "resource": {
      "employee": {
        "map": {
          "jobtitle": "title|",
          "subtitle": "supervisor#|",
          "phone": "mobilephone"
        }
      }
    }
  }
} 

            

# reads the supervisor's display text. | supplies an empty fallback. The inherited label, resource identity, filters, calendars, and eligibility map remain in place. The subtitle replaces the inherited department or subsidiary subtitle.

The following table shows how the board uses each mapped resource property.

Mapped Property	Board Usage
label	Resource-row heading and resource-panel card in both compact and detailed display.
jobtitle, subtitle	Additional lines in detailed board rows and detailed resource-panel cards. The resource popup also shows jobtitle.
title	Resource-popup heading, with HTML support. It is separate from the plain-text row label.
skilltext	HTML content in the resource popup. It can include additional relevant information as well as skills.
phone, email	Contact actions in the resource popup when values are present.
details	Included in resource text searching. Mapping it alone does not display it in the resource popup.

Use Detailed display to show the supervisor subtitle on board rows, and the resource panel's detailed mode to show it on cards. Board display and resource-panel display are separate choices. Keep content short enough for the available row width.

Another customer pattern adds crew size to the existing job-title line:

              {
  "routes/scheduler": {
    "resource": {
      "employee": {
        "map": {
          "jobtitle": "formulatext:{title}||nvl2({custentity_nxc_crew_size}, ' - Crew: '||{custentity_nxc_crew_size}, '')"
        }
      }
    }
  }
} 

            

custentity_nxc_crew_size is a customer field, not a standard FSM field. This variant requires that field, or a replacement field available to the employee search. It shows the crew suffix in detailed rows, detailed cards, and the popup's job-title line. It changes displayed information. It does not calculate crew availability or add crew members to task assignments.

Event Definitions

The following table lists standard event definitions and their feature requirements.

Definition	Records and Purpose	Availability
event.task	CRM tasks and their scheduling data.	Standard definition.
event.projecttask	Project tasks and their scheduling data.	Depends on the Project Management feature.
event.nonworkingday	Field Service Employee Non-Working Day records.	Standard definition.
event.resourceallocation	Resource Allocation time blocks.	Depends on Project Management and Resource Allocations.

The board uses mapped event IDs, resource associations, dates, time zones, labels, and eligibility values. Preserve the standard date/resource criteria and access restrictions when changing searches. The selected date range and resources form part of those criteria.

To change only the CRM task display label, the following fragment retains the rest of its inherited map and reads the NetSuite task title for label:

              {
  "routes/scheduler": {
    "event": {
      "task": {
        "map": {
          "label": "title"
        }
      }
    }
  }
} 

            

This changes that label's source. It does not change the task title, event identity, scheduling fields, or other labels.

Search Filters and Panel Filters

Search filters select the records retrieved from NetSuite. Panel filters select from mapped records available to the board. A panel filter cannot display a record excluded by the underlying search. See Board searches and request tags for the default selection logic, subsidiary scope, and the meaning of user.view, user.edit, and the request tags.

Schedule Board search definitions use the board's server template context. This differs from the current-job context in FSM Mobile. Do not assume that an FSM Mobile event reference is available in a Schedule Board search. For template syntax, see FSM Expressions and Template Tags.

Warning:

Assess record visibility and scheduling effects before changing resource, date, or subsidiary criteria, Boolean grouping, or the nested project task search. The CRM case-expansion removal described in this topic is an exception. These searches are part of the board's data boundary. Panel filters cannot correct a broadened search or restore excluded data.

The following table lists configuration changes and their risks.

Change	Risk and Consequence
Remove or broaden the user.view condition	Can return records outside the intended subsidiary view scope through the board. Do not rely on panel filters or editing eligibility to keep retrieved data out of view.
Remove or broaden the user.edit mapping	Can make records or assignment targets selectable outside the intended editing scope. Board editing controls and NetSuite save permissions remain separate. A save may fail or, where permitted, change unintended records.
Remove resource criteria or the nonempty team condition	Can include unrelated assignments or incorrectly match tasks with empty teams, including during unassigned-work requests. Removing team matching can instead hide work assigned to team members.
Remove date criteria, or use the same date rule for every record type	Can load unnecessary history or exclude valid work. CRM tasks use start-date inclusion. Project tasks and contextual blocks use date overlap.
Change and/or nesting	Can make a scope or date condition apply to only one branch. Adding a restriction outside the case-expansion branch and its nested search is not necessarily equivalent to adding it inside both.
Remove the project task nested ID search or filter assignment joins directly in the outer search	Can return an incomplete resources list. Project task saves rebuild assignments, so a partial list can lead to lost assignments or incorrect work recalculation. This is not the CRM case-link search.
Replace a standard filters array or add a new resource definition without its own restrictions	Arrays replace inherited arrays. New definitions do not inherit the employee definition's safeguards. A short custom filter can silently remove resource, date, or subsidiary conditions.

Keep subsidiary formulas conditional on the account's enabled features. References to subsidiary fields are not a portable substitute for the non-OneWorld defaults. Preserve mapped IDs, assignment lists, calendars, dates, time zones, and editing rules when changing presentation.

Removing Linked CRM Task Selection and Case Expansion

event.task.map.link supplies the grouping value used for linked focus and automatic selection. The standard mapping uses the case number. It is not a record hyperlink. Links in title, details, add, and other display/action mappings are separate.

There are two independent changes:

1. Set event.task.map.link to the Boolean value false. This setting stops automatic focus or selection of other tasks through the mapped link value. Deleting the property from a custom override would allow the standard mapping to remain inherited.

2. Replace event.task.filters with its original first branch. Remove the outer or branch that uses the nested cases search. This change stops loading additional CRM tasks based solely on a shared case within the requested resource and date scope.

The following OneWorld example makes both changes. It retains the standard subsidiary formula, primary-assignee matching, nonempty task-team matching, and start-date criteria. The array completely replaces event.task.filters. The rest of the standard task definition and map remains inherited.

              {
  "routes/scheduler": {
    "event": {
      "task": {
        "filters": [
          [
            [
              ["assigned", "anyof", "${ request.parameters.resource }"],
              "or",
              [
                ["formulatext:{custevent_nx_task_team.id}", "isnot", ""],
                "and",
                ["custevent_nx_task_team", "anyof", "${ request.parameters.resource }"]
              ]
            ],
            "and",
            ["startdate", "onorafter", "${ request.parameters.start }"],
            "and",
            ["startdate", "onorbefore", "${ request.parameters.end }"],
            "and",
            ["formulatext:case when '${ user.view }' = '0' or coalesce({case.subsidiary.id}, {job.subsidiary.id}, {company.subsidiary.id}, 0) in (0,${ user.view }) then 'T' else 'F' end", "is", "T"]
          ]
        ],
        "map": {
          "link": false
        }
      }
    }
  }
} 

            

For a non-OneWorld account, omit the final "and" and subsidiary-formula condition, and retain the rest of the filter unchanged. Also retain any intentional task criteria already configured in the account. This example replaces standard case expansion and does not automatically preserve an existing custom filter array.

Setting link: false alone leaves the case-expansion search and its extra returned records in place. Removing the search alone leaves automatic linking among any matching visible tasks still returned. Applying both changes removes automatic linking and case-expansion loading. Individual selection, manual selection of multiple tasks, the underlying case relationship, and each task's editing conditions remain available.

Important:

Leave event.projecttask.filters unchanged. Its nested projecttasks search identifies eligible project task IDs and then loads the complete resource assignments. The standard project task map has no case link property. The event.nonworkingday and event.resourceallocation definitions also have no standard case-link mapping. Removing CRM case expansion does not require changing those definitions.

Grouping, Filtering, and Sorting

Grouping Resources

groups contains names from the mapped resource data. Its order determines the grouping levels.

For example, this fragment groups employees by region and then job title, using properties already present in the standard employee map:

              {
  "routes/scheduler": {
    "groups": ["regiontext", "jobtitle"]
  }
} 

            

The array replaces the inherited grouping array. Include every grouping level you intend to retain.

Panel Filter Options

Each panel's filter object contains named filter definitions.

Filter Property	Purpose
label	Filter label shown to the user.
column	Mapped property to match on a resource or event.
options	Available choices, supplied as an option list or a resolved search.
allany	Enables the All/Any choice for matching multiple selected values.

For data with multiple values, All requires every selected value to be present. Any requires a match to at least one selected value. The option IDs must correspond to the values supplied by the mapped property.

Resource, assigned-event, and unassigned-event panels have separate definitions. Changing one panel does not automatically change the others.

For example, changing resourcepanel.filter.region.label changes the resource panel's filter label. It does not rename the NetSuite region field or change its search criteria.

Consistent Filters Across Panels

Define a filter in every panel where that criterion has a useful meaning. Use matching option IDs and compatible mapped values in those panels. The resource panel filters resource rows. The assigned panel filters events on the board and in the assigned list. The unassigned panel filters its own event list. Each panel saves an independent selection, so adding the same definition does not synchronize selected values.

Region is available in all three standard panels. For a consistent label, this fragment changes the inherited Region filter label in each panel without replacing its options or mappings:

              {
  "routes/scheduler": {
    "resourcepanel": {
      "filter": {
        "region": {
          "label": "Service Region"
        }
      }
    },
    "assignedpanel": {
      "filter": {
        "region": {
          "label": "Service Region"
        }
      }
    },
    "unassignedpanel": {
      "filter": {
        "region": {
          "label": "Service Region"
        }
      }
    }
  }
} 

            

For a shared criterion, supply its resource mapping in resource.employee.map and every other applicable resource.<definition>.map. Also supply its event mapping in every applicable event.<definition>.map. Resource and event property names can differ. Each filter's column must identify the appropriate mapped property. That property must return IDs from the same option list. Do not assume that a task field or join also exists on a project task or record for a nonworking day.

Case Type has a different scope: it describes the case linked to a CRM task. The following example adds it to both event panels. It does not add a Case Type filter to resource rows, which have no corresponding case relationship in this example.

Adding a Case Type Filter While Retaining Other Event Types

This example filters CRM tasks by the selected Case Types. It retains project tasks, Employee Non-Working Days, and Resource Allocations regardless of that selection. It uses a separate mapped property, casetypefilter, so that the filtering values do not alter the existing casetype property used for coloring.

Event Definition	Value Supplied to casetypefilter	Effect of Selecting Case Types
task	The linked case's Case Type ID.	Matches the selected types. CRM tasks with no Case Type do not match an active selection.
projecttask	An array containing every available Case Type ID.	Matches any selected type without reading a case field from the project task.
nonworkingday	The same array of Case Type IDs.	Retains blocks for nonworking days without requiring a case relationship.
resourceallocation	The same array of Case Type IDs.	Retains allocation blocks without requiring a case relationship.

The following fragment assumes Project Management and Resource Allocations are enabled. If Project Management is disabled, omit the complete projecttask override. If either required feature is disabled, omit the complete resourceallocation override. Extend only the existing enabled definitions. A partial map is not a new event definition.

Add these properties to the existing custom configuration. The two panels use the same option search. Each retained context event resolves that search to an array of IDs using map: "internalid", rather than to option objects.

              {
  "routes/scheduler": {
    "event": {
      "task": {
        "map": {
          "casetypefilter": "case.custevent_nx_case_type|"
        }
      },
      "projecttask": {
        "map": {
          "casetypefilter": {
            "record": "customrecord_nx_case_type",
            "all": true,
            "map": "internalid"
          }
        }
      },
      "nonworkingday": {
        "map": {
          "casetypefilter": {
            "record": "customrecord_nx_case_type",
            "all": true,
            "map": "internalid"
          }
        }
      },
      "resourceallocation": {
        "map": {
          "casetypefilter": {
            "record": "customrecord_nx_case_type",
            "all": true,
            "map": "internalid"
          }
        }
      }
    },
    "assignedpanel": {
      "filter": {
        "casetype": {
          "label": "Case Type",
          "column": "casetypefilter",
          "options": {
            "record": "customrecord_nx_case_type",
            "all": true,
            "map": {
              "id": "internalid",
              "label": "name"
            }
          },
          "allany": false
        }
      }
    },
    "unassignedpanel": {
      "filter": {
        "casetype": {
          "label": "Case Type",
          "column": "casetypefilter",
          "options": {
            "record": "customrecord_nx_case_type",
            "all": true,
            "map": {
              "id": "internalid",
              "label": "name"
            }
          },
          "allany": false
        }
      }
    }
  }
} 

            

Use Any matching when selecting several Case Types: a CRM task has one linked Case Type. allany: false omits the All/Any control for this filter. It does not reset a previously saved All mode. The panel's Clear All action removes its selected filters and their matching modes.

The all-ID arrays are matching values for presentation and do not assign every Case Type to those records. Keep their search criteria aligned with the option search if you later restrict the available Case Types. An empty value, an absent property, or an arbitrary value such as "all" does not provide this behavior. The ID array is returned with each retained event, so its size grows with the Case Type list.

Retained events still have to satisfy the underlying searches, date range, visible resource rows, other active filters, and text search. For example, a resource-panel filter can remove an employee row and its blocks for nonworking days. This example prevents the Case Type filter from excluding context events. Other board filters can still exclude those events.

If other event definitions are displayed, give each one a deliberate mapping: its real Case Type where that relationship is supported, or the all-ID array where it should remain visible. If a criterion applies to CRM tasks and project tasks but not to nonworking days, map the corresponding field separately for each task type. Use the all-option-ID pattern only for context records that you intend to retain.

Panel Sort Options

Each panel's sort object contains named sort definitions.

Sort Property	Purpose
label	Sort choice shown to the user.
column	Mapped property used for ordering.
direction	"asc" or "desc".

Standard resource-panel choices sort labels alphabetically. Standard event-panel choices include priority, start date, and label. Use the mapped property's actual values when defining direction. A label such as High Priority does not itself determine the sort order.

Colors and Status Presentation

The configuration uses the spelling colour.

The following table lists color properties, standard defaults, and their purposes.

Property	Standard Default	Purpose
colour.enabled	true	Enables color grouping.
colour.readonly	false	When true, prevents customization of color items and swatches. You can still select a color group.
colour.default	"priority"	Supplies the default color-group ID.
colour.group	Priority, status, Task type, and Case type groups.	Defines the mapped property and items used by each group.
colour.palette	Named palettes containing color swatches.	Defines palettes available to groups.

Color Groups, Items, and Swatches

A group identifies the mapped event property to color. Its items associate returned values with labels, swatches, and optional map-cluster precedence. Keep a single value for a color category: the all-ID array used by the Case Type filter is not a suitable color category.

Property Within colour	Accepted Value and Effect
group.<group ID>.label	Label displayed for the group.
group.<group ID>.column	Mapped event property whose value identifies a color item.
group.<group ID>.palette	Existing palette ID, such as "rainbow", "cool", "warm", or "contrast".
group.<group ID>.items	Array of items or a resolved search/combined collection returning that array.
An item's id	Value matching the group's mapped event property. Use record IDs rather than labels for record-based choices.
An item's label	Label displayed for the item.
An item's swatch	Named swatch included in the group's palette. An omitted swatch is assigned from the palette in item order, cycling when necessary.
An item's cluster	Optional precedence for the color of a map cluster. Lower values take precedence. Use consistent numeric ranks when defining this behavior.
group.<group ID>.eventswatch	When true, a populated event-level swatch takes precedence over the group item. When false, the group replaces that event-level swatch. The standard groups use true.
palette.<palette ID>.label	Palette label displayed to the user.
palette.<palette ID>.swatches	Nonempty array of named swatches available to the palette. An override replaces the inherited array.

Include an explicit item swatch in the group's configured palette. If a user chooses another palette, the corresponding position in that palette is used. Saved item swatch choices can also take precedence.

Adding Colors to a Palette

The following fragment makes redpigment and sizzlingsunrise available in Cool by replacing cornflowerblue and cyanprocess. It retains the other six entries and the palette's eight positions.

              {
  "routes/scheduler": {
    "colour": {
      "palette": {
        "cool": {
          "swatches": [
            "redpigment",
            "viridiangreen",
            "sizzlingsunrise",
            "mediumaquamarine",
            "inchworm",
            "electricpurple",
            "electricindigo",
            "battleshipgrey"
          ]
        }
      }
    }
  }
} 

            

The swatches array replaces the inherited array. This example changes the choices for every group using Cool. An inherited item whose configured swatch was removed falls back to a palette color unless a saved choice takes precedence.

Use recognized swatch names. These values identify the board's supplied styles. Entering a new name or a hex color does not define a new swatch.

Keep matching positions available in every palette that you can select. The color picker wraps additional swatches onto another row. If you switch to a shorter palette, a configured or selected color can lose its corresponding position. This example preserves eight positions, matching the standard palettes.

Changing an Existing Color Group

Combine this fragment with the preceding Cool-palette change. The fragment changes the Priority group to use Cool and preserves all three priority IDs and cluster ranks. It sets High to redpigment, Medium to sizzlingsunrise, and Low to viridiangreen.

              {
  "routes/scheduler": {
    "colour": {
      "group": {
        "priority": {
          "palette": "cool",
          "items": [
            {
              "id": "1",
              "label": "High",
              "swatch": "redpigment",
              "cluster": "1"
            },
            {
              "id": "2",
              "label": "Medium",
              "swatch": "sizzlingsunrise",
              "cluster": "2"
            },
            {
              "id": "3",
              "label": "Low",
              "swatch": "viridiangreen",
              "cluster": "3"
            }
          ],
          "eventswatch": true
        }
      }
    }
  }
} 

            

The complete items array replaces the inherited Priority items. The priority values on the tasks are unchanged. eventswatch: true retains event-level presentation, including the standard gray color for completed tasks.

Adding a Case Type and Context Color Group

The following examples show three alternative ways to color CRM tasks by Case Type and provide gray presentation for work without a Case Type. Use the common Case Type group with one alternative. The alternatives are not cumulative.

Alternative	Value of This Approach	Effect on Existing Event Colors
One shared context item	One label and one customizable color for all work without a Case Type.	Gray is a fallback, and populated event-level swatches are retained.
Separate context items	Each context can later have its own label, color, and map-cluster rank.	Gray is a fallback, and populated event-level swatches are retained.
Direct swatch mappings	Fixed gray values with no context items to maintain in the color group.	Replaces context records' mapped swatches and applies whenever the active group honors event-level swatches.

The common group uses casecolour for a single category value. Keep it separate from the casetypefilter arrays in the filter example. Case Type items are loaded from their record search. No account-specific IDs are hard-coded.

Include a projecttask override only when Project Management is enabled. Include a resourceallocation override only when Project Management and Resource Allocations are enabled. Merge into the enabled standard definitions, preserving their searches, identity, date, resource, eligibility, and save mappings.

Common Case Type Group

This fragment adds casework and makes it the configuration default. It supplies the CRM task's actual Case Type and the corresponding color items. Add one of the three context-color alternatives to configure the presentation of other work.

                {
  "routes/scheduler": {
    "event": {
      "task": {
        "map": {
          "casecolour": "case.custevent_nx_case_type|"
        }
      }
    },
    "colour": {
      "default": "casework",
      "group": {
        "casework": {
          "label": "Case Type and Context",
          "column": "casecolour",
          "palette": "cool",
          "items": {
            "array": true,
            "casetypes": {
              "record": "customrecord_nx_case_type",
              "all": true,
              "map": {
                "id": "internalid",
                "label": "name",
                "cluster": 1
              }
            }
          },
          "eventswatch": true
        }
      }
    }
  }
} 

              

Case Type items receive colors from Cool in item order, cycling when necessary. A saved user group, palette, or swatch choice can take precedence over configuration defaults.

Alternative 1: One Shared Context Item

Use this when all work without a Case Type can share one color choice. CRM tasks without a Case Type, project tasks, nonworking days, and Resource Allocations return otherwork.

                {
  "routes/scheduler": {
    "event": {
      "task": {
        "map": {
          "casecolour": "formulatext:nvl(to_char({case.custevent_nx_case_type.id}), 'otherwork')"
        }
      },
      "projecttask": {
        "map": {
          "casecolour": "formulatext:'otherwork'"
        }
      },
      "nonworkingday": {
        "map": {
          "casecolour": "formulatext:'otherwork'"
        }
      },
      "resourceallocation": {
        "map": {
          "casecolour": "formulatext:'otherwork'"
        }
      }
    },
    "colour": {
      "group": {
        "casework": {
          "items": {
            "context": [
              {
                "id": "otherwork",
                "label": "Other Work",
                "swatch": "battleshipgrey",
                "cluster": 2
              }
            ]
          }
        }
      }
    }
  }
} 

              

The single context item defines the label and fallback color for all four situations. Its ID is an ordinary matching value, not a wildcard. The ID could be named all, but that name would not make it match other values automatically.

eventswatch: true in the common group preserves populated event-level swatches. Completed tasks keep their standard gray color. Tasks linked to closed cases, nonworking days, and Resource Allocations keep their existing specialized presentation. Battleship Gray is used when no event-level swatch is present.

Alternative 2: Separate Context Items

Use this when those situations should be independently configurable. The example starts all four items at Battleship Gray, but maps a distinct ID for each one.

                {
  "routes/scheduler": {
    "event": {
      "task": {
        "map": {
          "casecolour": "formulatext:nvl(to_char({case.custevent_nx_case_type.id}), 'nocasetype')"
        }
      },
      "projecttask": {
        "map": {
          "casecolour": "formulatext:'projecttask'"
        }
      },
      "nonworkingday": {
        "map": {
          "casecolour": "formulatext:'nonworkingday'"
        }
      },
      "resourceallocation": {
        "map": {
          "casecolour": "formulatext:'resourceallocation'"
        }
      }
    },
    "colour": {
      "group": {
        "casework": {
          "items": {
            "context": [
              {
                "id": "nocasetype",
                "label": "No Case Type",
                "swatch": "battleshipgrey",
                "cluster": 2
              },
              {
                "id": "projecttask",
                "label": "Project Task",
                "swatch": "battleshipgrey",
                "cluster": 2
              },
              {
                "id": "nonworkingday",
                "label": "Non-Working Day",
                "swatch": "battleshipgrey",
                "cluster": 2
              },
              {
                "id": "resourceallocation",
                "label": "Resource Allocation",
                "swatch": "battleshipgrey",
                "cluster": 2
              }
            ]
          }
        }
      }
    }
  }
} 

              

For example, changing only the projecttask item's swatch to viridiangreen gives project tasks that fallback color. The other three items retain Battleship Gray. The chosen swatch must belong to Cool. You can also customize the items independently when color customization is enabled.

As in Alternative 1, event-level swatches take precedence. Changing the item for nonworking days alone does not replace its standard unavailable swatch. Use eventswatch: false only when the group should replace all event-level colors, including completed-task and specialized context presentation.

Alternative 3: Map the Swatch Directly

Use this when the gray context color should be fixed in the event mappings. Add this fragment to the common group without either context-item alternative:

                {
  "routes/scheduler": {
    "event": {
      "task": {
        "map": {
          "swatch": "formulatext:case when {status.id} like 'COMPLETE' then 'ashgray' when {status.id} not like 'COMPLETE' and {case.stage} like 'CLOSED' then 'inactive' when {case.custevent_nx_case_type.id} is null then 'battleshipgrey' end",
          "cluster": 2
        }
      },
      "projecttask": {
        "map": {
          "swatch": "formulatext:'battleshipgrey'",
          "cluster": 2
        }
      },
      "nonworkingday": {
        "map": {
          "swatch": "formulatext:'battleshipgrey'",
          "cluster": 2
        }
      },
      "resourceallocation": {
        "map": {
          "swatch": "formulatext:'battleshipgrey'",
          "cluster": 2
        }
      }
    }
  }
} 

              

Here, swatch contains the recognized color name directly. casecolour still identifies a Case Type item. Putting a color name into casecolour alone would not assign that color.

The CRM task formula retains the standard completed-task and closed-case colors, then returns Battleship Gray when there is no Case Type. Ordinary CRM tasks with a Case Type receive their group color.

The other three maps replace their inherited swatches with Battleship Gray. This also replaces completed project tasks' standard gray color, the presentation for nonworking days, and Resource Allocations' hard/soft color distinction. Their dates, calendar effects, eligibility, and save behavior are unchanged.

With eventswatch: true, the direct swatch takes precedence over group and palette choices. It therefore remains fixed when the user changes to another group that also honors event-level swatches. With eventswatch: false, the active group ignores it. You cannot recolor these context records through a context item because this alternative defines none.

This alternative requires at least one available Case Type item for the new group. If there are no Case Types, use an existing enabled color group for the direct swatches instead.

The direct cluster: 2 mapping gives those events an explicit map-cluster rank. When an ordinary CRM task receives its Case Type group color, the item's rank of 1 is applied instead.

All three alternatives color available events without adding panel filters or changing which records the searches retrieve.

Status Presentation

eventstatus defines labels and icons for mapped event statuses. Standard entries include not started, in progress, completed, tentative, confirmed, and overdue.

Changing a color, label, or icon does not change the underlying record status or the rules governing its transitions. For automated case and CRM task status behavior, see .

Calendars and Location Data

The calendar definitions supply work hours, working weekdays, and exception dates. The standard configuration includes the FSM Work Calendar definition and, when Project Management is enabled, the standard NetSuite Work Calendar definition. A resource's mapped calendar value links it to the corresponding calendar.

Preserve matching calendar IDs and the properties used by calendar display and applicable project task processing.

Event and resource location mappings supply coordinates used by the map and on-site comparison. A map setting or onsite threshold does not generate missing coordinates or enable location collection in FSM Mobile. Use FSM Maps, Geo-location and Tracking and FSM Service Locations and Geocoding for the behavior that supplies or uses that data.

Editing and Assignment Constraints

The following table describes the conditions that govern editing and assignment.

Condition	Role
Board editing eligibility	administrators identifies roles for which board editing controls are enabled. The standard configuration includes the Administrator role and roles marked for FSM scheduling.
Event eligibility	The event's mapped editable value determines whether the event is eligible for editing.
Resource eligibility	Resource data determines whether the target employee is eligible for the relevant assignment, including applicable subsidiary and Project-resource conditions.
NetSuite processing	Permissions, record requirements, and the applicable save behavior still govern the resulting record operation.

The standard CRM task eligibility requires the task to be not started, with applicable subsidiary editing restrictions. Project tasks have additional requirements, including fixed-start scheduling and the relevant project resource condition.

Important:

Do not replace standard eligibility or access conditions with unrestricted values merely to enable dragging. Displaying a record, enabling an editing control, and successfully saving an assignment are different results.

An administrators override replaces the inherited array. Preserve the required authorized roles if that setting is changed. It does not grant NetSuite record permissions.

A new event definition or copied map does not establish that the record supports Schedule Board scheduling. Some standard definitions have specialized save processing. Confirm the supported record type, identity, mapped fields, and save behavior before treating a custom definition as equivalent to a standard event.

Performance Reference

For performance measurement and data capture, see FSM Performance and Data Collection.

Related Topics

• FSM Service Scheduling and Assignment

• FSM Maps, Geo-location and Tracking

• FSM Service Locations and Geocoding

• FSM Performance and Data Collection

General Notices