FSM Service Time Zone Sourcing and Synchronization

Field Service Management (FSM) stores a service time zone on assets, projects, cases, CRM tasks, and project tasks. The stored time zone identifies the time zone used for the record's service work. FSM can determine an asset's time zone from its coordinates. It can source other records' time zones from related records or the current NetSuite user's preference.

FSM also provides Field Service date and time fields on cases and CRM tasks. These keep the record's local dates and clock times together with its stored time zone. Synchronization converts applicable values between these fields and native NetSuite fields. People working in different time zones can then refer to the same service work.

How It Works

This section explains the records and rules involved in the feature.

Service Location and the Record's Time Zone

Here, service location means the physical place where service work is performed, such as the site where an asset is installed. For automatic asset time zone lookup, FSM uses the asset's latitude and longitude to identify that place. The term does not refer to a NetSuite location record or to a separate required field.

The record's service time zone is the time zone stored on that record. It provides the context for interpreting its Field Service dates and clock times. It can be sourced from another record or a user preference, so it is not proof that FSM has looked up the record's physical location. The sourcing rules in Time Zone Sourcing Precedence explain the difference.

Why FSM Has Separate Date and Time Fields

A clock time such as 09:00 needs a date and a time zone to identify when work is scheduled. In the case and CRM task conversion described here, native NetSuite date and time values use the current session's time zone. That time zone can differ from the time zone of the service work.

FSM's separate Field Service date and time fields represent values in the record's stored Field Service Time Zone. For a CRM task, these fields hold the local scheduled start and end values. FSM derives the equivalent native values for the current session, or derives the Field Service values from native input. Keeping both representations allows a local service schedule to be used by people working in different time zones. It also preserves the Field Service schedule when native CRM task clock-time restrictions require separate background synchronization.

Cases use their Field Service start values for start-value synchronization. Their end values also participate in completion processing. Projects and project tasks have different date and time fields and do not use the CRM task's four-field conversion. The field tables in Record Interactions identify these differences.

Three Time Zone Contexts

Three time zones can be relevant to the same service work:

• The record's service time zone identifies the time context of the work. The field is Time Zone on an asset and Field Service Time Zone on the other supported records.

• The current NetSuite user's time zone uses the user's preference. It supplies the final sourcing fallback where applicable and the session context for native date and time conversion.

• The Schedule Board viewing time zone controls how the board presents and interprets scheduled work. It can differ from both the record's time zone and the user's NetSuite preference.

Sourcing chooses a time zone for a record. Synchronization converts applicable date and time values between the record's time zone and the NetSuite session time zone. Changing the board's viewing time zone does not, by itself, replace every record's service time zone.

Field Service values and native values can show different dates or clock times for the same scheduled work. Parent and child records can have different service time zones, including cases on one project and tasks on one case.

Key Behaviors

This section describes how the feature responds to different conditions and actions.

Time Zone Sourcing Precedence

The following table lists the source order FSM uses when it evaluates a record's time zone.

Record	Source Order
Asset	Its latitude and longitude, when automatic coordinate lookup is available and enabled.
Project	Asset, then subsidiary, then the current NetSuite user's preference.
Case	Project, then asset, then subsidiary, then the current NetSuite user's preference.
CRM task	Case, then project, then asset, then the current NetSuite user's preference.
Project task	Project, then asset, then the parent project's subsidiary, then the current NetSuite user's preference.

A case, project, or asset can supply a time zone only when the relationship is populated and that source record has a populated time zone. Otherwise, FSM considers the next source. A customer is not a project time zone source simply because it is selected in the Company field.

Subsidiary sourcing applies when NetSuite Subsidiaries is enabled and the relevant subsidiary is available. A selected subsidiary supplies its own time zone. CRM tasks do not have a direct subsidiary step in this source order.

Asset Location Lookup

Address geocoding determines latitude and longitude. Automatic asset time zone lookup uses those coordinates to find a service time zone. These are separate operations: geocoding an address is not the same as selecting a time zone or scheduling the work.

FSM first matches the returned time zone name to its supported time zone catalog. If that name has no match, it can match by UTC offset. An offset is less specific than a region's named time zone. Different regions can share an offset but apply different daylight-saving rules. Successful lookup and a supported catalog match are required for a usable sourced value.

When automatic lookup is enabled, changing an asset's coordinates on its form can replace its time zone. During saving, changed coordinates can trigger lookup when the time zone was not also explicitly changed. An empty asset time zone can also be populated from its coordinates.

Cases, CRM tasks, and project tasks use their related-record source order. Their own address or coordinate changes do not directly invoke asset-style time zone lookup.

