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

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.

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 Oracle is 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

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 to identify whether you are affected

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.

The replacement: create, edit, and delete 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.

Migration approach

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.

Testing 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 SuitePacific can help

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.