NetSuite Next Access Control: What to Configure in 2026.2

NetSuite Next is not a single switch that an administrator flips for the whole account. The 2026.2 rollout introduces separate decisions for the new interface and for Ask Oracle, with access controlled by role.

That distinction matters because a pilot can expose users to a new interface, an AI assistant, or both. Those are different operational changes. They have different permission boundaries, different rollback paths, and different testing requirements.

The three NetSuite Next access modes

Administrators can manage access at Setup > Company > AI > NetSuite Next Access. For eligible roles, the account offers three settings.

NetSuite Next only

Users with this setting can use only NetSuite Next. Their environment switches to NetSuite Next the next time they log in.

This is the strongest rollout setting. It is appropriate after a role has completed a pilot and the team is comfortable with the new interface. It is not the right default for an untested custom role, especially one that depends on custom forms, browser scripts, or undocumented UI behavior.

Optional

Users can switch between the current NetSuite experience and NetSuite Next.

Optional access is the safest setting for a first pilot. It lets administrators compare the two experiences with the same role and user population. It also creates a practical fallback when a daily workflow behaves differently in the new interface.

Optional does not mean that every customization is automatically compatible. It only gives the user a choice of interface. The underlying records, permissions, scripts, and integrations still need to be tested.

Blocked

Users continue to use the current version of NetSuite and cannot access NetSuite Next.

Blocked is useful for roles that are not ready for the pilot, service-oriented users who need a stable interface, or groups whose workflows depend on a third-party customization that has not been validated.

The setting is role-based, so the same person may have different exposure when using different roles. That makes role inventory part of the rollout plan.

Ask Oracle is a separate permission decision

Ask Oracle has its own page at Setup > Company > AI > Ask Oracle Access.

By default, roles do not have access to Ask Oracle. An administrator must grant access to eligible roles explicitly. Giving a role access to NetSuite Next does not automatically mean that the role can use Ask Oracle.

This separation is useful. A company may want to let a small group test the new interface without allowing AI-assisted questions about business data. Another group may be ready to use Ask Oracle for narrowly defined workflows but should not be moved to the full NetSuite Next interface yet.

Ask Oracle also consumes AI Units, so a permission decision is a spending decision as well. We covered how the AI Unit pool works and what different features cost to run separately.

Some Ask Oracle features have additional requirements. For example, uploading documents requires upload access to the File Cabinet, and the feature supports one document per chat turn. A role that can open Ask Oracle may therefore still be unable to use every input method.

The August minor release also adds job details, additional document types, selectable effort levels, and new core skills in Ask Oracle. These capabilities should be tested as separate use cases rather than treated as one large feature.

What N/runtime.isNextActive() does

SuiteScript developers now have a way to detect whether NetSuite Next is active for the user running the script:

/**
 * @NApiVersion 2.1
 * @NScriptType UserEventScript
 */
define(['N/runtime'], (runtime) => {
    function beforeLoad(context) {
        log.audit({
            title: 'NetSuite Next status',
            details: runtime.isNextActive()
        });
    }

    return { beforeLoad };
});

The method returns true when NetSuite Next is active for the current user and false otherwise. Oracle documents it as available to both client and server scripts.

One limitation matters before you build anything on top of it. Oracle states that for scheduled and map/reduce scripts the return value depends on the user running the script, and that the method returns false when NetSuite runs the script as the System user. A background job that logs the interface mode will therefore report false for reasons that have nothing to do with the pilot. Use the method in a context where the executing user is the user you care about.

That makes it useful for controlled compatibility logic. A client script can select a small UI behavior based on the active experience. A server script can record the environment during a pilot or use the status as a diagnostic signal when comparing workflows.

For example, a client script could display a diagnostic message during a controlled test:

define(['N/runtime', 'N/ui/message'], (runtime, message) => {
    function pageInit() {
        if (!runtime.isNextActive()) {
            return;
        }

        message.create({
            title: 'NetSuite Next',
            message: 'This test is running in NetSuite Next.',
            type: message.Type.INFORMATION
        }).show();
    }

    return { pageInit };
});

The important boundary is what this method does not do. It does not enable NetSuite Next. It does not grant Ask Oracle access. It does not verify the permissions of the current role. It also does not prove that a custom form, workflow, browser script, or Suitelet has identical behavior in both experiences.

Use the method as an input to a compatibility decision, not as a compatibility test.

A safer rollout sequence

A practical pilot can use four stages.

1. Inventory roles, not just users

List the roles that use custom forms, browser scripts, workflows, Suitelets, and high-value financial processes. Include integration-adjacent human roles such as administrators, operations managers, and finance reviewers.

The NetSuite Next setting is applied to roles. A user list alone will not tell you which people are exposed through which role.

The Advanced Partner Center, Customer Center, Employee Center, Partner Center, and Vendor Center role families are not eligible for the NetSuite Next access setting. They should be documented as outside the pilot scope rather than treated as failed configuration.

2. Start with Optional

Use Optional for a small group and define the workflows they must test. For example:

• create and edit a transaction;
• approve a transaction;
• open a saved search and export its results;
• use a custom form;
• run a workflow action;
• open a Suitelet;
• complete a month-end review.

Record not only whether the page loads, but whether the business result is the same.

3. Give Ask Oracle access to a narrower group

Treat Ask Oracle as a separate pilot. Begin with users who understand the data they are querying and can recognize an incomplete or misleading answer. Test role permissions, saved-search-based answers, uploaded documents, job details, and the effect of different effort levels.

Do not use a successful answer as proof that the user had the correct data scope. Validate the answer against a known report or saved search. The general problem of what an AI agent inside NetSuite can actually see, and under which role it acts, applies here too.

4. Move to NetSuite Next only after evidence

NetSuite Next only is a rollout decision, not a test setting. Use it after the pilot group has completed the defined workflows and the fallback procedure is known.

Keep a record of which roles are Optional, Blocked, or NetSuite Next only. Revisit the list when a custom role or major customization changes.

What developers should test

The new runtime method makes environment-aware diagnostics easier, but the broader test still belongs to the application team. Check:

• client scripts on the forms used by the role;
• custom buttons and page actions;
• Suitelets and dashboards;
• saved searches and exports;
• workflows and approval paths;
• custom records and custom forms;
• browser extensions or third-party tools;
• scripts that assume a particular page structure;
• help and error paths used by operations staff.

For each workflow, record the role, the interface mode, the record type, the expected result, and the observed result. If the workflow creates, approves, posts, or sends anything, verify the record and audit trail after the test.

The operational takeaway

NetSuite 2026.2 changes the rollout problem from “Should we turn on NetSuite Next?” to “Which roles should see which parts of the new experience, and what evidence do we need before expanding access?”

Use Optional for controlled comparison, Blocked for roles that must remain stable, and NetSuite Next only for roles that have completed the pilot. Manage Ask Oracle separately. Use runtime.isNextActive() for diagnostics or narrowly scoped behavior, but do not mistake it for a substitute for workflow testing.

The safest rollout is role-based, reversible, and measured against business outcomes rather than interface availability.

Sources

[1] Managing NetSuite Next Access by Role

[2] Managing NetSuite Next Access

[3] Setting Ask Oracle Access

[4] August Minor Release for NetSuite 2026.2

[5] NetSuite Next FAQ