Creation and Later Changes

For projects, cases, CRM tasks, and project tasks, opening a new or copied record sources its time zone. Relationship changes on the NetSuite form can source it again, including replacing a populated value. The following table lists the selections that trigger sourcing.

Record	Source Selections
Project	Asset or subsidiary.
Case	Project/Company, Asset, or subsidiary.
CRM task	Case, Project/Company, or Asset.
Project task	Project or Asset.

When an operation outside the user interface (UI) creates or copies one of these records, FSM evaluates the final submitted relationships again, even if the operation supplied a time zone earlier. On an existing-record edit or inline edit, save-time sourcing fills an empty time zone and retains a populated one. This save-time behavior differs from changing a source relationship on an interactive form.

A stored service time zone is not a live link to the source record. Sourcing updates the record being created or edited.

CRM Task Synchronization in Two Directions

CRM task conversion operates when the task has a service time zone and either a Task Type (custevent_nx_task_type) or an asset. It synchronizes the four Field Service date and time fields listed in Record Interactions with native Start Date (startdate), End Date (enddate), Start Time (starttime), and End Time (endtime). Reserve Time (timedevent) controls the native timed schedule.

Native values to Field Service values. On the NetSuite form, changing the native Start Date, Start Time, End Time, or Reserve Time derives Field Service values in the task's time zone. If both resulting Field Service clock times are populated, Start Time must be earlier than End Time. An equal or later Start Time blocks saving with Start time must be before end time. Server-side submission also enforces this ordering when conversion runs.

Field Service values to native values. Changing Field Service values derives the native representation in the current session's time zone. At save time, a populated Field Service Start Date makes the Field Service values the conversion input. When that date is empty, the native values are the input. A valid Field Service interval can convert to native clock times whose start is equal to or later than the end. The expected behavior is to clear Reserve Time, allow NetSuite to clear the native time values, and successfully save the Field Service schedule. Eligible saved tasks are then selected for background native-time restoration, as described in Processing Model and Lifecycle.

For a non-UI submission with a populated Field Service Start Date, FSM derives native values from the Field Service values. Changing only the native times in that submission does not make those native times the conversion input and can result in those changes being replaced.

When conversion needs a start date and none is supplied, it uses the current date in the input's time zone. When Field Service values are the conversion input, FSM sets Field Service End Date to Field Service Start Date. Native-to-Field Service conversion begins with one native date. The conversion treats an equal or earlier native end clock as the following day. The resulting Field Service clocks still have to pass the ordering rule.

A later Field Service End Date does not bypass that rule. For example, Field Service times of 23:00 to 01:00 are rejected when both are populated, even if separate date fields suggest an overnight interval. This is different from valid Field Service times that cross midnight only after conversion to the user's time zone.

When FSM Clears Reserve Time

Reserve Time can be cleared when the converted native clock times do not meet the required order in the current NetSuite session. This can occur even when the task's Field Service times are valid and the full converted dates and times are chronologically correct. FSM compares the converted native clock times. A later end date does not make a native start clock of 13:00 earlier than an end clock of 02:30. A difference between time zones does not trigger this clearing when the converted native clocks remain in increasing order.

The following table compares a Field Service schedule with its equivalent native schedule. The session time zone is three hours ahead on the service date.

Representation	Start	End
Field Service schedule	11 October, 10:00	11 October, 23:30
Equivalent native schedule in the session time zone	11 October, 13:00	12 October, 02:30

The work still ends after it starts. However, the native clock comparison sees 13:00 followed by 02:30. FSM therefore clears Reserve Time instead of discarding the valid Field Service schedule. Rollover can also occur in the other direction. With a session three hours behind, Field Service times of 01:00 to 04:00 on one date cross a session-date boundary. The native start is 22:00 on the previous date, and the native end is 01:00 on the service date.

The following table describes situations that can produce the same conversion condition.

Situation	Clearing Condition
Entering or changing Field Service dates or times	The new local schedule converts to a native interval that crosses a session-date boundary.
Changing the task's Field Service Time Zone	With existing Field Service values, the new time zone changes their native representation. A source-relationship change can also trigger this when it sources the task's time zone again.
Adding or changing Task Type or Asset	These selections can trigger conversion, and adding either can make a task eligible for form conversion. With Field Service values present, the same native clock-order condition applies.
Saving an existing task from a different NetSuite session time zone	Save-time conversion uses the populated Field Service Start Date and current session context, even if the user changed another field rather than the schedule.
A scripted or integration submission that runs the same conversion	With Field Service Start Date populated, conversion derives native values in the submitting session's time zone. Other NetSuite submission validation can still apply.

Native input remains a separate case. Editing native times derives Field Service values. When both native clocks are populated and native Start Time is equal to or later than End Time, that conversion can also clear Reserve Time. It treats the native end as the following day when deriving the Field Service values. If the resulting Field Service Start Time is equal to or later than Field Service End Time, saving is rejected. If the derived Field Service times are valid, later save-time conversion can still encounter the native representation condition described in this section and use the expected save-and-restoration path. Clearing Reserve Time does not permit an invalid Field Service time range to be saved.

A cleared Reserve Time box alone does not prove that this condition occurred or that a task is awaiting restoration. Native timed scheduling also depends on populated time values, and the background selection checks the saved fields described in Processing Model and Lifecycle.

Case and Project Task Differences

Case start-value synchronization updates the start date and start time when the case has a Case Type and a service time zone. On the form, it converts native start changes to Field Service start values. A populated Field Service Start Date takes priority at submission. Case completion can populate its end values through separate status processing.

Project and project task time zone sourcing does not give those records the CRM task date and time conversion or Reserve Time restoration behavior. Their scheduling behavior is handled by the relevant record and scheduling capabilities.

Record Interactions

The following tables describe the time zone, scheduled date and time, and actual service-time fields on supported records.

Time Zone Fields by Record

FSM provides the following stored selection fields. Each selects a Field Service Time Zone record (customrecord_nx_time_zone), which supplies the supported time zone identity used for geographic matching and date and time interpretation.

Record	FSM Field Label	Field ID	Purpose
Asset	Time Zone	custrecord_nx_asset_time_zone	Stores the time zone selected or determined from the asset's coordinates and can supply it to related service records.
Project	Field Service Time Zone	custentity_nx_time_zone	Stores the project's service time zone and can supply it to cases, CRM tasks, and project tasks.
Case	Field Service Time Zone	custevent_nx_time_zone	Provides the time zone for the case's Field Service date and time values and start-value conversion and can supply it to CRM tasks.
CRM task	Field Service Time Zone	custevent_nx_time_zone	Provides the time zone for the task's local scheduled date and time values, native conversion, and eligible native-time restoration.
Project task	Field Service Time Zone	custevent_nx_time_zone	Stores the project task's service time zone, sourced from its project context and asset. It does not add CRM task date and time conversion.

Field Service Date and Time Fields on Cases and CRM Tasks

FSM provides all four fields in the following table on cases and CRM tasks. These fields are separate date-only and clock-time fields. The time fields do not contain their own date or time zone. Their values are interpreted with the record's Field Service Time Zone.

FSM Field Label	Field ID	Value Represented
Field Service Start Date	custevent_nx_start_date	Start date in the record's Field Service Time Zone.
Field Service Start Time	custevent_nx_start_time	Start clock time in the record's Field Service Time Zone.
Field Service End Date	custevent_nx_end_date	End date in the record's Field Service Time Zone.
Field Service End Time	custevent_nx_end_time	End clock time in the record's Field Service Time Zone.

On a CRM task, these fields represent the scheduled service interval and participate in the two conversion directions described in CRM Task Synchronization in Two Directions. On a case, ongoing synchronization updates only Field Service Start Date and Start Time, together with native Start Date (startdate) and Start Time (starttime). Separate case completion processing can populate Field Service End Date and End Time. The presence of four fields on a case does not give it the CRM task's end-time validation or restoration behavior.

FSM does not provide these four custom fields on assets, projects, or project tasks. Project tasks use their native scheduling fields instead.

Other FSM Date and Timestamp Fields

Other FSM fields have different purposes and should not be confused with the case and CRM task date and time fields in Field Service Date and Time Fields on Cases and CRM Tasks.

Record	FSM Field Label	Field ID	Purpose and Boundary
Project	Field Service Start Date	custentity_nx_start_date	A date used as the start anchor for Program generation. It is separate from native Project Start Date (startdate) and does not participate in CRM task date and time synchronization.
CRM task and project task	Field Service Start	custevent_nx_task_start	Actual service-start timestamp.
CRM task and project task	Field Service On Site	custevent_nx_task_onsite	Actual on-site timestamp.
CRM task and project task	Field Service Off Site	custevent_nx_task_offsite	Actual off-site timestamp.
CRM task and project task	Field Service End	custevent_nx_task_end	Actual service-end timestamp.

