FSM Customer Record

A customer identifies the person or organization associated with service work in Field Service Management (FSM). FSM uses the standard NetSuite customer record for customer identity, contacts, addresses, and pricing context. Assets, projects, cases, tasks, and transactions hold their own references to the customer.

The customer that owns an asset can differ from the customer selected for service work and billing. For example, an equipment owner and a service provider can have separate customer records. The customer and asset selection configuration determines which pairings are available. Allowing a pairing doesn't transfer asset ownership.

Record Information

The following table summarizes the customer record identifiers.

Property

Value

Record type

Standard NetSuite

Record name

Customer

Record ID

customer for record operations and customer searches

Record identity

NetSuite Internal ID (internalid)

Customer identifier

Customer ID (entityid), separate from the Internal ID

FSM record model

models/customer

Customer, Company, Entity, and Parent can be labels or relationship fields on other records. Their labels don't identify a separate FSM customer record type. A project uses the separate native record ID job.

For information about entering customer records, see Creating a Customer Record. For native customer fields, refer to the Customer Records Browser.

Forms

Use a standard NetSuite customer form or an account-created custom customer form to present the relevant customer information. The supplied FSM form definitions don't include a separate customer form. FSM adds the Field Service subtab and related information to customer records. The fields, lists, and actions available to a user depend on the form, account configuration, and access.

NetSuite form and role preferences determine the preferred customer entry form. If a custom customer entry form uses Store Form with Record, NetSuite retains that form for records created with it. NetSuite also uses the retained form when those records are reopened. Form options vary by form type. See Defining Preferred Forms and Custom Entry Form Properties.

The standard FSM Mobile Contacts resource uses explicit field definitions and is read-only. When the standard FSM Mobile Contacts resource displays customer fallback details, it doesn't load the customer's stored UI form. When a resource generates FSM Mobile elements from a NetSuite form, form loading and field overrides are independent of the business record's retained form. See Form Properties.

Record Relationships

The relationship field is stored on the record that holds the reference. Several assets and service records can reference the same customer.

The following table describes customer relationships with other records.

Related record

Relationship and field ID

Purpose

Parent Customer

The child customer's native Parent (parent) references another customer.

Represents the customer hierarchy. This relationship doesn't automatically include subcustomer assets in FSM's default owned-asset selection.

Contact

The customer's native Contacts sublist (contactroles) holds Contact and Role relationships. contact identifies its primary contact. FSM reads the primary relationship through the search join contactprimary.internalid.

Supplies existing contacts and primary-contact context. The customer's own Email and Phone remain separate values.

Field Service Asset

The asset's Customer (custrecord_nx_asset_customer) references one primary customer.

Identifies the owner and supplies address-book choices. Several assets can reference the same customer.

Additional Asset Customers

The asset's Field Service Customers (custrecord_nx_asset_customers) stores multiple customer references.

Records additional customer relationships. Using these relationships to permit service customers requires the corresponding customer and asset selection configuration.

Project

The project's Field Service Customer (custentity_nx_customer) references the customer. Its native Parent (parent) can identify the customer or another project.

Keeps the service customer identifiable within the project hierarchy.

Case and CRM Task

Each record's Field Service Customer (custevent_nx_customer) references the customer. Native Company (company) can contain the customer directly or a project.

Keeps the customer available separately when Company identifies a project.

Project Task

The project task's Field Service Customer (custevent_nx_customer) references the customer. Native Company (company) identifies its project.

Retains customer context for work under the project.

Service transaction

Field Service Customer (custbody_nx_customer) on transactions such as estimates, sales orders, and invoices references the customer. Native Entity (entity) and Project (job, where applicable) are separate relationships.

Retains service-customer context alongside the transaction's native billing relationships.

Field Service Language

Customer Field Service Language (custentity_fsm_language) references customrecord_fsm_language.

Supplies the language choice used by customer-related service notifications and reports.

Field Service Customer is stored on the related project, case, task, or transaction. It is not an additional customer field on the customer record itself.

Account-specific service-provider fields or association records can define permitted customer and asset relationships. A custom link doesn't automatically participate in FSM selection, inheritance, FSM Mobile resources, history, reports, or synchronization. See FSM Customer and Asset Selection and Configuring FSM Customer and Asset Selection.

FSM Fields

The following tables describe customer fields used by FSM. The tables don't include every native CRM field. Field labels can vary by account.

Identity and Communication

The following table describes identity and communication fields.

Field

Field ID

Purpose and important values

Internal ID

internalid

Identifies the saved customer in searches and record relationships. Use this identity when a relationship requires a customer internal ID.

Customer ID

entityid

User-facing name or number. It is distinct from the Internal ID and can reflect NetSuite numbering settings.

Company Name, First Name, Last Name

companyname, firstname, lastname

Supply names for FSM customer selectors and FSM Mobile contact display.

Type

isperson

Distinguishes a Company from an Individual. Native entry fields and some FSM Mobile contact-selection requirements depend on this distinction.

Inactive

isinactive

Native inactive state. Relevant FSM customer selectors exclude inactive candidates. Existing references and historical service data remain separate from current selection choices.

Status

entitystatus

Native customer lifecycle status. It is separate from case or task Status and doesn't itself establish FSM service eligibility.

Primary Contact

contact, search join contactprimary.internalid

Identifies the primary contact relationship. The joined Internal ID is a search value, not a customer field to write directly.

Email, Phone, Mobile Phone

email, phone, mobilephone

