Configuration
This guide helps administrators and consultants understand, set up, and troubleshoot NetSuite Field Service Management (FSM). It covers the product’s architecture, configuration file structure, search syntax, configuration preview, and best practices for safe, manageable customizations.
Field Service Management (FSM) uses a layered architecture to balance strong core features with flexible, customer-specific setup. Understanding how these layers work and how configuration fits together is key for a smooth rollout and ongoing management.
The Two Levels of Field Service Management
There are two main levels in the FSM product, each with its own scope:
-
Core Product Code
-
Configuration Code
The core product code controls the fundamental behavior of FSM and is locked to users. The core product is installed in accounts as a NetSuite SuiteApp. Objects in the SuiteApp have an nx tag in their IDs and names that start with "Field Service."
The Configuration Code is visible and accessible to users and has the ability to be modified for each customer through the Field Service Configuration record.
Within the Configuration, there are two aspects:
-
Core Product Configuration
-
Custom Configuration
Core Product Configuration
The core product configuration is included with the product and is embedded in the core product code — only the FSM product team can make changes to the core product configuration. Changes to the core code go to all accounts as they upgrade to the latest SuiteApp version.
However, the core product configuration runs independently in each account and adapts based on that account’s NetSuite preferences and settings. So, every account’s core configuration is unique to that account.
Custom Configuration
The custom configuration, often called the config file, allows each account to merge custom configuration with the core product configuration. This account-specific setup is saved as a JSON object in a custom record called Field Service Configuration, under Field Service > Administration > Configuration.
When an account is first deployed, a default base custom configuration will be deployed in the account.
The base custom configuration will enable users to immediately view tasks and content on the mobile. This base configuration is then configured further in an account to meet each customers specific needs. It is built to cover 90% of use cases right away, so you can get started quickly and deploy fast.
Merging Core Product and Custom Configuration
The FSM product merges the core product and custom config at runtime or when the product is being used and the resulting config is what runs in the account.
You should only have one active custom configuration file; mark the rest as inactive.
How is Configuration Merged?
When adding custom configuration it is important to understand how merge logic is applied.
Objects
Objects are generally content wrapped in braces {}. Objects, such as element, article, or map, are merged property-by-property. Only the properties you set in your custom config will override the core config. Copy the sections you want to change from the core to your custom config, then remove anything extra so only your updates stay.
Arrays
Arrays are content wrapped in square brackets []. Arrays such as filter and item, are not merged. If you override an array, your config replaces the whole base array. So if you only add your new value, you’ll lose all the default behavior. You’ll need to copy the whole base array from the core config and add your changes.
Configuration at Runtime
At runtime, the configuration JSON merges with the core product code to control how FSM works. The core product code always runs, but the configuration JSON overrides it for the sections you specify.
If there’s no custom JSON, FSM runs using the core product behavior.
The Configuration Preview feature lets you see the runtime config right in your account. For more information, see Configuration Preview.
To learn more about this feature, see the following topics: