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 |
|
|
Record identity |
NetSuite Internal ID ( |
|
Customer identifier |
Customer ID ( |
|
FSM record model |
|
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 ( |
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 ( |
Supplies existing contacts and primary-contact context. The customer's own Email and Phone remain separate values. |
|
Field Service Asset |
The asset's 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 ( |
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 ( |
Keeps the service customer identifiable within the project hierarchy. |
|
Case and CRM Task |
Each record's Field Service Customer ( |
Keeps the customer available separately when Company identifies a project. |
|
Project Task |
The project task's Field Service Customer ( |
Retains customer context for work under the project. |
|
Service transaction |
Field Service Customer ( |
Retains service-customer context alongside the transaction's native billing relationships. |
|
Field Service Language |
Customer Field Service 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 |
|
Identifies the saved customer in searches and record relationships. Use this identity when a relationship requires a customer internal ID. |
|
Customer ID |
|
User-facing name or number. It is distinct from the Internal ID and can reflect NetSuite numbering settings. |
|
Company Name, First Name, Last Name |
|
Supply names for FSM customer selectors and FSM Mobile contact display. |
|
Type |
|
Distinguishes a Company from an Individual. Native entry fields and some FSM Mobile contact-selection requirements depend on this distinction. |
|
Inactive |
|
Native inactive state. Relevant FSM customer selectors exclude inactive candidates. Existing references and historical service data remain separate from current selection choices. |
|
Status |
|
Native customer lifecycle status. It is separate from case or task Status and doesn't itself establish FSM service eligibility. |
|
Primary Contact |
|
Identifies the primary contact relationship. The joined Internal ID is a search value, not a customer field to write directly. |
|
Email, Phone, Mobile Phone |
|
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 |
|
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) |
|
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 |
|
|
Address details |
Address subrecord |
|
|
Attention, addressee, and address phone |
Address subrecord |
|
|
Default billing and shipping markers |
Address-book |
|
|
Formatted address |
Address subrecord |
|
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 |
|
Provides customer currency context for pricing. The customer model includes this mapping when Multiple Currencies is enabled. |
|
Primary Subsidiary |
|
Native OneWorld customer context. Transaction use is also subject to the customer's subsidiary relationships and applicable NetSuite features. |
|
Price Level |
|
Native customer pricing preference. |
|
Item Pricing, Group Pricing |
|
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 |
|---|---|
|
Supplies the customer side of permitted service pairings and related-record sourcing. |
|
|
Supplies existing customer contacts, primary-contact context, and fallback communication details. |
|
|
Supplies address-book choices to the asset's Address Select. |
|
|
Provides customer pricing context for applicable time and consumable calculations. |
|
|
Supplies customer language and applicable recipient context for service output. |
|
|
Uses Field Service Language for customer-related notification and report language selection. |
|
|
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.