Customer-level communication details. FSM can use Email and Phone as case fallback details. The FSM Mobile customer fallback also reads Mobile Phone. These fields don't replace the corresponding fields on a contact.

Field Service Language

custentity_fsm_language

Stored FSM language selection. The supplied field is optional and has no default selection. With Multi-Language enabled, it is the first language source for customer-related service notifications and template-generated report attachments. A blank value permits the applicable subsidiary and account fallbacks.

Language (native)

language

Native customer language preference in NetSuite for printed transaction forms. It is separate from Field Service Language used by FSM.

Customer language doesn't select the technician's FSM Mobile interface language. See FSM Localization and Translation and Configuring FSM Localization and Translation for language sources, fallback rules, and setup.

Addresses

The customer address book can hold several service and billing addresses. An asset stores its own Address Select (custrecord_nx_asset_address) and saved address text (custrecord_nx_asset_address_text). Address Select uses the primary customer's address book. The asset's additional customers don't add their addresses to that list.

The following table distinguishes stored address-book data from the customer search columns used by FSM. For the native subrecord fields, see the Address Records Browser.

Data

Native record location or field ID

FSM Customer search value

Address entry and label

Customer addressbook sublist, entry internalid and label

addressinternalid and addresslabel

Address details

Address subrecord addressbookaddress, addr1, addr2, addr3, city, state, zip, country

address1, address2, address3, city, state, zipcode, country

Attention, addressee, and address phone

Address subrecord attention, addressee, addrphone

attention, addressee, addressphone

Default billing and shipping markers

Address-book defaultbilling, defaultshipping

isdefaultbilling, isdefaultshipping

Formatted address

Address subrecord addrtext

address. FSM also builds service-address text from the address components

An address-entry ID is not the customer's Internal ID. Likewise, a search column such as address1 is not the subrecord field ID addr1.

After changing a customer address, don't assume that every asset or historical task has been updated. Address sourcing and subsequent updates from assets to tasks have separate triggers and scopes. See FSM Service Locations and Geocoding. A typed project can also receive customer address-book entries through the applicable project validation path when Project Management is disabled. See FSM Record Model Configuration - Project.

Pricing and Transaction Context

The following table describes pricing and transaction data.

Field or data

Field ID or sublist

Purpose in FSM

Currency

currency

Provides customer currency context for pricing. The customer model includes this mapping when Multiple Currencies is enabled.

Primary Subsidiary

subsidiary

Native OneWorld customer context. Transaction use is also subject to the customer's subsidiary relationships and applicable NetSuite features.

Price Level

pricelevel

Native customer pricing preference.

Item Pricing, Group Pricing

itempricing, grouppricing

Native pricing data that can affect customer item-price lookup. These are sublists, not FSM processing-status fields.

Customer pricing can affect supported time and consumable pricing. Billability depends separately on the Billing Rule on the CRM task and the applicable billing configuration. The supplied customer field definitions don't include a billing-rule field. See FSM Billing Rules and FSM Record Model Configuration - Customer.

The customer model's assets value represents permitted asset choices. In the standard configuration, the assets value is derived from an asset search rather than stored in an FSM customer field. Detailed mappings and relationship choices belong in the Model and Customer and Asset Selection configuration references.

Creation and Update Sources

The following table describes how customer records are created, updated, or referenced.

Source

Effect on the record

Native NetSuite entry

Creates or edits customer identity, contacts, address-book entries, native pricing data, and Field Service Language, subject to form and account requirements.

Customer imports and integrations

Can maintain supported native and custom customer data using the applicable NetSuite permissions and validation. Their requirements are separate from interactive form selection.

FSM service work and FSM Mobile

Read customer context and store customer references on related records. The standard FSM Mobile Contacts resource displays customer fallback details when the mapped contact value is zero. It doesn't provide general customer maintenance.

Creating an asset from a customer's Field Service subtab creates an asset that references the customer. It doesn't create another customer. See Field Service Subtabs on Employee and Customer Records for the Asset and Cases lists.

Used by FSM Features

The following table describes how FSM features use customer data.

Feature

How the Customer is used

FSM Customer and Asset Selection

Supplies the customer side of permitted service pairings and related-record sourcing.

FSM Contact Sourcing and Synchronization

Supplies existing customer contacts, primary-contact context, and fallback communication details.

FSM Service Locations and Geocoding

Supplies address-book choices to the asset's Address Select.

FSM Billing Rules

Provides customer pricing context for applicable time and consumable calculations.

FSM Service Reports and Notifications

Supplies customer language and applicable recipient context for service output.

FSM Localization and Translation

Uses Field Service Language for customer-related notification and report language selection.

FSM Profitability Reporting

Provides a report shortcut from the saved customer record. The supplied report uses customer hierarchy criteria and qualifying FSM projects. It is not an unrestricted total of every customer transaction.

Record Constraints and Data Requirements

Native customer creation requires the applicable identity and lifecycle information. Company and Individual entries use different name fields. Enabled features and custom forms can add requirements. In OneWorld, a customer needs a primary subsidiary before transactions can be entered. See Creating a Customer Record for native requirements.

Field Service Language is optional in its supplied field definition. A particular form, integration, or FSM Mobile element can impose additional requirements. A complete service address, notification recipient, or pricing setup is required only for the capability that uses that data. These conditions don't make every value required on the customer record.

Requests and results for contact attachment to projects, asset location updates, and service notifications belong to related records. The supplied customer field definitions have no FSM fields for tracking pending work or completion for these processes. Saving a customer record doesn't confirm that these processes have finished.

Additional Information

Related Topics

General Notices