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, and 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 roll-out and ongoing management.

The Two Levels of Field Service Management

There are two main levels in the FSM product, each with its own scope:

  1. Core Product Code

  2. Configuration Code

The core product code controls the fundamental behavior of FSM and is locked for 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 starting with "Field Service."

The Configuration Code is visible and accessible by users, and you can modify it for each customer using the Field Service Configuration record.

Within the Configuration, there are two aspects:

  1. Core Product Configuration

  2. Custom Configuration

Core Product Configuration

The core product configuration is comes with the product and is built into 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 when they upgrade to the latest SuiteApp version.

However, the core product configuration runs independently in each account and adapts to that account’s NetSuite preferences and settings, so each account’s core configuration is unique.

Custom Configuration

The custom configuration—often called the config file—lets each account merge its own setup 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 you first deploy an account, a default base custom configuration will be deployed in the account.

The base custom configuration lets you view tasks and content in the mobile app right away. You can then tweak it to fit each customer’s needs. It's designed to cover 90% of use cases, 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 you use the product and the result config runs in the account.

Important:

You should only have one active custom configuration file—mark the rest as inactive.

How is Configuration Merged?

When you add a custom configuration, it's important to understand how the merge logic works.

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 config into your custom config, then remove anything extra so only your updates remain.

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, then 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 can override 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:

General Notices