The actual-work fields store timestamps with date and time, rather than the separate scheduled date and clock-time values. Time capture, activities, and time bills are covered by the actual service-time capability. This feature does not populate those timestamps merely by sourcing a time zone or converting a schedule.

Processing Model and Lifecycle

Most sourcing and form conversion occurs during record creation, field changes, or submission. CRM task native-time restoration is separate background work associated with Field Service Scheduled : Time Zone, deployment customdeploy_nx_timezone.

Expected Save and Restoration Sequence

For a valid Field Service schedule whose converted native clocks are incompatible, clearing Reserve Time is intended to allow the record to be saved. Clearing Reserve Time is not intended to block saving until background processing finishes. Subject to other record validation, the expected sequence is:

1. FSM retains the Field Service schedule and clears Reserve Time. NetSuite clears the native time values.

2. The task saves successfully with its Field Service values and service time zone.

3. The saved task becomes eligible for the time zone assessment when it has a Task Type, a populated Field Service Start Time, and no native Start Time. The assessment adds a native-time restoration action for it.

4. The time zone script processes that action using the task's time zone context, writes the native Start and End times, and checks Reserve Time again.

The saved-field conditions form the pending workload. The cleared box itself is not a queue flag. A saved task can wait for the next assessment or processing execution. The background selection is narrower than the form-conversion condition. Form conversion can also operate for an asset-linked task without a Task Type. An asset relationship alone does not qualify that task for automatic native-time restoration.

The following table describes the expected stages and observable effects.

Expected Stage	Observable Effect
Save succeeds after incompatible native clocks are detected	Field Service values remain on the saved task. Reserve Time is cleared and native times are empty.
Task awaits native-time restoration	Opening an eligible task can display Syncing Task Times. This identifies outstanding synchronization, not proof that an execution is currently running.
Restoration succeeds	Native Start and End times are populated and Reserve Time is checked again. The Field Service schedule is retained.
Restoration fails or does not run	Native times may remain unpopulated. Saving the Field Service values does not itself prove that native-time restoration has completed.

An active, unrecovered error matching a native-time restoration action can cause that action to be skipped, leaving the task awaiting synchronization. Other eligible actions can still run. An execution finishing does not prove that every selected task's native times were restored.

Restoration is asynchronous. The save operation does not guarantee immediate completion. Shared scheduling, deployment controls, execution monitoring, and error-record handling belong in FSM Script Reference.

The known save-freeze issue described in Limitations and Constraints interrupts the expected save flow and does not confirm a successful save. Background restoration does not complete an unsaved form submission.

Configuration

For the supported settings, defaults, and examples, see Configuring FSM Service Time Zone Sourcing and Synchronization.

You can configure automatic coordinate-based asset sourcing. Its baseline is enabled, subject to the account's mapping-service prerequisites. Disabling this lookup stops that automatic sourcing path. The setting alone does not clear existing record time zones.

The sourcing control is configured in Configuring FSM Service Time Zone Sourcing and Synchronization. Record-model and NetSuite-view configuration define the mappings and presentation used by the records. Schedule Board viewing choices are separate and are described in FSM Schedule Board Configuration.

Limitations and Constraints

The following limitations and constraints apply:

• Known save issue: Entering Field Service Start and End times and clicking Save can cause FSM to clear Reserve Time but leave the CRM task form frozen instead of completing the save. This is a defect in the expected successful-save path, rather than the intended wait for background restoration. A frozen form does not establish that the changed schedule was saved or selected for processing.

• The fallback user preference belongs to the operation's current NetSuite context. An integration or background operation can therefore source a different fallback from an interactive user.

• Automatic asset lookup depends on account enablement, coordinates, provider results, and the supported time zone catalog. It is not a guarantee that every location will produce a time zone.

• CRM task clock-time validation and native-time restoration must not be generalized to cases, projects, project tasks, calendar events, or phone calls.

• Scheduled date and time fields are separate from the actual Field Service Start and End timestamps (custevent_nx_task_start and custevent_nx_task_end). Time zone sourcing and schedule conversion do not record technician work, start or complete service work, or calculate billable time. Actual service-time capture is a separate capability.

Related Topics

For related information, see the following topics:

• FSM Asset Hierarchy and Inheritance - asset inheritance rules are separate from coordinate-based time zone sourcing.

• FSM Case and CRM Task Status Automation - case completion and its date and time effects.

• FSM Maps, Geo-location and Tracking - Map and location behavior.

• Schedule Board Settings, Scheduling, and Shortcuts - Viewing time zone selection and scheduling operations.

• Tracking Field Service Time - Actual service-time capture.

General Notices