NetSuite FSM Breaking Change: How to Replace readonly Resource-Level Rules Before August 11

The readonly property in NetSuite FSM Configuration records is a field-level setting that prevents technicians from editing specific resources in the FSM mobile app. In the 2026.07.1 bundle, Oracle is removing the resource-level readonly property and replacing it with more granular field-level access controls configured at the section and field level.

If you have configured readonly rules at the resource level of your NetSuite Field Service Management configuration, those rules will stop working on August 11, 2026, when Oracle deploys the FSM 2026.07.1 bundle update to Production.

Quick answer

The readonly property at the resource level in NetSuite FSM Configuration records is being removed in the 2026.07.1 bundle update on August 11, 2026. Any readonly rules configured at the resource level will stop working after the update without an error, alert, or log entry in the system. Technicians who were restricted by these rules will gain the ability to edit records that were previously locked. Oracle is removing the resource-level readonly property because it was a binary on/off control that could not distinguish between create, edit, and delete permissions. The replacement is field-level access control configured at the section and field level in the FSM Configuration record, which provides more granular control. Organizations should identify all resource-level readonly configurations before August 11, recreate the restrictions using field-level controls in Sandbox, and validate that the new configuration produces the expected behavior before Production.

There is no error when this happens. No alert, no log entry, and no visible change in your FSM Configuration record. Technicians will simply gain the ability to edit records that your readonly rule was previously restricting.

Need help identifying and migrating your FSM configuration before August 11? SuitePacific works with NetSuite customers through FSM bundle updates, including configuration reviews, migration support, and Sandbox validation. Contact us and we will help you get ahead of this before it affects your live operation.

Why Is Oracle Removing the readonly Property?

The readonly property at the resource level was a single on/off control. It blocked technicians from editing a record but gave administrators no way to distinguish between create, edit, and delete permissions independently. You could not, for example, allow technicians to create new records on a tab but prevent them from deleting existing ones.

The 2026.07.1 update replaces this blunt control with three separate properties on mobile tabs: create, edit, and delete. Each can be configured independently per tab, giving administrators more precise control over what technicians can do in the mobile app.

As part of this change, the readonly property at the resource level is being retired. Oracle has not provided an automatic migration for it. Identifying and replacing your readonly rules is a manual task that must be completed before August 11.

What Happens If You Do Nothing About the readonly Property?

If you have readonly rules at the resource level and take no action before August 11:

The rules will remain visible in your FSM Configuration record after the update
They will have no effect on technician behaviour
Technicians will be able to create, edit, and delete records on any tab that previously had a readonly restriction
There is no warning in the mobile app or in NetSuite that the restriction has been removed

This is the category of FSM change that is easy to miss in Sandbox testing if you are only checking that things load and complete correctly, rather than specifically testing that restrictions are still in place.

How Do You Identify Whether You Are Affected by This Change?

Open your FSM Configuration record in NetSuite (Sandbox first) and review the resource-level configuration. You are looking for any property named readonly applied at the resource level rather than at the mobile tab level.

If you are uncertain where to find this in your specific configuration, search for readonly within the FSM Configuration record. The property is documented in the FSM configuration schema. Any occurrence of readonly at the resource level rather than at an individual tab is what needs to be replaced.

If your configuration has no readonly rules at the resource level, you are not affected by this specific change. You should still validate your mobile tab permissions in Sandbox, but no migration is required for this item.

What Replaces the readonly Property on Mobile Tabs?

The three new properties work at the mobile tab level, not the resource level. For each mobile tab in your FSM Configuration, you can now specify:

create: whether technicians can create new records on that tab
edit: whether technicians can edit existing records on that tab
delete: whether technicians can delete records on that tab

The important default to understand: if none of these properties are set on a tab, all three actions are permitted. This means that after August 11, any tab that was previously restricted only by a resource-level readonly rule will default to fully open.

The readonly resource-level rule is replaced by three independent properties at the mobile tab level.

What Is the Migration Approach for the readonly Property?

For each readonly rule you find at the resource level, work through the following:

1. Identify what the readonly rule was protecting

Determine which mobile tabs and which record types the rule was applied to, and what business reason existed for making those records read-only for technicians. Understanding the original intent is important before you translate the rule into the new property structure.

2. Decide which actions to restrict

With the new system, you have three separate levers. The equivalent of a readonly restriction is to set edit: false and delete: false on the relevant mobile tabs, while leaving create set according to your requirements.

If the original intent was specifically to prevent editing but not creation, you can now express that exactly rather than using a blunt readonly block.

3. Apply the replacement properties to the correct mobile tabs

Add the appropriate create, edit, and delete properties to each mobile tab that needs restrictions. If a tab has no restriction properties set, technicians will have full create, edit, and delete access by default after the update.

4. Remove or note the retired readonly property

The retired readonly property at the resource level will have no effect after August 11. It does not need to be removed for the system to function, but leaving it in place creates a false impression that a restriction is active. Remove it once you have confirmed the replacement tab-level properties are working correctly.

How Do You Test the readonly Migration in Sandbox?

Your Sandbox account already has 2026.07.1 available as of July 16. Test your migration there before August 11.

Specifically:

Log in to the FSM Mobile app as a technician role that was previously subject to a readonly restriction
Attempt to edit a record on a tab that had the restriction
Confirm that the tab-level edit: false property blocks the action as expected
Confirm that tabs with no restriction properties set allow all three actions
Test create, edit, and delete separately on each affected tab: do not assume that one test covers all three

Do not only verify that the mobile app loads correctly. Verify that the permission boundaries you expect are actually enforced.

Frequently asked questions

Will Oracle migrate my readonly rules automatically? No. Oracle has confirmed that the readonly property at the resource level is being retired, but no automatic migration is provided. Identifying and replacing these rules is a manual task.

What if I miss the August 11 deadline? If you do not replace your readonly rules before August 11, technicians who were previously restricted by those rules will gain unrestricted access after the Production upgrade. You can apply the replacement edit, create, and delete properties after the upgrade and the new properties will take effect in the mobile app, but there will be a window between August 11 and when you complete the work where restrictions are not in place.

Do I need to do anything if I do not use readonly at the resource level? No. If your FSM Configuration does not use readonly at the resource level, this specific change does not require action. Review your mobile tab permissions in Sandbox as part of your general 2026.07.1 validation, but no migration work is needed for this item.

Where can I find more information about the new properties? The full 2026.07.1 release notes are available in SuiteAnswers answer ID 1047018. The FSM Configuration documentation in SuiteAnswers covers the mobile tab property schema.

How Can SuitePacific Help With the readonly Migration?

Reviewing FSM Configuration for retired properties, translating business requirements into the new mobile tab permission model, and validating the result in Sandbox before August 11 is exactly the kind of work SuitePacific does for NetSuite customers in the post-go-live phase.

If your team does not have an FSM-experienced administrator available before August 11, reach out to us. We will work through your configuration, identify what needs to change, and make sure your technicians have the right access when Production updates.

For dedicated FSM support and configuration troubleshooting, see NetSuite FSM Support and Troubleshooting. For more on how SuitePacific handles post-go-live configuration and administrator support, see the NetSuite administrator support service.