FSM Customer and Asset Eligibility Configuration
This topic is intended for administrators and developers who configure customer and asset eligibility relationships.
The Asset model supplies eligible customer IDs. The Customer model supplies eligible asset IDs. These are two directions of the same relationship. Coordinate both eligibility settings so that selecting either side gives the intended result.
The standard relationship uses the Asset owner. For a service-provider relationship, a Customer multiselect field on the Asset can supply eligible bill-to customers. The owner field remains separate. The following fragment assumes that custrecord_nxc_service_providers already exists as a Customer multiselect on the Asset:
{
"models/asset": {
"prototype": {
"map": {
"customers": "custrecord_nxc_service_providers[]|"
}
}
},
"models/customer": {
"prototype": {
"assets": {
"asset": {
"filters": [
"custrecord_nxc_service_providers",
"anyof",
"${ customer.id }"
]
}
}
}
}
}
The Asset side reads the service-provider IDs. The Customer side finds Assets naming that Customer as a service provider. The inherited array: true, record type, and retrieval option remain. Populate and maintain the service-provider field for selection.
To allow any Customer/Asset pairing at this model eligibility layer, use this fragment:
{
"models/asset": {
"prototype": {
"map": { "customers": true }
}
},
"models/customer": {
"prototype": {
"map": { "assets": true }
}
}
}
Removing model eligibility restrictions can permit an unrelated customer to be selected for billing. NetSuite permissions, form availability, and other business rules still apply.
For relationships held in a child record, use a search collection that returns related IDs. Leave the corresponding mapped eligibility value empty so that the collection is used. Remove an inherited search when it would include an owner or Asset that should no longer be eligible. Don't merely add a second search and assume the original one stops contributing.
The following fragment assumes an existing relationship record and two List/Record fields. It replaces the inherited owner searches with relationship searches:
Replace the illustrative record and field IDs with the corresponding IDs from your account.
{
"models/asset": {
"prototype": {
"map": { "customers": "" },
"customers": {
"array": true,
"customer": null,
"serviceproviders": {
"record": "customrecord_nxc_service_providers",
"all": true,
"filters": [
"custrecord_nxc_service_providers_asset",
"anyof",
"${ asset.id }"
],
"map": "custrecord_nxc_service_providers_customer"
}
}
}
},
"models/customer": {
"prototype": {
"map": { "assets": "" },
"assets": {
"array": true,
"asset": null,
"serviceproviders": {
"record": "customrecord_nxc_service_providers",
"all": true,
"filters": [
"custrecord_nxc_service_providers_customer",
"anyof",
"${ customer.id }"
],
"map": "custrecord_nxc_service_providers_asset"
}
}
}
}
}
The empty map values defer to the search collections. The customer: null and asset: null entries remove the respective inherited named searches during configuration merging. The custom searches return ID arrays. Their templates use the selected asset or customer model, rather than the FSM Mobile event context.
NetSuite form filtering preserves an existing selected value on initial load, even if the relationship has since changed. Changing the Customer or Asset can apply the new eligibility result. FSM Mobile option definitions control FSM Mobile selection separately.