So, NetSuite wants us to include a Least Privilege Access role in our SuiteApps. We want our SuiteApps to support both OneWorld and NonOneWorld accounts. We do that with code-level feature checks. But, if the role that executes doesn't have Subsidiary List view, we fail in a OneWorld environment because we don't have the permission to search Subsidiaries ... and if we ADD that permission to the custom role, it because a required feature in the manifest.xml .. and will no longer install into NonOneWorld accounts.

Are you running into issues deploying to a leading account? I just started running into errors when deploying to a leading account on permissions

it was against 2025.1 and 2025.2 accounts.

I think we are running into separate issues. I originally ran into the issue with non one world accounts and including the subsidiary permission. I ended up having to execute all of the scripts as admin to get around the issue I don’t run into the same issue for department/class/location I do not require any of the permissions in the manifest

<feature required="false">SUBSIDIARIES</feature>
<feature required="false">CLASSES</feature>
<feature required="false">LOCATIONS</feature>
<feature required="false">DEPARTMENTS</feature>

Right. "running all scripts as Admin" ...well, we're trying to comply with BFN requirements.

I agree. I would like to to able to run scripts as a specific custom role but with the current netsuite limitation on permissions, it makes it impossible to handle both one world and non oneworld accounts. We commonly have to join on the subsidiary table and it just isn’t possible

In short, it appears we cannot support OneWorld/NonOneWorld AND the inclusion of a CustomRole. I'll report back here when I get responses to the Support Tickets

Correct. I was told at one point to manage two apps. A one world and non one world version

It may be a long shot and I have little experience with SuiteApp. But can you use config.load and check the options in the "Subsidiary" field under the Restrict View subtab of user preference? @darrenhillconsulting config.load('userpreferences').getField('subsidiary').getSelectOptions()

I think we're missing the point ... the issue is at the

object.xml

level and during the NetSuite installation process (which is a blackbox). We already know how to manage code level feature checks

Here's my "solution" to that problem. It is a hack. It is ugly. 1/10 would not recommend. It only works if you are deploying using the SDF CLI and know up front whether you are deploying to a OneWorld or non-OneWorld account. Fortunately, non-OneWorld systems are rare enough that I haven't actually had to use this on an actual customer system. I created a second copy of customrole_xyz.xml named customrole_xyz.xml.NonOneWorld. I commented out the LIST_SUBSIDIARY entry in the permissions list in the non-OneWorld role. And I created a powershell script for a non-OneWorld deploy that renames the two copies of the role XML, runs the deploy with the non-OneWorld role, then renames them back.