FSM Error Record

A Field Service Error record stores information about a failure captured during a Field Service Management (FSM) operation. It can identify the failed action, affected record, execution context, and request, together with the error message and available diagnostic details.

FSM uses some active, unrecovered error records to prevent a failed action from being attempted again or to exclude affected records from later processing. The effect depends on the capability and the information captured. An error record is not a severity classification or a script execution status.

A failure captured by FSM can originate in NetSuite validation, permissions, an account customization, another script, or an external service called during the operation. The FSM deployment that reports the failure doesn't, by itself, identify the component that caused it.

Record Information

The following table identifies the record and its purpose.

Property	Value
Record type	FSM custom record
Record name	Field Service Error
Record ID	customrecord_nx_error
Primary purpose	Capture failure information and, for applicable processing, identify unresolved work.
Error identifier	The error record's internal ID. This is separate from Record Id, which identifies the affected business record.

Record Relationships

The following table describes the record's relationships.

Related information	Relationship	Purpose
Affected business record	Record Type and Record Id together identify a record when supplied. Record Type and Record Id are text fields rather than a List/Record relationship.	Identify the record being processed. The reference can describe a parent or processing target. It doesn't necessarily identify every record changed before the failure.
User and role	User references an entity, and Role references a NetSuite role.	Identify the reported execution user and role. Background processing can report its execution identity rather than the technician who originally requested the work.
Script deployment	Script Deployment stores the deployment's script ID as text.	Identify the reporting or supplied processing deployment and support applicable error matching.
Support case and issue	Case Id and Issue Id store support investigation references as text.	Associate the failure with an investigation or reported defect when supplied. Case Id is not the affected FSM service case relationship.
Scheduled action	Action Type and Action Payload describe the processing action when supplied.	Let shared scheduled processing recognize a previously failed action.

FSM Fields

Field labels can change in an account. Use the field IDs to identify the data. Fields are populated according to the reporting path. A blank field doesn't prove that the related information was irrelevant to the failure.

Error Details and Recovery

The following table describes error and recovery fields.

Field	Field ID	Meaning
Name	name	Error name or code. The main reporting paths use Error when no name is supplied.
Message	custrecord_nx_error_message	The reported explanation of the failure. A message can originate in FSM, NetSuite, or another component involved in the operation.
Stack Trace	custrecord_nx_error_stack_trace	Available call-stack information. Its format and completeness depend on the error and reporting path.
Date	custrecord_nx_error_date	Reported error timestamp. Reporting normally supplies the current time when the error has no timestamp. The reported timestamp is separate from the standard record creation metadata in NetSuite.
Recovered	custrecord_nx_error_recovered	Indicates whether the error has been marked as recovered. The box is cleared by default. Errors marked as recovered don't meet the unrecovered-error condition described in Recovery and processing meanings.
Inactive	isinactive	Standard record inactivity. Inactive errors don't meet the active-error condition used by those processing checks.
Case Id	custrecord_nx_error_case_id	Optional support case reference for investigation. Stored as text.
Issue Id	custrecord_nx_error_issue_id	Optional issue or defect reference. Stored as text.

Execution Context

The following table describes execution-context fields.

Field	Field ID	Meaning
User	custrecord_nx_error_user	Reported user entity, normally taken from the reporting execution unless supplied with the error. Internal execution identities that cannot be stored as an entity reference are omitted.
Role	custrecord_nx_error_role	Reported role, normally taken from the reporting execution. A role that cannot be resolved for storage can be omitted.
Script Version	custrecord_nx_error_script_version	Reported FSM version. The main reporter uses the FSM version included in its build by default. Suitelet 2 obtains the installed FSM bundle version when available.
Script Deployment	custrecord_nx_error_script_deployment	Supplied deployment script ID or the current reporting deployment ID. There is no separate script-record ID field on this record.
Script Context	custrecord_nx_error_script_context	Supplied or current NetSuite execution context, such as scheduled processing or a Suitelet request. This identifies capture context rather than proving the failure's origin.
Script Module	custrecord_nx_error_script_module	Supplied module or route identifier. The main reporter uses main when none is supplied. It is not necessarily a NetSuite script ID.
Script Parameters	custrecord_nx_error_script_parameters	Supplied execution options. The main reporter stores an empty object when none are supplied. The field doesn't necessarily contain every deployment parameter.
Script Logs	custrecord_nx_error_script_logs	Captured FSM console information when the reporting path supplies it. This is not a complete execution-log history.
Script Index	custrecord_nx_error_script_index	Scheduled queue item index when supplied by the earlier callback runner. It is not a source-code line number.

