FSM Mobile Resource Selection and Shared Data
FSM Mobile uses resource definitions to provide the tabs and supporting data available to a user or job. Configuration rules select which resources load. Administrators can use these rules to select resources for the appropriate context and reuse loaded data in FSM Mobile expressions.
This topic explains where resources are defined, how configuration rules select resources, and how resources supply data to other FSM Mobile resources. For resource and element properties, see FSM Mobile Resource Properties Reference and FSM Mobile Element (Block) Reference.
In this topic:
Where Mobile Resources Are Configured
The literal root JSON key "routes/mobile" contains FSM Mobile configuration. Named resource definitions, such as inventory and consumables, are direct entries under "routes/mobile". There is no general tabs wrapper.
The following table lists paths for resource definitions and selection rules.
|
Configuration Path |
Purpose |
|---|---|
|
|
Defines the record sources for jobs shown in FSM Mobile, including task and project task events. |
|
|
Selects resources available for a matching job. For example, |
|
|
Selects supporting resources loaded for a matching employee. |
|
|
Defines a named FSM Mobile resource, including its elements and, where applicable, its article model. |
|
|
Defines lookup data that is available to other FSM Mobile resources when loaded through the user resource rules. |
Standard configuration includes inventory in user.employee.resources by default. This rule loads the resource so its lookup data can be referenced by other FSM Mobile resources. You can extend inventory or add other supporting resources to the employee resource rules. Defining a resource alone does not load its data. If you remove inventory from the matching employee resource rule, it no longer loads as shared user data.
Shared Rule Matching
Rules compare conditions with data supplied by the relevant feature. FSM Mobile resource rules receive mapped user or event data. Other rule families supply their own context. A condition cannot read an arbitrary NetSuite field unless that value is supplied in the context.
Every condition in one rule must match. An array supplies alternatives for one condition: any entry can match. Output properties, such as resources in an FSM Mobile resource rule, are excluded from matching. Use only condition and output properties accepted by the relevant rule family. An extra property can become an unintended condition.
Condition Examples
The following rule fragments demonstrate matching against illustrative mapped data. These fragments are examples, rather than complete configuration replacements. The IDs are illustrative. Use the values and structure supplied by your mapping.
|
Rule Fragment |
Mapped Input |
Matching Behavior |
|---|---|---|
|
|
|
Matches. Nonempty numbers and strings are compared as text. |
|
|
|
Matches either listed value. A value of |
|
|
|
Matches a populated, nonzero value. It also matches |
|
|
|
Matches missing, |
|
|
|
Has the same false-input matching behavior as |
|
|
|
Matches the nested |
|
|
|
Matches because both conditions pass. It fails if |
|
|
Any mapped user or event data |
In an FSM Mobile resource rule, |
Numeric 0 is treated as false input. The string "0" is populated text. A numeric-zero condition also behaves like false, so it cannot distinguish zero from other false or missing inputs. Do not use zero as an ordinary record-type ID.
The text conditions "true" and "false" have the same matching effects as Boolean true and false. A true condition tests whether an input is populated, rather than requiring the exact Boolean value true.
Omitting a condition leaves that input unrestricted. For example, {"task": 104} does not restrict asset, whereas {"task": 104, "asset": true} requires both the specified task value and a populated asset value.
Using Matching Rules
Matching and selection are separate: several rules can match the same data, and the feature determines which matches it uses.
|
Rule Family |
Selection Behavior |
|---|---|
|
FSM Mobile resource selection |
Uses the first match. Place specific rules before a catch-all rule. |
|
CRM task billing ( |
Uses the first match. |
|
Automatic notification rules |
Use the first match. |
|
Program project and case rules |
Use all matches. |
For accepted inputs, output properties, and effects, see Configuring FSM Billing Rules, Configuring FSM Program, or FSM Notification Configuration, as applicable. The example in Selecting Resources shows first-match selection when both a specific rule and a catch-all rule match.
Selecting Resources
Resource selection uses an ordered list of rules. Each rule is an object with a resources array of resource IDs and can include conditions that determine which user or event it applies to. FSM uses the first rule that matches the current user or event. Keep the conditions, order, and existing IDs when modifying the list.
resources is the output of each rule and is excluded from conditions. Every other condition uses the mapped user or event data described in Shared Rule Matching. A rule containing only resources matches without conditions. Place this catch-all rule after more specific rules.
The example uses mapped event values. It selects details and a custom inspection resource when task is 104 or 105 and asset has a value. Otherwise, it selects details:
[
{
"task": [104, 105],
"asset": [true],
"resources": ["details", "inspection"]
},
{
"resources": ["details"]
}
]
The IDs are illustrative. Define the custom resource and use values supplied by your event mapping. When adapting the event's resources array, preserve all other required rules and resource IDs.
To add another supporting resource for employees, define it directly under "routes/mobile" and include its ID alongside inventory in the appropriate user.employee.resources rule. To make a job resource available, include its ID in the relevant event resource rule, such as event.article.task.resources.
A custom rule array replaces the corresponding standard array. Replacing user.employee.resources or an event's resources array without preserving required rules can remove resources that other FSM Mobile functions use.
Sharing Data Between Resources
The inventory resource supplies option lists used across FSM Mobile tabs. A shared list is defined as a hidden Text element in a loaded supporting resource. Give the element a unique uri, set map to "|", and define its options. Other elements can then reference the registered URI, such as services.options, instead of repeating the same search on each tab.
For static option lists on hidden elements, see Shared Option Lists and URI References for the conditions that can remove an option array during rendering.
Shared data does not have to be inventory-related. You can define a separate named supporting resource under "routes/mobile" and add that resource's ID to the matching employee rule. Expressions reference the supplying element's uri, not the supporting resource's ID.
The supplying resource must load before its URI can be used. Referencing the loaded options does not rerun the supplying search for each consuming element. Loading or refreshing the supplying resource can run the search again. Use an event resource for a list that depends on the current job rather than a user-level shared resource.
The following example adds a shared Service item list to inventory.element. It shows the placement of the search and the properties that let other elements reference its options:
{
"routes/mobile": {
"inventory": {
"element": {
"services": {
"type": "text",
"hidden": true,
"map": "|",
"uri": "services",
"options": {
"record": "item",
"all": true,
"filters": [
["isinactive", "is", "F"],
"and",
["type", "anyof", "Service"]
],
"map": {
"id": "internalid",
"label": "itemid"
}
}
}
}
}
}
}
Merge this addition into the existing JSON. The matching user.employee.resources rule must include inventory. The standard configuration includes inventory by default. Preserve the complete existing resource-rule array if you change it. The all property retrieves additional search results in batches when the list can exceed the standard first 1,000 results.
For search filters, mapping syntax, and the locations that support all, see FSM Searches and Field Mapping. The topic also explains how to define mapped job or user data and distinguishes an event map from a resource's article map.
A Select element in a loaded FSM Mobile resource can use the shared options:
{
"service": {
"type": "select",
"label": "Service",
"options": "services.options"
}
}
The Select's value and save mapping remain specific to that resource. The two examples are fragments to merge into the appropriate resource definitions. These fragments do not replace the complete FSM Mobile configuration.
The standard inventory searches also supply item data used by FSM Mobile features such as consumables, Sales Orders, and receiving. Review dependencies before changing or removing those existing searches.
For guidance on measuring the effect of shared option lists on FSM Mobile loading, see FSM Performance and Data Collection.
Using Template Tags
Template tags in the form ${ ... } can supply resource configuration values when the server prepares the resource. Their results must be valid for the receiving properties. See FSM Expressions and Template Tags for syntax, available context, and value-type handling.
Tags can reference mapped job or user data.
Applying Resource Changes
Changed resource definitions and selection rules take effect when FSM Mobile reloads the applicable configuration and data. A consumer of shared data also depends on the supplying resource being loaded. Refreshing only the consumer does not replace stale supplier data.
Mobile Emulator Access
When you are signed into NetSuite, a checked Field Service Mobile box on your current role makes you eligible to open another employee's FSM Mobile session. People already recognized as Administrators also qualify. The target employee must be an FSM Mobile user.
The optional user.mobileadminroles array lists integer internal IDs of additional roles. A listed role grants the same eligibility when its Field Service Mobile box is clear. The standard default is an empty array:
{
"user": {
"mobileadminroles": []
}
}
Listing a role whose Field Service Mobile box is already checked adds no benefit. A custom list replaces the existing list, so retain additional roles that should continue to qualify. An empty list leaves eligibility from the Field Service Mobile box and Administrator eligibility in effect.
This eligibility applies to the Mobile Login and Email Mobile Login actions and Schedule Board resource login links. Technicians' Mobile tabs and task actions are configured separately.