Others

Field Service Roles

The out-of-the-box Field Service roles do not have the “Field Service Scheduler” or “Field Service Mobile” checkboxes checked due to a NetSuite limitation.

Locked Bundle Objects

Certain objects (custom records, lists & fields) within the Field Service Management bundle have been locked to prevent customization in customer accounts. These bundle objects cannot be unlocked under any circumstances.

The code behind the Field Service product relies on specific settings on these bundle objects; unexpected changes to these bundle objects may result in data loss upon future upgrades or the product failing to work within the customized account.

As such, these objects have been locked to avoid any negative outcomes and to allow for more stable releases.

Inventory Status and Consumables Tab and Records

If the NetSuite Inventory Status feature is enabled in the customer’s account, the Field Service Consumables record cannot be used. The Field Service Consumable record (and matching “Inventory” tab on the mobile) does not support the Inventory Status feature.

Item Fulfillment – Asset Creation

Asset creation through item fulfillment will only be triggered where the Item Fulfillment record has been edited (or created) and saved through the NetSuite user interface.

Sales orders fulfilled from the Field Service mobile application are not expected to trigger automatic asset creation unless someone edited and saved the resulting item fulfillment through the NetSuite UI.

Item Fulfillment – Pick/Pack/Ship

The Pick, Pack & Ship feature on item fulfillment records in NetSuite is not fully supported.

Fulfillments created from the Field Service mobile will always be created with the “Shipped” status.

Automatic asset creation from item fulfillment will always be triggered by creation of the item fulfillment regardless of the status (picked, packed or shipped).

On the mobile app, editing of Sales Order lines pre-created and pre-fulfilled (picked or packed) through the NetSuite UI can result in error messages related to fulfillment.

Config and Multi-Select Field Values

When running a search in config or in the console and returning the values from a multi-select field a common mapping pattern can be seen below:

            {
  "record": "task",
  "filters": ["internalid","anyof","12345"],
  "map": {
    "id": "internalid",
    "team": {
      "id": "=custevent_nx_task_team[]",
      "label": "#custevent_nx_task_team[]|"
    }
  }
} 

          

Here it is expected that the "team" property of each result will be an array of id/label pairs for the employees selected in the "custevent_nx_task_team" multi-select field (see below).

            [{
  "id": "12345",
  "team": [{
    "id": "555",
    "label": "Bob"
  },{
    "id": "777",
    "label": "Bill"
  },{
    "id": "999",
    "label": "Jane"
  }]
}] 

          

It is expected that the "id" s and the "label" s will align with each-other BUTbut due to a NetSuite limitation these will sometimes be mismatched.

NetSuite returns the list of "id" s and the "label" s separately and each list may be in a different and unexpected order. These two lists are then combined into the final result as shown above but you cannot trust that the id matches the given label.

The good news is that there are very few use-cases where this miss-match results in problems. Usually the Field Service mobile app will disregard the provided label and will use only the "id". In most places where the label needs to be displayed it is re-obtained from the proper & accurate list of "options" based on the "id" provided (rather than directly using the "label" returned above).

This problem usually becomes apparent where custom config has been applied to the account such that both the "id" and the "label" are used directly. This sort of config should be avoided where-ever possible as the results cannot be relied upon to be consistent. Instead custom config should take only the "id" and then separately lookup the correct "label" from a reliable options list.