Action and Affected Record

The following table describes action and affected-record fields.

Field	Field ID	Meaning
Action Type	custrecord_nx_error_action_type	Identifier of the failed FSM processing action when supplied.
Action Payload	custrecord_nx_error_action_payload	Data supplied to that action. Shared scheduled processing uses the action type and payload with the deployment to match an earlier error.
Record Event	custrecord_nx_error_record_event	Reporting user event entry point, such as beforeLoad, beforeSubmit, or afterSubmit.
Record Method	custrecord_nx_error_record_method	Record operation reported by the user event, such as create or edit. This is separate from the HTTP Request Method.
Record Type	custrecord_nx_error_record_type	NetSuite record type being processed when supplied, such as supportcase, task, job, or an FSM custom record ID.
Record Id	custrecord_nx_error_record_id	Internal ID of that record when available. A failed creation can have no saved record ID. Interpret this together with Record Type.

Request Information

The following table describes request fields.

Field	Field ID	Meaning
Request Url	custrecord_nx_error_request_url	Request route or address supplied by the reporting path. The value can be an FSM route rather than the browser's complete address.
Request Method	custrecord_nx_error_request_method	HTTP method, such as GET or POST.
Request Parameters	custrecord_nx_error_request_parameters	Captured request parameters. The main Suitelet removes reserved routing and authentication parameters before reporting.
Request Headers	custrecord_nx_error_request_headers	Captured request headers. Their contents depend on the reporting path.
Request Body	custrecord_nx_error_request_body	Captured request body when supplied. It describes the request at capture time, rather than confirming that its requested changes were saved.

Request and action data can contain account information. The main reporter masks string values in properties named password in Action Payload and Request Body. Don't assume that this masking removes every sensitive value from every reporting path or field.

Recovery and Processing Meanings

An active, unrecovered error has both the Inactive and Recovered boxes cleared. For applicable processing, additional identifiers determine whether that error affects the work:

Processing check	Information used	Meaning
Shared scheduled action check	Active and unrecovered state, matching deployment, Action Type, and Action Payload.	A matching action can be skipped unless that action's retry rules permit another attempt.
Feature record exclusion	Active and unrecovered state, matching deployment, Record Type, and a nonempty Record Id.	The affected record, or related work identified by the capability, can be excluded from assessment.

The Recovered field indicates that an error has been marked as addressed. Applicable processing can reconsider the work without matching that report as an unrecovered error. The intended sequence is:

1. Investigate and resolve the underlying problem.

2. Mark the relevant error as recovered.

3. Trigger the applicable processing again.

4. Confirm the business result.

The problem can involve data, permissions, configuration, a customer customization, an external dependency, or FSM itself.

Checking the Recovered box doesn't repair business data, reverse partial changes, request an execution, or prove that the failed action later succeeded. Making an error inactive likewise changes the active-error condition without correcting the underlying failure. Correcting business data doesn't itself update the error's recovery state.

During an investigation, you can mark an error as recovered and trigger the work again to try to obtain a current failure report. If the action runs and fails through a reporting handler, a new error record can appear near the top of a list sorted by most recent Date. This doesn't refresh the old record or prove that its underlying cause was resolved. Prior partial changes and any other blocking errors must be considered before repeating the operation. For action blocking, timed retries, record exclusion, and investigative retries, see Errors and Skipped Work.

Some actions have specific delayed-retry rules. Those rules don't apply to every error, and time passing doesn't guarantee that another execution will run or succeed. If other matching active, unrecovered errors remain, work can remain blocked or excluded. See FSM Script Reference for shared execution and retry behavior, and the relevant Feature for its selection rules and consequences.

Creation and Update Sources

Captured Failures

The following table describes error capture and maintenance sources.

