FSM Mobile 2026.07.1 early-access sandbox checklist

FSM SuiteApp 2026.07.1 is available only for early-access testing in sandbox accounts. This FSM Mobile 2026.07.1 checklist focuses on the changes most likely to affect technician work, task loading, access, and saved mobile-form behavior: status feedback, loading and sync errors, task completion, record permissions, automatic mapping, expressions, navigation titles, and headings.

TL;DR: Test status counters, offline behavior, loading failures, and sync retries on real devices. Verify cancomplete, create, edit, and delete independently; migrate applicable resource-level readonly rules to edit; and enable automap only after confirming that every intended element ID exactly matches its NetSuite field ID.

Key takeaways

Status indicators appear at the app, task, mobile-tab, and record levels. When multiple statuses apply, the display priority is Offline, Active Sync, Draft, then Error.
Failed loading can leave the task list empty and prevent technicians from selecting Add Tasks. A failed synchronization instead shows a record-level error icon that technicians can retry without changing data.
The release removes resource-level readonly rules from FSM Configuration. Migrate applicable logic to edit, and test each permission property independently.
Setting automap to true can reduce explicit mapping, but an element ID mismatch can cause a mobile-tab request to fail and prevent tasks from loading.
format(date) and now() must resolve to the stored format required by the target element, independent of the localized format shown to the technician.

1. Validate status feedback at every scope

FSM Mobile adds status indicators at the app, task, mobile-tab, and record levels. These indicators identify active sync, draft, error, and offline statuses. Do not sign off after checking a single icon: the app-level and task-level counters intentionally use different record sets.

Area	Expected status information
Task list	App-level status icon and counter
Individual task	Task-level status icon and counter
Mobile tabs and records	Status icons that update as status changes

Use this acceptance sequence:

Confirm that the app-level counter appears at the top of the task list and counts records with active sync, draft, error, or offline status.
Confirm that the task-level counter appears at the top of each task and includes only records with draft or error status.
Take the app offline. Verify that the app icon shows Offline, the app-level counter includes records pending synchronization, and a warning banner remains at the bottom of every page while the technician navigates.
During synchronization, verify that the active-sync icon appears consistently wherever Active Sync status is shown.
Where multiple statuses apply, confirm this priority: Offline, Active Sync, Draft, Error.

These changes complement the status badge updates on Agenda task cards, which address task-state visibility elsewhere in FSM Mobile.

2. Separate loading-failure tests from sync-failure tests

Loading indicators appear on the task list and mobile tabs while FSM Mobile retrieves task data, user resources, or mobile-tab data from the server. If loading fails, an error banner appears in the affected area. A blank task list can therefore indicate a loading problem rather than an ordinary empty assignment list.

Retrieve task data, user resources, and mobile-tab data, and verify that loading indicators appear while each request is in progress.
When task data or user resources cannot load, verify that the task list appears empty, an error banner appears in the affected area, and technicians cannot select Add Tasks.
After a failed record synchronization, verify that a dedicated error icon appears on the affected record.
Retry synchronization without changing record data. A successful retry should remove the icon.
Verify that the icon remains until the data changes or a retry succeeds. If values that caused the original failure are restored, the icon may reappear.

Include the related barcode scanning reliability changes in the same device and connectivity plan when technicians use device cameras.

3. Check navigation-bar titles for records and drafts

The navigation bar can display up to two lines for the current mobile tab and its record or draft. Review tab names and title-information configuration for forms that have similar layouts or records.

Confirm that the first line displays the configured mobile-tab name. If the name is blank, the line should remain blank.
For an existing record, verify that the second line displays the label and value of the first mobile-tab element that provides title information.
For a draft with configured title information, verify that the second line displays Unsaved Draft.
For a tab with no title-information element, verify that only the first line appears.

Capture the result for existing records and drafts separately. This gives support teams a baseline for distinguishing title configuration, draft state, and record issues.

4. Test task completion with `cancomplete`

The cancomplete property in the mobile event map controls whether tasks can be completed in FSM Mobile. When cancomplete returns false, the Complete button is dimmed and the app does not start a completion request.

Event type	Default completion behavior
Customer Relationship Management (CRM) tasks	Only the task assignee can complete the task by default
Project tasks	Any mobile user can complete the task by default
Other mobile event types	Existing completion behavior remains unless `cancomplete` is configured

Test the assigned and unassigned user cases for CRM tasks.
Test more than one mobile user against project tasks.
Configure cancomplete to return true and verify that completion can proceed.
Configure it to return false and verify both outcomes: Complete is dimmed and no completion request starts.
Retest other event types used in the account instead of assuming CRM or project defaults apply to them.

Where task state is also affected by service start and end information, include FSM Mobile task status behavior based on Field Service Start and End in the end-to-end test case.

5. Migrate resource-level `readonly` rules to `edit`

