FSM Record Model Configuration
Record models provide the field mappings, default values, and record-specific behavior used by FSM in NetSuite and server processing. Some models also support FSM Mobile operations. Use this reference to identify the applicable model and the settings associated with it.
Retain the product's standard model mappings unless a supported configuration procedure specifies a change. Do not clear or remove mappings as a general customization practice. Add or modify a mapping only when a defined requirement identifies the attribute, its data source, and the behavior that will use it. Mapping changes can affect record reads, writes, and existing FSM processing.
A model definition is different from an FSM Mobile resource definition. An FSM Mobile resource selects records and presents elements to a technician. Its article definition can supply its own mappings and synchronization behavior. Changing models/task does not automatically change every FSM Mobile article that reads Task records.
Where Model Settings Are Configured
Each record model has its own top-level property in the FSM configuration JSON, such as "models/asset", "models/case", or "models/task". Use the exact configuration ID listed in the Model Index.
Within a model's root object, prototype contains instance settings such as map, defaults, and supported model-specific properties. Some settings belong directly inside the root object. Examples include the asset duplicate comparison settings uniqueFormula and uniqueTemplate. Each model entry identifies where its documented settings belong.
Use FSM Configuration for configuration placement, merging, Preview, and activation. Use FSM Searches and Field Mapping for map and search syntax.
Purpose and Effect of Model Mappings
A mapping associates a model attribute, such as customer, with a NetSuite field or calculated search value. It can define the value read and the destination for writes separately. Existing FSM code continues to use the same attribute name after its mapping changes. defaults supplies an omitted initial value. The map connects the attribute to stored data.
Supplying Additional Values When Creating Records
A creation operation can obtain values from a source record and pass those values as attributes to a destination record model. The source search map determines which values are read and the attribute names supplied. The destination model map connects those names to the fields written on the new record. An additional mapping is useful when the supplied attribute name differs from the destination field ID. A mapping is also useful when normal model reads need that field under a defined attribute.
For example, an implementer wants a project created for a new asset to receive the department selected on the asset's item. The Item search in warranty.asset can return a department attribute. An additional Project model mapping then connects department to a custom Department field on the Project.
The following customization fragment illustrates this connection. The custom field IDs are examples: replace the example field IDs with the actual Item source field and Project destination field. Both fields must already exist and accept compatible values. Merge the fragment into the existing custom configuration. The inherited Item restrictions, type and date mappings remain in effect.
{
"warranty": {
"asset": {
"item": {
"map": {
"department": "custitem_example_department"
}
}
}
},
"models/project": {
"prototype": {
"map": {
"department": "custentity_example_department"
}
}
}
}
Here, the Item source field supplies department, and the Project model writes that attribute to custentity_example_department. A Department selection normally supplies the Department internal ID. The source value must be valid for the destination field. The source is a direct Item search, so this example does not require an additional Item model mapping.
In the shared record-model write path, an attribute without an explicit mapping uses its own name as the destination field ID. This applies to standard and custom field IDs. For example, the Item search could instead supply the Project custom field ID directly:
{
"warranty": {
"asset": {
"item": {
"map": {
"custentity_example_department": "custitem_example_department"
}
}
}
}
}
With no existing Project mapping for custentity_example_department, the shared write path uses that name directly. No additional project mapping is needed to write this supplied value. An existing nonempty field mapping for the same attribute takes precedence.
Using a destination field ID does not automatically read a source field with that name. The source search still needs its own valid mapping. It also does not make every field available in normal model reads: add a model mapping when that field must be included in those reads. An unmapped field may be fetched by an explicit model attribute request, but merely naming it does not add it to every search.
The destination field must be available and writable on the record being created, and the supplied value must meet its type, permissions and validation requirements. A model mapping used in normal searches also requires the field to be searchable. Adding a mapping does not create a NetSuite field or FSM Mobile element, initiate an operation, or keep records synchronized. Model mappings apply to other operations using the same model as well. For the new-Asset trigger and the effects on subsequent requests and existing projects, see Configuring FSM Automatic Project Creation for New Assets. Use FSM Searches and Field Mapping for detailed mapping syntax.
Effects of Mapping Changes
The following table summarizes the purposes and effects of mapping changes.
|
Change |
Purpose |
Effect |
|---|---|---|
|
Add an attribute |
Make an additional existing field available to a template, rule, or operation using that model. |
Model reads can include the extra field. The intended operation must consume the attribute to produce the required business outcome. Adding a mapping does not itself create a NetSuite field or an FSM Mobile element. |
|
Remap an existing attribute |
Point an existing FSM attribute to another compatible field for a supported account-specific requirement. |
Existing code continues using the attribute name but reads, and potentially writes, a different field. Related formulas and processing do not automatically adapt. |
|
Change a calculated mapping |
Adjust a documented calculation consumed by an existing feature. |
Changes the value supplied to that feature. Asset automatic naming and customer eligibility are examples of deliberate mapping customization. Use their specific configuration guidance. |
Adding an entry can expand the search columns used to load the model, even when no operation uses the new value. Retain standard identity, relationship, and transaction-line mappings because existing processing depends on these mappings.
Clearing or removing a mapping is not a general way to disable behavior. Configuration null removes the entry during merging. Some read and write paths can then treat the attribute name as a native field ID. A blank mapping has different effects. Follow the exact documented instructions for any deliberate blank or removal.
The following fragment illustrates where a model mapping override belongs. Merge it into the existing custom configuration. It is not a replacement configuration.
{
"models/asset": {
"prototype": {
"map": {
"autoname": ""
}
}
}
}
Here, models/asset identifies the model, prototype contains its instance settings, and map.autoname identifies the mapping being changed. See models/asset for this setting's effect and naming-specific guidance.
Defaults and Inheritance
defaults supplies attributes omitted when a new model is created. Existing record values are read from NetSuite. Certain models also apply defaults during form initialization or validation. Their individual entries describe that behavior. A Boolean default on those paths can replace an existing value, including a value of false.
Models can inherit another model's field mappings and behavior. A change to a base model can therefore affect several record types. An individual model can supply its own mapping or default in place of the inherited value. Check each affected model's effective configuration. Derived models can supply different mappings and defaults.
Each model entry begins with a standard default JSON fragment showing its mappings, defaults, and the model settings covered here, including relevant inherited values. These are reference fragments, not replacement configurations. Executable methods and callbacks are omitted. Properties that vary with enabled features and account-formatted values are explained beside the fragments because their effective values vary by account.
The model tables identify useful standard mappings and explicit defaults. The tables are not a complete list of fields supported by each NetSuite record, and the tables do not establish that every visible implementation property is a customer configuration option. Retain record identity, relationship mappings, and specialized behavior when making a supported change.
Model methods, event callbacks, synchronization functions, and processing functions are not portable configuration recipes. A new FSM Mobile resource with the same record type or copied JSON can have different fulfillment, transformation, inventory, and related-record behavior. See FSM Mobile Resource Properties Reference for article configuration and the relevant feature topic for the supported operation.
Custom Forms for Record Creation
For a NetSuite record created through a record model, prototype.defaults.customform supplies the internal ID of the custom form used for creation. This applies to Journal Entry, Opportunity, Quote, and Sales Order models as well as other models that create records through the shared record-creation path.
|
Property |
Purpose |
Standard Default |
Effect and Dependencies |
|---|---|---|---|
|
|
Selects the NetSuite custom form used when creating a record through this model. |
No form ID is assigned by the standard Journal Entry, Opportunity, Quote, or Sales Order defaults. |
Uses the specified form when the new model's attributes do not already supply |
For example, the following customization fragment supplies a Sales Order form default. Replace 123 with the applicable Sales Order form's internal ID and merge the fragment into the existing configuration. The inherited Sales Order defaults remain in effect.
{
"models/salesorder": {
"prototype": {
"defaults": {
"customform": 123
}
}
}
}
Use the same prototype.defaults.customform location within models/journal, models/opportunity, or models/quote for the corresponding record type. This default applies to creation through that model. It does not select the form displayed when opening an existing NetSuite record. An FSM Mobile resource's form setting and article defaults have their own configuration. See FSM Mobile Resource Properties Reference.
Model Index
The model entries cover mappings, defaults, and model settings used in customer configuration. Item, Subsidiary, and TimeZone are listed under Excluded Models at the end of this reference.
|
Configuration ID |
Model |
Reference |
|---|---|---|
|
|
Activity base |
|
|
|
Asset |
|
|
|
Case |
|
|
|
Consumable |
|
|
|
Contact |
|
|
|
Customer |
|
|
|
Employee |
|
|
|
Expense Report |
|
|
|
Invoice |
|
|
|
Item Fulfillment |
|
|
|
Journal Entry |
|
|
|
Opportunity |
|
|
|
Project |
|
|
|
Project Task |
|
|
|
Quote |
|
|
|
Sales Order |
|
|
|
CRM Task |
|
|
|
Time Bill |
|
|
|
Transaction base |
|
|
|
Transfer Order |
models/activity
models/activity provides shared mappings and sourcing behavior inherited by the CRM Task and Project Task models. The Case model also reuses selected sourcing behavior. This model is separate from the Field Service Activity record used by automatic service time tracking, which supports CRM Tasks only.
Standard default structure (JSON fragment):
{
"models/activity": {
"prototype": {
"record": "activity",
"map": {
"name": "title",
"company": "company",
"project": "formulatext:nvl2(nullif({company.internalid}, {custevent_nx_customer.internalid}), {company.internalid}, '')|",
"status": "status",
"priority": "priority",
"message": "message",
"type": "custevent_nx_task_type",
"customer": "custevent_nx_customer",
"asset": "custevent_nx_task_asset",
"address": "custevent_nx_address",
"latitude": "custevent_nx_latitude",
"longitude": "custevent_nx_longitude",
"timezone": "custevent_nx_time_zone",
"id": "internalid"
},
"defaults": {}
}
}
}
The following table describes the activity model's shared settings.
|
Property |
Purpose |
Standard Value |
|---|---|---|
|
|
Base activity record identity. |
|
|
|
Activity title. |
|
|
|
Company, FSM customer, and Asset relationships. |
|
|
|
Activity classification and details. |
|
|
|
Service location and time zone. |
|
|
|
Supplies default model attributes on creation. Additional application paths are described in this entry. |
|
The standard model recognizes both customers and projects in the Company field. It keeps the company, customer, project, and Asset relationships consistent. Project Task narrows the Company relationship to a project. Preserve these relationships when extending a derived model. Location geocoding is configured in Configuring FSM Service Locations and Geocoding.
Activity defaults are applied during initialization and validation when a type or Asset is present. Non-Boolean defaults fill an empty model value. Boolean defaults can replace it. Use the record-specific entry when changing Task or Case defaults.
models/asset
The Asset model represents customrecord_nx_asset. Its mappings support naming, parent relationships, customer eligibility, and service location.
Standard default structure (JSON fragment):
{
"models/asset": {
"prototype": {
"record": "customrecord_nx_asset",
"map": {
"name": "name",
"autoname": "formulatext:substr(trim(regexp_replace({custrecord_nx_asset_item}, '^'||{custrecord_nx_asset_item.parent}||' : ')||' '||nvl({custrecord_nx_asset_serial}, nvl(regexp_replace({custrecord_nx_asset_address_text},CHR(13)||CHR(10),' '), {custrecord_nx_asset_address}))), 1, 80)",
"parent": "parent",
"type": "custrecord_nx_asset_type",
"item": "custrecord_nx_asset_item",
"serial": "custrecord_nx_asset_serial",
"customer": "custrecord_nx_asset_customer",
"customers": "formulatext:{custrecord_nx_asset_customer.internalid}",
"transaction": "custrecord_nx_asset_transaction",
"addressbook": "custrecord_nx_asset_address",
"addresstext": "custrecord_nx_asset_address_text",
"latitude": "custrecord_nx_asset_latitude",
"longitude": "custrecord_nx_asset_longitude",
"timezone": "custrecord_nx_asset_time_zone",
"timezoneid": "custrecord_nx_asset_time_zone.custrecord_nx_time_zone_olson|",
"region": "custrecord_nx_asset_region",
"locationchanged": "custrecord_nx_asset_location_update",
"id": "internalid"
},
"defaults": {},
"customers": {
"array": true,
"customer": {
"all": true,
"record": "customer",
"filters": [
"internalid",
"anyof",
"${ asset.customer || 0 }"
]
}
}
},
"uniqueFormula": "formulatext:regexp_replace({custrecord_nx_asset_item.id} || ' ' || nvl({custrecord_nx_asset_serial.id}, {custrecord_nx_asset_address_text}), '['||chr(13)||chr(10)||chr(39)||']+', ' ')",
"uniqueTemplate": "${ ((item || '') + ' ' + (serial ? serial : addresstext || '')).replace(/['\\r\\n]+/g, ' ') }"
}
}
The following table describes the asset model's naming, customer selection, duplicate comparison, and default settings.
|
Property |
Purpose |
Standard Value or Behavior |
Configuration Effect and Dependency |
|---|---|---|---|
|
|
Defines the generated Asset name. |
Formula that combines the Item name with serial number, address text, or address selection. Trims the result to 80 characters. |
Use a formula for the required automatic name, or |
|
|
Controls which Customers can be selected for service work against this asset. |
|
A field or formula can return allowed customer IDs. Literal |
|
|
Provides a fallback search for allowed Customers when the mapped result calls for a lookup. |
Search collection with |
Change the search to find the customers permitted for the selected asset. It runs only for a blank or missing mapped result and must return Customer IDs. See Customer Selection Settings. |
|
|
Defines the duplicate key calculated for Assets already stored in NetSuite. |
Search formula combining Item ID with serial number or address text and removing apostrophes and line breaks. |
Keep it consistent with |
|
|
Defines the duplicate key calculated from proposed Asset values. |
Template combining |
Keep it consistent with |
|
|
Supplies default values for Asset model attributes. |
|
No explicit Asset defaults. Added defaults also apply on initialization: Boolean values can overwrite existing values. Other values fill an empty attribute. |
The empty autoname mapping shown in Where Model Settings Are Configured stops the model from supplying an automatic name. Required Name fields still need a value when automatic naming is disabled. For the complete naming setup procedure, see Disable Automatic Naming for a Record Type.
Useful standard mappings are name: "name", parent: "parent", type: "custrecord_nx_asset_type", item: "custrecord_nx_asset_item", serial: "custrecord_nx_asset_serial", customer: "custrecord_nx_asset_customer", and transaction: "custrecord_nx_asset_transaction". Location mappings use custrecord_nx_asset_address, custrecord_nx_asset_address_text, custrecord_nx_asset_latitude, custrecord_nx_asset_longitude, custrecord_nx_asset_time_zone, and custrecord_nx_asset_region.
The parent mapping identifies the parent asset. It does not define the naming formula. Asset inheritance and parent-only fields are controlled separately. See Configuring FSM Asset Hierarchy and Inheritance for those controls and FSM Asset Hierarchy and Inheritance for their consequences. The location-change indicator supports later updates to related tasks. Changing a display map does not replace that processing.
See Customer and Asset Eligibility for coordinated eligibility changes. Duplicate comparison changes must continue to distinguish the intended Asset identities and reject duplicates under the account's business rules.
Customer Selection Settings
The asset's owner is the singular customer attribute, mapped by prototype.map.customer to custrecord_nx_asset_customer. The plural customers settings control which customers can be selected for work against that asset. Permitting another customer for service work does not change the owner stored on the asset.
prototype.map.customers supplies the first result. It can read a field or formula, or supply a literal Boolean value. prototype.customers defines a fallback search. FSM uses the mapped result as follows:
|
Mapped Result |
Customer Choices |
Fallback Search Used? |
|---|---|---|
|
Literal |
Leaves the native Customer field's normal choices available, without the Asset-based restriction. It does not mean 'use the owner field' or 'enable a field mapping.' |
No. |
|
Literal |
No permitted Customer candidates. |
No. |
|
A nonempty ID string, such as |
Only the customers identified by that string. |
No. |
|
An array of IDs, such as |
Only the listed customers. An empty array, |
No, including for an empty array. |
|
A blank string, |
The customers returned by |
Yes. |
With the standard configuration, an asset owned by customer 42 produces the mapped result "42". That result restricts the Customer choices to its owner, so the fallback search is not used. Mapping customers to a Customer multiselect instead allows the customers listed in that field to be used for service work.
If prototype.map.customers is set to "", FSM uses prototype.customers. The standard search also finds the owner: in ${ asset.customer || 0 }, asset is the selected asset and asset.customer is its owner ID. The tag inserts that ID into the search filter, or 0 when no owner ID is present. A custom search can find a different permitted relationship, such as service providers linked to the Asset.
The search collection's array: true combines its results into an ID list, such as [42, 73]. FSM then uses those IDs to retrieve the Customer labels for the selector. Return IDs from this lookup, rather than Customer display objects.
Normal NetSuite access and field restrictions still apply when true removes the Asset-based filter. These settings define permitted candidates. An existing selection can be retained when a form first opens. For selection, sourcing, and saved-value behavior, see FSM Customer and Asset Selection.
models/case
The Case model represents supportcase. It provides Case defaults, automatic naming, company and Asset sourcing, and the project-closing option.
Standard default structure (JSON fragment):
{
"models/case": {
"prototype": {
"record": "supportcase",
"map": {
"name": "title",
"autoname": "formulatext:substr({custevent_nx_case_type}||' '||{casenumber}||' '||{custevent_nx_case_asset}, 1, 80)",
"company": "company.internalid|company",
"project": "formulatext:nvl2(nullif({company.internalid}, {custevent_nx_customer.internalid}), {company.internalid}, '')|",
"contact": "contact",
"email": "email",
"phone": "formulatext:''|phone",
"details": "custevent_nx_case_details",
"number": "casenumber",
"start": "startdate",
"end": "enddate",
"startdatetz": "custevent_nx_start_date",
"starttimetz": "custevent_nx_start_time",
"enddatetz": "custevent_nx_end_date",
"endtimetz": "custevent_nx_end_time",
"timezone": "custevent_nx_time_zone",
"assigned": "assigned",
"stage": "stage",
"status": "status",
"updatestatus": "custevent_nx_status_update",
"updateunbilled": "custevent_nx_unbilled_update",
"customer": "custevent_nx_customer",
"asset": "custevent_nx_case_asset",
"transaction": "custevent_nx_case_transaction",
"type": "custevent_nx_case_type",
"purchaseorder": "custevent_nx_case_purchaseorder",
"recurrence": "custevent_nx_recurrence",
"propagate": "custevent_nx_recurrence_propagate[boolean]",
"recurrencedata": "custevent_nx_recurrence_data[json]",
"id": "internalid"
},
"defaults": {
"starttimetz": 32400000
},
"autoclose": true
}
}
}
The native start-date and start-time formula mappings vary by account and are omitted from this fragment. prototype.map.subsidiary is "subsidiary" when Subsidiaries is enabled. The time default is shown in milliseconds before conversion to the account's display format.
|
Property |
Purpose |
Standard Default |
Effect and Dependencies |
|---|---|---|---|
|
|
Defines the generated Case title. |
Formula combining Case type, Case number, and Asset. Limited to 80 characters. |
A populated result replaces a different title when an FSM Case type is present. Set |
|
|
Defines the default FSM start time for a Case. |
|
Supplies the Case start time. FSM converts this value to the account's time display format. Default application also occurs on Activity initialization and validation when a type or Asset is present. |
|
|
Controls whether closing an eligible Case can automatically close its Project. |
|
Permits closing the linked project after a case with an FSM case type closes. The conditions described in this entry still apply. |
Standard relationship mappings include company: "company.internalid|company", customer: "custevent_nx_customer", asset: "custevent_nx_case_asset", transaction: "custevent_nx_case_transaction", and type: "custevent_nx_case_type". Other useful mappings include name: "title", number: "casenumber", details: "custevent_nx_case_details", contact: "contact", and email: "email". The phone mapping has a blank search result and a write destination of phone, because the Case phone is not searchable through that mapping.
The standard maps FSM start and end date/time fields separately from native Case start/end fields. It also maps status-update, unbilled-update, and recurrence data used by their processing. Preserve those distinctions. Recurrence settings belong in Configuring FSM Case and Task Recurrence and status rules in Configuring FSM Case and CRM Task Status Automation.
Automatic project closing requires an FSM Case type, a closed Case stage, and a Company that is a project. The closing branch applies when all of the following conditions are met:
-
No further programmed work remains.
-
The project has no end date.
-
programuntilis not a numeric rolling limit. -
The project is not already closed.
-
No linked case remains open.
It sets the project's closed status and end date. Further programmed work follows program processing instead. Changing autoclose does not disable that separate program branch.
This fragment prevents eligible Case closure from automatically closing its project:
{
"models/case": {
"prototype": {
"autoclose": false
}
}
}
The model also supports the Case invoice action and service report actions. Their action eligibility and results belong in the respective features. Invoice-specific configuration is under models/invoice, and report settings are in FSM Service Report Configuration.
models/consumable
The Consumable model represents customrecord_nx_consumable. It supports NetSuite Consumable validation and consumption processing. The FSM Mobile consumables resource has its own article definition.
Standard default structure (JSON fragment):
{
"models/consumable": {
"prototype": {
"record": "customrecord_nx_consumable",
"map": {
"task": "custrecord_nx_constask",
"case": "custrecord_nx_conscase",
"asset": "custrecord_nx_consasset",
"employee": "custrecord_nx_consemployee",
"item": "custrecord_nx_consitem",
"quantity": "custrecord_nx_consqty",
"billable": "custrecord_nx_consbillable",
"location": "custrecord_nx_conslocation",
"transaction": "custrecord_nx_constransaction",
"serial": "custrecord_nx_conserial",
"bin": "custrecord_nx_conbin",
"binnumber": "custrecord_nx_conbin#|",
"created": "<formuladate:{created}",
"id": "internalid"
},
"defaults": {}
}
}
}
prototype.map.pricelevel is generated when Multiple Prices is enabled. Its standard formula reads the Consumable price-level field, supplies Custom Price when blank, and leaves Item Groups without a price level. The following table describes the formula's effect.
|
Property |
Purpose |
Standard Mapping or Default |
|---|---|---|
|
|
Links to the job, Asset, and employee. |
|
|
|
Usage and billing data. |
|
|
|
Resulting transaction and inventory references. |
|
|
|
Price level used for a sales line. |
Conditional on Multiple Prices. Blank level is read as Custom Price, except Item Groups. |
|
|
Supplies default model attributes on creation. |
|
The billing rule can set billable status and price level during validation. A custom price result is represented by a blank Consumable price level. Related Sales Order processing handles the custom rate. A Consumable linked to a completed task and a Case can be queued for processing when it is not yet linked to a transaction. Preserve Task and transaction links when extending mappings. Billing rules belong in Configuring FSM Billing Rules and transaction-processing controls in Configuring FSM Consumable Processing.
models/contact
This model represents contact. Its standard map contains name: "entityid", email: "email", phone: "phone", and mobile: "mobilephone". prototype.defaults is empty. Project processing uses the Primary contact role when attaching a selected Contact.
Standard default structure (JSON fragment):
{
"models/contact": {
"prototype": {
"record": "contact",
"map": {
"name": "entityid",
"email": "email",
"phone": "phone",
"mobile": "mobilephone",
"id": "internalid"
},
"defaults": {}
}
}
}
Contact role IDs are product relationships, rather than an option for redefining roles through this model. Contact selection and attachment settings belong with Project contact configuration and the relevant record topic. A model mapping change does not alter a separate FSM Mobile Contact search.
models/customer
This model represents customer. Its eligibility settings work with models/asset to determine the Customer and Asset combinations available on supported FSM forms.
Standard default structure (JSON fragment):
{
"models/customer": {
"prototype": {
"record": "customer",
"map": {
"contact": "contactprimary.internalid|",
"email": "email",
"phone": "phone",
"assets": "formulatext:''",
"id": "internalid"
},
"defaults": {},
"assets": {
"array": true,
"asset": {
"all": true,
"record": "customrecord_nx_asset",
"filters": [
"custrecord_nx_asset_customer",
"anyof",
"${ customer.id }"
]
}
}
}
}
}
prototype.map.currency is "currency" when Multiple Currencies is enabled. It is omitted from this fixed-value fragment.
|
Property |
Purpose |
Standard Value |
Effect and Dependencies |
|---|---|---|---|
|
|
Controls which Assets can be selected for work against this customer. |
|
An empty value defers to the |
|
|
Defines the search used to find permitted assets when the mapped value is blank. |
|
Finds assets owned by the selected customer. Custom searches must return Asset IDs. Tags use the named |
|
|
Supplies default attributes when a Customer model is created. |
|
No explicit Customer model defaults. |
Other standard mappings are contact: "contactprimary.internalid|", email: "email", and phone: "phone". Currency is mapped when Multiple Currencies is enabled.
The model also looks up customer Item pricing for Time Bills and Consumables. Its pricing method is part of product processing. It is not a customer function-override recipe. Pricing depends on the enabled NetSuite pricing features and customer data. See Customer and Asset Eligibility for supported relationship configuration.
models/employee
This model represents employee. Standard mappings cover employee names and email, FSM labor cost, inventory location, work calendar, region, skills, coordinates, and FSM Mobile fields. The subsidiary mapping is present when Subsidiaries is enabled. The inventory mapping is custentity_nx_location, work calendar is custentity_nx_work_calendar, and skills are mapped as a multiselect through custentity_nx_skill[]. prototype.defaults is empty.
Standard default structure (JSON fragment):
{
"models/employee": {
"prototype": {
"record": "employee",
"map": {
"firstname": "firstname",
"middlename": "middlename",
"lastname": "lastname",
"email": "email",
"cost": "custentity_nx_labor_cost",
"password": "custentity_nx_password",
"newpassword": "|password",
"giveaccess": "giveaccess",
"mobileuser": "custentity_nx_mobile_user",
"inventory": "custentity_nx_location",
"workcalendar": "custentity_nx_work_calendar",
"region": "custentity_nx_region",
"skill": "custentity_nx_skill[]",
"latitude": "custentity_nx_latitude",
"longitude": "custentity_nx_longitude",
"id": "internalid"
},
"defaults": {}
}
}
}
prototype.map.subsidiary is "subsidiary" when Subsidiaries is enabled. It is omitted from this fixed-value fragment.
prototype.map.inventory maps the Employee inventory-location attribute to custentity_nx_location. It identifies the Employee field containing that location. The location value is set on the Employee record. Retain this mapping when using the standard FSM inventory-location field. It is separate from the Transaction prototype.inventory setting, which selects a line collection for bin, serial, and lot assignment conversion.
The model is used by Employee FSM Mobile-login notifications and account FSM Mobile-user lookup. Its FSM Mobile link includes the Employee email. Authentication and access fields are part of those product operations. These fields are not a recipe for bypassing access controls or moving credentials to another field.
Use FSM Mobile user-resource configuration to change which supporting resources an employee receives. Schedule Board employee selection and mapping have their own definition. Neither is configured by adding filters or resources to models/employee.
models/expensereport
The Expense Report model represents expensereport and inherits the Transaction model's common body mapping and transaction behavior. Its explicit prototype.defaults is empty.
Standard default structure (JSON fragment):
{
"models/expensereport": {
"prototype": {
"record": "expensereport",
"map": {
"id": "*formulatext:case when {line} > 0 then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum|",
"paymentmethod": "paymentmethod",
"expenses": [
{
"entity": "customer.internalid|expense.customer",
"memo": "formulatext:REPLACE({memo}, {expensecategory}||': ')|expense.memo",
"amount": "amount|expense.amount",
"category": "expensecategory|expense.category",
"billable": "billable|expense.isbillable",
"taskcol": "custcol_nx_task|expense.custcol_nx_task",
"asset": "custcol_nx_asset|expense.custcol_nx_asset",
"foreignamount": "custcol_nx_foreignamount|expense.foreignamount"
}
]
},
"defaults": {},
"syncentity": false,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
The inherited Project and Project Task mappings vary with Project Management. See models/transaction for their exact values.
Its prototype.map.expenses array maps expense lines: Customer through customer.internalid|expense.customer, memo to expense.memo, amount to expense.amount, category to expense.category, billable to expense.isbillable, Task to expense.custcol_nx_task, Asset to expense.custcol_nx_asset, and foreign amount to expense.foreignamount.
Preserve the complete line array when extending it. An incomplete editable line collection can remove existing lines when saved. The model's after-submit behavior updates Case unbilled amounts when a Case link is present. Expense billing rules and FSM Mobile Expense form defaults are separate from this model mapping. See FSM Searches and Field Mapping for sublist syntax and Configuring FSM Billing Rules for billing rules.
models/invoice
The Invoice model represents invoice and inherits the Transaction base. It enables entity synchronization, adds Item lines and the purchase-order field, and initializes subsidiary during creation. Its explicit prototype.defaults is empty.
Standard default structure (JSON fragment):
{
"models/invoice": {
"prototype": {
"record": "invoice",
"map": {
"id": "*formulatext:case when {line} > 0 then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum",
"paymentmethod": "paymentmethod",
"items": [
{
"item": "item|item.item",
"quantity": "quantity|item.quantity",
"entity": "entity|item.entity",
"rate": "rate|item.price",
"task": "custcol_nx_task|item.custcol_nx_task"
}
]
},
"defaults": {},
"applyCaseTimeExpenseOnly": true,
"syncentity": true,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
The inherited Project and Project Task mappings vary with Project Management. See models/transaction for their exact values.
|
Property |
Purpose |
Standard Default |
Effect and Dependencies |
|---|---|---|---|
|
|
Controls whether automatically applied Time and Expense lines are limited to the invoice's Case. |
|
On invoice creation, applies eligible Time and Expense lines whose Task belongs to the invoice's Case. When |
The Item map contains Item, quantity, entity, rate, and Task fields. These map to the Item sublist. The standard purchase-order map is otherrefnum.
Turning off applyCaseTimeExpenseOnly can include billable time and expenses for other work available to the invoice's customer or project. Confirm the invoice's scope and resulting lines before using the change.
The Case action selects an eligible Sales Order transformation when possible, or creates an invoice with the Case's customer and other context. The model does not submit an invoice when it finds no applicable lines. Do not use an empty custom line map to change invoice eligibility. Invoice action behavior belongs in the relevant feature. The exact Case button settings belong in FSM NetSuite View Configuration.
models/itemfulfillment
The Item Fulfillment model represents itemfulfillment and inherits the Transaction base. It sets prototype.inventory to "items". prototype.defaults is empty. Its map adds the source transaction, read-only shipping address, and Item line information.
Standard default structure (JSON fragment):
{
"models/itemfulfillment": {
"prototype": {
"record": "itemfulfillment",
"map": {
"id": "*formulatext:case when {account} is null and lower({item.type.id}) not in ('taxitem', 'taxgroup', 'shipitem') then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum|",
"paymentmethod": "paymentmethod",
"address": "shipaddress|",
"items": [
{
"item": "item|item.item",
"line": "line|item.line",
"orderline": "|item.orderline",
"quantityremaining": "formulanumeric:abs({quantity})|item.quantityremaining",
"quantity": "formulanumeric:abs({quantity})|item.quantity",
"location": "location|item.location",
"asset": "custcol_nx_asset|item.custcol_nx_asset",
"task": "custcol_nx_task|item.custcol_nx_task",
"consumable": "custcol_nx_consumable|item.custcol_nx_consumable"
}
]
},
"defaults": {},
"syncentity": false,
"inventory": "items"
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
The inherited Project and Project Task mappings vary with Project Management. See models/transaction. The Item-line mappings isbinitem, usesbins, isserialitem, and islotitem are generated according to the enabled bin, serial, lot, and advanced inventory features and are omitted from this fixed-value fragment.
The Item map contains Item, line, order-line reference, remaining quantity, quantity, location, Asset, Task, and Consumable links. Bin, serial, and lot properties are added according to enabled inventory features. Quantity mappings read absolute quantities. The model initializes inventory location during creation.
Fulfillment processing controls which transformed lines are received or fulfilled and validates the inventory assignments needed for each selected line. Invalid or missing assignments can leave a line out of the fulfillment. When no lines remain, no fulfillment is submitted. Preserve line identities and inventory feature dependencies.
This reference does not supply a custom fulfillment function or a generic model-copy procedure. Adding record: "itemfulfillment" to a new FSM Mobile article does not establish the specialized model's behavior.
models/journal
This Journal Entry model represents journalentry and uses Transaction behavior with its own body and lines map. The line map includes entity, account, Asset, Task, credit, debit, and memo, with department, class, and location when their features are enabled. Subsidiary is conditional. There is no additional Journal default object beyond inherited empty model defaults.
Standard default structure (JSON fragment):
{
"models/journal": {
"prototype": {
"record": "journalentry",
"map": {
"id": "*internalid",
"type": "recordtype",
"date": "trandate",
"lines": [
{
"entity": "entity|line.entity",
"account": "account|line.account",
"asset": "custcol_nx_asset|line.custcol_nx_asset",
"task": "custcol_nx_task|line.custcol_nx_task",
"credit": "creditamount|line.credit",
"debit": "debitamount|line.debit",
"memo": "memo|line.memo"
}
]
},
"defaults": {},
"syncentity": false,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
prototype.map.subsidiary is "subsidiary" when Subsidiaries is enabled. Line mappings for department, class, and location are added when their respective features are enabled. These conditional entries are omitted from the fragment.
Use prototype.defaults.customform to supply the form for Journal Entries created through this model. See Custom Forms for Record Creation. Labor recovery uses the accounting controls described in Configuring FSM Project Labour Cost Posting. Changing Journal line mappings can alter accounting entries and Task or Asset attribution. Use the accounting feature and record topics for the resulting journal and costing relationships.
models/opportunity
This model represents opportunity and derives from Transaction. Its baseline enables entity synchronization and adapts the transaction map for Opportunity searches. It uses a different ID formula based on lineitem. Project writes to job when Project Management is enabled and otherwise to entity. Unsupported inherited search columns for created-from data, email, contact, and purchase order are removed. Defaults remain inherited and empty.
Standard default structure (JSON fragment):
{
"models/opportunity": {
"prototype": {
"record": "opportunity",
"map": {
"id": "*formulatext:case when {lineitem} is null then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"paymentmethod": "paymentmethod"
},
"defaults": {},
"syncentity": true,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
prototype.map.project is "|job" with Project Management and "|entity" without it. The inherited prototype.map.projecttask is "custbody_nx_projecttask" when Project Management is enabled. These conditional entries are omitted from the fragment.
Use prototype.defaults.customform to supply the form for Opportunities created through this model. See Custom Forms for Record Creation. Use the Opportunity record and FSM view definitions for the supported integration. Replacing the adaptations with the generic Transaction map can introduce invalid Opportunity search columns.
models/project
The Project model represents job. It supports Project creation, naming, customer/Asset relationships, contact synchronization, and program-related data.
Standard default structure (JSON fragment):
{
"models/project": {
"prototype": {
"record": "job",
"map": {
"id": "internalid",
"start": "startdate",
"end": "enddate",
"timezone": "custentity_nx_time_zone",
"name": "companyname",
"autoname": "formulatext:substr({custentity_nx_project_type}||' '||(case when {entityid} like '% : '||{companyname} then {internalid}||'' else {entityid} end)||' '||{custentity_nx_asset}, 1, 80)",
"parent": "formulatext:''|parent",
"customer": "custentity_nx_customer",
"asset": "custentity_nx_asset",
"contact": "contactprimary.internalid|contact",
"email": "contactprimary.email|",
"phone": "contactprimary.phone|",
"status": "entitystatus",
"type": "custentity_nx_project_type",
"assetlabel": "custentity_nx_asset#",
"programstart": "custentity_nx_start_date",
"programuntil": "custentity_nx_program_create_until",
"updatecontacts": "custentity_nx_contact_update"
},
"defaults": {
"status": 2,
"allowexpenses": true,
"updatecontacts": true
},
"address": {
"record": "customer",
"filters": [
"internalid",
"anyof",
"${ project.customer || 0 }"
],
"map": {
"id": "<addressinternalid",
"label": "addresslabel",
"defaultbilling": "isdefaultbilling",
"defaultshipping": "isdefaultshipping",
"isresidential": "isshipaddress",
"addressbookaddress": {
"attention": "attention",
"addressee": "addressee",
"addrphone": "addressphone",
"addr1": "address1",
"addr2": "address2",
"addr3": "address3",
"city": "city",
"state": "state",
"zip": "zipcode",
"country": "country"
}
}
}
}
}
}
The three preference defaults that vary with enabled features and optional Subsidiary and Currency mappings are omitted from this fixed-value fragment. Their conditions are described in this entry. The address object retains the complete standard address-search structure.
|
Property |
Purpose |
Standard Value |
Effect and Dependencies |
|---|---|---|---|
|
|
Defines the generated Project name. |
Formula using Project type, the project identifier, and Asset, limited to 80 characters. |
Supplies an automatic company name for a typed FSM Project. Set |
|
|
Supplies the initial Project status. |
|
Initial In Progress status. |
|
|
Controls whether the Project permits expense entry. |
|
Enables expense entry. |
|
|
Supplies the Project's expense-type preference. |
Whether Job Costing and Project Budgeting is enabled. |
Supplies the Project expense preference. |
|
|
Supplies the Project's task-resource preference. |
Whether Project Management is enabled. |
Supplies the Project resource preference. |
|
|
Supplies the Project's assignee restriction for time entry. |
Whether Project Management is disabled. |
Supplies the Project time-entry restriction. |
|
|
Requests synchronization of the Project's contacts. |
|
Requests contact synchronization for a new or newly initialized typed FSM Project. Validation handles this processing flag separately from ordinary defaults. |
|
|
Defines the Customer addresses available to populate the Project address book. |
Customer-address search filtered to |
Supplies address-book entries on server-side validation of a typed Project without Project Management, except inline editing. Narrow the search to relevant addresses when the customer has many addresses. Retain the complete required address data. |
The map includes name: "companyname", customer: "custentity_nx_customer", asset: "custentity_nx_asset", type: "custentity_nx_project_type", status: "entitystatus", start: "startdate", end: "enddate", and timezone: "custentity_nx_time_zone". Contact is read from the primary contact and written to contact. Contact email and phone are read-only mappings. Subsidiary and currency depend on enabled NetSuite features.
The standard parent mapping returns a blank search value but writes to parent. It is not a searchable Project-parent relationship. Preserve that distinction in searches.
Typed Projects apply defaults during initialization and validation. Non-Boolean defaults fill empty values. Boolean defaults can replace existing values. updatecontacts has its own timing conditions and is not a general instruction to repeatedly set a processing flag on all Projects.
The address search returns ID, label, billing/shipping markers, residential marker, and an addressbookaddress object containing attention, addressee, phone, address lines, city, state, postal code, and country. Its named template context is project. General search syntax belongs in FSM Searches and Field Mapping. Use the relevant configuration and feature topics for program rules, accounting controls, and contact synchronization behavior.
models/projecttask
This model represents projecttask and inherits Activity mappings and sourcing. It adds number: "custevent_nx_task_number" and maps subsidiary from the Project when Subsidiaries is enabled. Its explicit prototype.defaults is empty.
Standard default structure (JSON fragment):
{
"models/projecttask": {
"prototype": {
"record": "projecttask",
"map": {
"name": "title",
"company": "company",
"project": "formulatext:nvl2(nullif({company.internalid}, {custevent_nx_customer.internalid}), {company.internalid}, '')|",
"status": "status",
"priority": "priority",
"message": "message",
"type": "custevent_nx_task_type",
"customer": "custevent_nx_customer",
"asset": "custevent_nx_task_asset",
"address": "custevent_nx_address",
"latitude": "custevent_nx_latitude",
"longitude": "custevent_nx_longitude",
"timezone": "custevent_nx_time_zone",
"id": "internalid",
"number": "custevent_nx_task_number"
},
"defaults": {}
}
}
}
The fragment includes the inherited Activity map. prototype.map.subsidiary is "job.subsidiary|" when Subsidiaries is enabled. It is omitted from the fragment.
The standard Company relationship permits a Project, rather than a Customer. The model clears its generated number on copy and uses the new internal ID when numbering the resulting record. Preserve the Project relationship. It determines customer and Asset sourcing. Project Task scheduling and assignment data have their own Schedule Board and FSM Mobile definitions.
Service report actions use Project Task notification definitions. Configure report templates and buttons through FSM Service Report Configuration, rather than adding report properties to this model.
models/quote
This Quote model represents estimate. It inherits Transaction maps, empty defaults, and processing, and enables entity synchronization. NetSuite Quote form components use it.
Standard default structure (JSON fragment):
{
"models/quote": {
"prototype": {
"record": "estimate",
"map": {
"id": "*formulatext:case when {line} > 0 then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum|",
"paymentmethod": "paymentmethod"
},
"defaults": {},
"syncentity": true,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
The fragment includes the inherited Transaction map. Project and Project Task mappings vary with Project Management. See models/transaction.
Use prototype.defaults.customform to supply the form for Quotes created through this model. See Custom Forms for Record Creation. The FSM Mobile quote resource defines its own article and specialized processing. It does not select models/quote simply because its record type is estimate. Use the FSM Mobile resource and the Quote feature configuration for supported changes, preserving creation or transformation behavior and downstream links.
models/salesorder
This Sales Order model represents salesorder and inherits Transaction behavior. It enables entity synchronization and adds an Item line map containing Item, quantity, entity, rate, and Task. The standard purchase-order mapping is otherrefnum.
Standard default structure (JSON fragment):
{
"models/salesorder": {
"prototype": {
"record": "salesorder",
"map": {
"id": "*formulatext:case when {line} > 0 then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum",
"paymentmethod": "paymentmethod",
"items": [
{
"item": "item|item.item",
"quantity": "quantity|item.quantity",
"entity": "entity|item.entity",
"rate": "rate|item.price",
"task": "custcol_nx_task|item.custcol_nx_task"
}
]
},
"defaults": {
"orderstatus": "B",
"iscrosssubtransaction": true
},
"syncentity": true,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
The inherited Project and Project Task mappings vary with Project Management. See models/transaction for their exact values.
Its creation defaults are orderstatus: "B" and iscrosssubtransaction: true. These are the processing model's defaults, not a universal promise about the initial state of every Sales Order created through FSM Mobile. The model can add Consumable lines with inventory and pricing data, update the linked case, and unlink Consumables when the Sales Order is destroyed.
Use prototype.defaults.customform to supply the form for Sales Orders created through this model. See Custom Forms for Record Creation. The FSM Mobile salesorder article has separate fulfillment and synchronization behavior. Changing this model or copying the FSM Mobile resource's visible JSON does not establish that a new resource will retain that behavior.
models/task
The CRM Task model represents task and inherits Activity mapping and sourcing. It provides automatic naming, time defaults, job links, and Task-specific processing.
Standard default structure (JSON fragment):
{
"models/task": {
"prototype": {
"record": "task",
"map": {
"name": "title",
"company": "company",
"project": "formulatext:nvl2(nullif({company.internalid}, {custevent_nx_customer.internalid}), {company.internalid}, '')|",
"status": "status",
"priority": "priority",
"message": "message",
"type": "custevent_nx_task_type",
"customer": "custevent_nx_customer",
"asset": "custevent_nx_task_asset",
"address": "custevent_nx_address",
"latitude": "custevent_nx_latitude",
"longitude": "custevent_nx_longitude",
"timezone": "custevent_nx_time_zone",
"id": "internalid",
"autoname": "formulatext:substr({custevent_nx_task_type}||' '||{custevent_nx_task_number}||' '||{custevent_nx_task_asset}, 1, 80)",
"number": "custevent_nx_task_number",
"start": "starttime",
"date": "startdate",
"startdatetz": "custevent_nx_start_date",
"starttimetz": "custevent_nx_start_time",
"enddatetz": "custevent_nx_end_date",
"endtimetz": "custevent_nx_end_time",
"duedate": "duedate",
"completed": "custevent_nx_task_end",
"booking": "custevent_nx_task_booking_confirmed",
"assigned": "assigned",
"case": "case.internalid|supportcase",
"team": "custevent_nx_task_team[]",
"skill": "custevent_nx_task_skill[]",
"timedevent": "formulatext:NVL2({starttime}, 'T', 'F')|timedevent",
"billing": "custevent_nx_billing_type",
"actions": "custevent_nx_actions_taken"
},
"defaults": {
"starttimetz": 32400000,
"endtimetz": 61200000
}
}
}
}
The fragment includes the inherited Activity map. prototype.map.end uses a formula generated with the account's time format, and prototype.map.subsidiary is added when Subsidiaries is enabled. These generated entries are omitted. Time defaults are shown in milliseconds before conversion to the account's display format.
|
Property |
Purpose |
Standard Default |
Effect and Dependencies |
|---|---|---|---|
|
|
Defines the generated CRM Task title. |
Formula combining Task type, generated Task number, and Asset. Limited to 80 characters. |
Replaces a different title when an FSM Task type is present. Set |
|
|
Defines the default FSM start time for a CRM Task. |
|
Default FSM start time. |
|
|
Defines the default FSM end time for a CRM Task. |
|
Default FSM end time. |
FSM converts the time defaults to the account's display format. This fragment changes the time defaults to 08:00 and 16:00.
{
"models/task": {
"prototype": {
"defaults": {
"starttimetz": 28800000,
"endtimetz": 57600000
}
}
}
}
The values are numbers representing time of day, not time zone offsets. The time defaults do not reschedule every existing task. These values also supply defaults used by program generation. Check newly created tasks, program-generated tasks, and relevant form initialization or validation paths. Activity default application requires a type or Asset. Boolean defaults on that path can replace an existing value.
Standard mappings include number: "custevent_nx_task_number", assigned: "assigned", case: "case.internalid|supportcase", team: "custevent_nx_task_team[]", skill: "custevent_nx_task_skill[]", billing: "custevent_nx_billing_type", and actions: "custevent_nx_actions_taken". duedate maps to the standard Task duedate field. Booking and completion map to custevent_nx_task_booking_confirmed and custevent_nx_task_end.
Native date, start, and end are distinct from the FSM start/end date and time attributes. On model creation, supplied native date/time attributes are translated to the FSM date/time attributes, and an omitted assignee becomes unassigned. Preserve the relationship between these fields and time zone processing. The model removes the lead assignee from the additional team list. When no project is selected, the model sources the case's customer and asset. A customer or asset change can clear the case link if the values no longer match.
Billing defaults, consumable processing, and service report actions use their own configuration. Changing a Task model map does not replace Schedule Board event mapping or an FSM Mobile Details article map.
models/time
The Time Bill model represents timebill. Its explicit prototype.defaults is empty. It supports NetSuite Time Bill validation, billing, and Case unbilled updates.
Standard default structure (JSON fragment):
{
"models/time": {
"prototype": {
"record": "timebill",
"map": {
"employee": "employee",
"date": "date|trandate",
"duration": "durationdecimal|hours",
"rate": "rate",
"billable": "isbillable",
"item": "item.internalid|item",
"price": "item.baseprice|",
"memo": "memo",
"cost": "custcol_nx_time_cost",
"costed": "custcol_nx_time_costed",
"billed": "custcol_nx_time_billed",
"status": "status",
"task": "task.internalid|casetaskevent",
"project": "customer",
"taskcol": "custcol_nx_task",
"asset": "custcol_nx_asset",
"id": "internalid"
},
"defaults": {}
}
}
}
prototype.map.pricelevel is "formulatext:''|price" when Override Time Rates is enabled. Location, department, and class mappings are added when their respective features are enabled. These conditional entries are omitted from the fragment.
|
Property |
Purpose |
Standard Mapping or Default |
|---|---|---|
|
|
Employee who performed the work. |
|
|
|
Reads the date and writes the transaction date. |
|
|
|
Reads decimal duration and writes hours. The model also converts an hours-and-minutes value to decimal hours. |
|
|
|
Native event relationship. |
|
|
|
FSM Task and Asset references used by billing and costing. |
|
|
|
Customer or Project entity. |
|
|
|
Billing data. |
|
|
|
Costing and processing data. |
|
Price level mapping is present when Override Time Rates is enabled. Department, class, and location mappings depend on the corresponding NetSuite features. Billing rules can recalculate billable status and, with Multiple Prices and Override Time Rates, rate and price level. Changing a displayed field or a default does not prevent that recalculation.
Keep the native event link and FSM Task column distinct. Validation synchronizes the Task column for supported CRM Task relationships. Case invoicing and labor recovery use that column. Billing controls belong in Configuring FSM Billing Rules and labor-cost posting controls in Configuring FSM Project Labour Cost Posting. The FSM Mobile times resource supplies its own article map and element defaults.
models/transaction
This is the common Transaction base, with record identity transaction. It supports transaction reading and record-specific processing and is the transaction base available to FSM Mobile articles through article.extend: "models/transaction".
Standard default structure (JSON fragment):
{
"models/transaction": {
"prototype": {
"record": "transaction",
"map": {
"id": "*formulatext:case when {line} > 0 then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum|",
"paymentmethod": "paymentmethod"
},
"defaults": {},
"syncentity": false,
"inventory": false
}
}
}
prototype.map.project is "job.internalid|job" with Project Management and "job.internalid|entity" without it. prototype.map.projecttask is "custbody_nx_projecttask" when Project Management is enabled. These conditional entries are omitted from the fragment.
Transaction Mappings and Processing Properties
The following table describes the transaction model's mappings and processing properties.
|
Property |
Purpose |
Standard Value |
Effect and Dependencies |
|---|---|---|---|
|
|
Identifies the transaction to which each returned line belongs. |
Merged transaction ID derived from non-mainline rows. |
Combines transaction lines into one mapped object. Preserve a populated merge key for the rows to retain. |
|
|
Identifies the actual transaction record type. |
Transaction record type, or lowercase transaction type. |
Identifies the actual type used for supported writes. |
|
|
Identifies the source transaction used for transformation. |
Source transaction and its record type. |
Supports creation by transformation. |
|
|
Identifies the transaction's entity, Customer, and Project relationships. |
Native entity, FSM customer, and Project mapping. Project writes to |
Preserves customer/Project sourcing. |
|
|
Links the transaction to FSM service records. |
|
FSM transaction relationships. |
|
|
Keeps the native Entity and FSM Customer values consistent, accounting for Project relationships. |
|
|
|
|
Identifies the line collection whose bin, serial, and lot assignments FSM converts to and from NetSuite inventory fields. |
|
|
|
|
Supplies default attributes when a Transaction model is created. |
Inherited empty defaults. |
No additional explicit Transaction defaults. |
Assignment conversion depends on enabled NetSuite inventory features and the line mappings. This property does not control stock availability or fulfillment.
syncentity and inventory control built-in transaction processing. Retain each model's standard values unless a supported feature configuration specifies a change. Their appearance in a default fragment does not establish these properties as general customization switches. Employee prototype.map.inventory is a separate field mapping. See models/employee.
Project Task mapping is added when Project Management is enabled. The base also supplies date, status, email, primary contact, purchase-order reference, and payment-method mappings. Individual transactions adapt mappings where fields differ or are not searchable.
In dynamic mode, the transaction base preserves selected fields whose values depend on the entity when the entity changes. The base also handles item group end lines. When a line map includes line identity, the base uses that identity to update lines. Inventory assignment conversion depends on enabled bin, serial, lot, and advanced inventory features. Those built-in processors and their maps are not a procedure for copying internal functions.
Saving a complete editable sublist can remove lines missing from the supplied collection. Preserve all lines that must remain, their identities, and their read-only state. Use FSM Searches and Field Mapping for sublist mapping requirements.
Selecting this base for an FSM Mobile article retains the transaction base. It does not automatically select the Sales Order, Invoice, Item Fulfillment, or other specialized model, nor does it recreate a standard resource's own synchronization behavior.
models/transferorder
The Transfer Order model represents transferorder and inherits Transaction behavior. Its explicit defaults are empty. It supplies a Transfer Order ID formula that excludes linked transfer lines, maps status to orderstatus, maps the requestor to employee, and maps from: "location" and to: "transferlocation". The Item array maps Item and absolute quantity to the Item sublist.
Standard default structure (JSON fragment):
{
"models/transferorder": {
"prototype": {
"record": "transferorder",
"map": {
"id": "*formulatext:case when {line} > 0 and {transferorderitemline} is null then {internalid} end|internalid",
"type": "formulatext:nvl({recordtype}, lower({type}))",
"createdfrom": "createdfrom",
"createdfromtype": "createdfrom.recordtype|",
"entity": "entity",
"customer": "custbody_nx_customer",
"asset": "custbody_nx_asset",
"case": "custbody_nx_case",
"task": "custbody_nx_task",
"status": "status|orderstatus",
"date": "trandate",
"email": "email",
"contact": "contactprimary.internalid|",
"purchaseorder": "otherrefnum|",
"paymentmethod": "paymentmethod",
"firmed": "firmed",
"employee": "requestor.internalid|employee",
"from": "location",
"to": "transferlocation",
"items": [
{
"item": "item|item.item",
"quantity": "formulanumeric:abs({quantity})|item.quantity"
}
]
},
"defaults": {},
"syncentity": false,
"inventory": false
}
}
}
For the meaning of the inherited syncentity and inventory properties and guidance on changing these properties, see Transaction Mappings and Processing Properties.
The inherited Project and Project Task mappings vary with Project Management. See models/transaction for their exact values.
Transfer Order form components use this model. FSM Mobile order, return, and receive resources have separate article definitions and transaction processing. Preserve source and destination locations and the relevant transformation, fulfillment, or receipt path. A model map change does not define a complete new FSM Mobile transfer workflow.
Customer and Asset Eligibility
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 while retaining the owner field separately. 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. Do not 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. Replace the illustrative record and field IDs with the account's actual IDs. It replaces the inherited owner searches with relationship searches:
{
"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. customer: null and asset: null 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.
Related Operational References
For performance measurement and data capture, see FSM Performance and Data Collection. For deployment controls and processing indicators, see FSM Script Reference.
Excluded Models
The following model definitions exist in the product but are outside the customer configuration covered by this reference. Retain their product defaults and use the applicable record, feature, or resource configuration for the associated behavior. Their omission from the Model Index does not mean the corresponding records are absent from FSM.
|
Model |
Reason for Exclusion |
Related Configuration |
|---|---|---|
|
|
No customer model-override procedure is covered here. Operational Item sources are defined elsewhere. |
Item selection, inventory searches, and Asset generation use their applicable feature, search, and resource definitions. |
|
|
No customer model-override procedure is covered here. The model contains product-level Subsidiary loading behavior. |
Use NetSuite subsidiary setup and supported FSM time-zone configuration. |
|
|
No customer model-override procedure is covered here. The model supports product time-zone lookups. |
Use the supported FSM time-zone controls and applicable records. |
Related Topics
- FSM Configuration Reference
- FSM Expressions and Template Tags
- FSM Searches and Field Mapping
- FSM NetSuite View Configuration
-
FSM Notification Configuration and FSM Service Report Configuration: email and PDF settings.
- FSM Mobile Resource Properties Reference
-
Configuring FSM Asset Hierarchy and Inheritance and Configuring FSM Service Locations and Geocoding: service coordinates and parent/child Asset values.
-
Configuring FSM Billing Rules and Configuring FSM Consumable Processing: billable results and Consumable transaction processing.
-
Configuring FSM Case and CRM Task Status Automation, Configuring FSM Program, and Configuring FSM Case and Task Recurrence: work generation, recurrence, and status rules.
- Configuring FSM Project Labour Cost Posting
Additional Information
- FSM Configuration
-
FSM Records and the relevant FSM Features: record meanings and operational behavior.