Source	Capture and information supplied	Consequence to interpret
FSM dedicated scheduled processing	Reports action failures that are not treated as ignorable. Available action metadata supplies the action and affected-record context.	The failed action can remain outstanding, be skipped later, or cause related-record exclusion. Other eligible actions can continue.
Scheduled initialization, assessment, or outer execution failure	Reports the caught failure with available execution options, queue index, and console details, then raises the error again.	The execution can end before its intended work is completed.
Earlier scheduled callbacks	Reports a failed callback and continues when its ignore option permits continuation. Otherwise, the failure reaches the outer execution handler.	A completed execution can include recorded callback failures. The earlier ignore option differs from the dedicated runner's ignorable-error handling.
FSM user events	Reports errors caught by the user event wrapper, then raises the error again. Captured details include the event, operation, record type, available record ID, and console information.	The effect depends on the event. A failure after submission doesn't establish that the business record was never saved.
FSM Suitelet and earlier server requests	Reports handled request failures, including authentication failures that reach these handlers, with available route, request, and console information. The response can include the error record ID.	A failed response doesn't establish that every earlier step was rolled back.
FSM Suitelet 2	Creates an error record for caught request or account-key setup failures. Supplies the error, timestamp, user, role, version, deployment, execution context, and request information.	This path doesn't populate all the action, record, module, parameter, and console fields supplied by other reporting paths.
Field Service Scheduled : Error (customdeploy_nx_error)	Maintenance masks detected password values in existing Action Payload and Request Body data.	This maintenance is redaction, not business-data recovery or retry.

Capture Limits and Exclusions

The record is not a universal log of all FSM, browser, or NetSuite failures:

• In dedicated scheduled processing, recognized record collisions and errors matching the action's ignore rule are deferred without creating an error record through that catch path.

• The earlier server treats DELETE of an already missing record as an ignored condition and returns before reporting it.

• The FSM RESTlet 2 handler logs caught failures and returns a generic error. Its catch handler doesn't create a Field Service Error record. A downstream FSM Suitelet can separately report a failure it handles.

• Browser validation messages, local FSM Mobile errors, and connection failures don't by themselves establish that a server error record was created.

• An error record might not be created if a failure occurs outside the reporting handlers or during the attempt to save the error report.

The error message and available stack can provide evidence about an originating validation, script, or service. The deployment, module, action, and record fields describe the context supplied by the reporter and may be incomplete. Don't assume that each field identifies the original source of the failure.

Used by FSM Features

Error records have different operational consequences. A single failed request can affect one action. A matching unrecovered error can prevent a later action. Feature exclusion can keep an entire related group out of assessment. Blocked is a shared scheduled-processing log outcome when all assessed actions are skipped, not a field on the error record. An execution that finds no remaining actions can also have excluded outstanding records.

Feature	How the error record is used
FSM Asset Hierarchy and Inheritance and FSM Service Locations and Geocoding	Matching action errors can leave child inheritance or task location updates outstanding.
FSM Consumable Processing	Errors on a case, its sales order, or its consumable records can exclude the related case from assessment.
FSM Program	Errors on a project, case, or CRM task can exclude the associated project and its linked cases from Program assessment.
FSM Case and Task Recurrence	Errors on a recurrence definition or its case or task occurrences can exclude the related definition from applicable recurrence assessment.
FSM Case Unbilled Amount Calculation	A matching Unbilled deployment error for a case excludes that case from background assessment.
FSM Service Time Tracking, FSM Case and CRM Task Status Automation and FSM Service Time Zone Sourcing and Synchronization	Matching action errors can leave time, status, or native-time synchronization work outstanding. Retry eligibility differs by action.
FSM Service Reports and Notifications, FSM Contact Sourcing and Synchronization and FSM Localization and Translation	Matching action errors can prevent individual notification, contact attachment, or translation maintenance actions.
FSM Project Labor Cost Posting	A handled server failure can be reported even when earlier journal or time bill changes have already succeeded.

The record has no severity field. Assess its meaning through the affected capability and actual outstanding work rather than treating every error as equally important. Detailed feature lifecycle and effects belong in the linked topics.

Record Constraints and Data Requirements

Date is required in the supplied custom record definition. The main reporting schema requires Name and Date. Other custom fields are optional, and Recovered defaults to unchecked.

Captured text can be formatted or shortened for storage. Context depends on the path and the data available at failure time. The record is not a complete copy of the execution, request, or business record. User and role references can be absent when their execution identities cannot be stored.

Access to these records should be limited to trained staff who need it for their work. Creating or changing an error record can affect scheduled processing as well as expose diagnostic data. See For Administrators - Roles and Permissions.

An eligibility or pending flag on a business record is separate from error data and execution state. Neither an error record's state nor a completed script execution confirms that every requested business-record change succeeded.

Additional Information

• FSM Script Reference

• Investigating FSM Recurrence Errors and Partial Results

• FSM Consumable Billing Eligibility and Processing Lifecycle

Related Topics

• FSM Records
• FSM Case Record
• FSM Consumable Record
• FSM CRM Task Record
• FSM Recurrence Record

General Notices