FSM Mobile 2026.07.1 adds independent create, edit, and delete record-permission properties. Existing readonly, min, and max rules continue to apply, but this release removes the readonly rule from the resource level of FSM Configuration. Migrate applicable resource-level restrictions to edit.

Inventory resource-level readonly rules before changing the sandbox configuration.
Identify the users, resources, record conditions, and forms each rule was intended to restrict.
Move applicable resource-level logic to edit.
Test create, edit, and delete separately. Permission for one action does not establish permission for another.
Retest applicable element-level readonly, min, and max rules.
Run a positive and negative test for each action and expected user outcome.

Unconfigured permission properties default to true. Expressions that do not evaluate to true or false also default to true, so every permission expression should be tested for an explicit Boolean result. For related release-cycle configuration changes, see FSM Mobile app configuration enhancements.

6. Validate `automap` before enabling it

Set a mobile tab’s automap property to true to map elements without defining every corresponding field in article.map. By default, automap is not set to true for any FSM Mobile tab.

At runtime, FSM reviews unmapped elements and checks whether an element ID exactly matches a field ID on the record specified by article.record. A matching element is treated as mapped. Explicit mappings continue to apply and take precedence, and runtime mapping does not modify the FSM Configuration.

{
  "automap": true
}

Before enabling it:

List unmapped elements on the target mobile tab.
Confirm that each intended element corresponds to an existing NetSuite field on the record specified by article.record.
Compare each element ID with the field ID exactly.
Review article.map and preserve explicit mappings that are intentional.
Enable automap in sandbox, then load, edit, save, reopen, and synchronize the tab.
Validate that an ID mismatch is corrected before broader use: a mismatch can cause the mobile-tab request to fail and prevent tasks from loading.

7. Test expressions and required formats

Mobile expressions include format(date) and now() for date, time, and datetime values, including dynamic resource-block min, max, and value properties. The value must resolve to the format required by the target element. FSM ignores a configured property when its result does not match that format.

Element type	Required format	Example
`date`	`YYYY-MM-DD`	`2026-07-14`
`timeofday`	`HH:mm:ss`	`09:30:00`
`datetime`	`YYYY-MM-DD HH:mm:ss`	`2026-07-14 09:30:00`

Test format(date) and now() in applicable value, min, and max expressions.
Verify that the expression result uses the required stored format, regardless of the localized display format.
Review configurations containing nxc_now(). FSM automatically migrates existing expressions to corresponding helper replacements while preserving existing checkbox conditions.
Review the copied configuration named Auto Configure xxxx: Migrate nxc_now expressions.

After a mobile form closes, FSM Mobile evaluates required expressions to determine whether a mobile tab is complete. If an expression returns false, dependent mobile tabs or the Complete button remain available even if an empty element exists. Keep this check separate from permission testing because required expressions and permission properties control different outcomes.

8. Verify heading blocks and layout

Static heading blocks organize long mobile forms without placeholder fields or inline HTML workarounds. Configure a mobile-tab element with the heading block type and a label.

Test level values 1, 2, and 3, in decreasing order of visual prominence.
Verify that an invalid level defaults to 1.
Confirm that a heading spans the full content width.
Confirm that index controls placement when defined; otherwise, FSM Mobile uses element order.
Save the form and verify that heading blocks are excluded from the save payload.

Oracle identifies SuiteAnswers ID 1046936 as the configuration reference for heading blocks. For a related configuration-interface topic, see independent Preview and Editor resizing.

FAQ

If multiple statuses apply, which status does FSM Mobile show?

FSM Mobile displays the highest-priority status in this order: Offline, Active Sync, Draft, then Error. The app-level counter includes active sync, draft, error, and offline records; the task-level counter includes only draft and error records.

What must I check before enabling `automap`?

Confirm that every intended unmapped element ID exactly matches a field ID on the record specified by article.record. Explicit mappings in article.map retain priority. Test the tab in sandbox because an ID mismatch can prevent tasks from loading.

What replaces resource-level `readonly` rules?

Migrate applicable resource-level readonly logic to edit. Test create, edit, and delete independently, while retaining and validating applicable readonly, min, and max rules.

Can a technician retry a failed synchronization without editing the record?

Yes. After a failed sync, a dedicated error icon appears on the affected record. The technician can retry without changing data, and the icon remains until the data changes or a retry succeeds.

What happens to existing `nxc_now()` expressions?

FSM automatically migrates them to corresponding helper replacements while preserving existing checkbox conditions. It stores the migrated expressions in a copied configuration named Auto Configure xxxx: Migrate nxc_now expressions.

Key takeaways

1. Validate status feedback at every scope

2. Separate loading-failure tests from sync-failure tests

3. Check navigation-bar titles for records and drafts

4. Test task completion with cancomplete

5. Migrate resource-level readonly rules to edit

6. Validate automap before enabling it