Developing SuiteApps for OneWorld and non-OneWorld Accounts

NetSuite OneWorld enables companies to manage multiple subsidiaries, business units and legal entities, domestic or internationally from a single solution, providing real-time financial and operational visibility and control at the local, regional, and headquarters levels. Non-OneWorld accounts are less common, but they might be in use by your smaller single-entity customers. Depending on your target customer base, your SuiteApp may need to support both OneWorld and non-OneWorld NetSuite accounts.

SDF Manifest

If subsidiaries are listed as a feature dependency in the manifest, the SuiteApp installation will generate an error in non-OneWorld accounts. However, this feature can always be set to not required as shown in the example below.

Setting a required element to false signifies that the corresponding feature does not need to be enabled in the target NetSuite account. The contents of these elements are ignored if they depend on non-mandatory features, which only prompt warnings during the SuiteCloud project validation.

If the SuiteApp includes a custom record or other record fields referencing the subsidiary field, you can use the SDF enhanced feature dependency functionality to avoid problems during SuiteApp installation in non-OneWorld accounts. Refer to Enhanced Feature Dependencies for SDF Custom Objects Containing OneWorld Components for details. 

Please be aware that the enhanced feature dependency is not available to all other supported SDF objects. If the SuiteApp contains an object that references the subsidiary field or is dependent on the feature itself, the dependency must be removed from the XML file definition. Otherwise, the installation of the SuiteApp will throw an error.

For example, this SuiteApp includes a Custom Role assigned with the Lists> Subsidiaries permission.

The following error will occur in a non-OneWorld account when the SuiteApp is installed, due to subsidiary dependency permission.

SuiteTalk - REST and SuiteQL

Executing a REST GET request (/record/v1/subsidiary) to the subsidiary record in a non-OneWorld account will not yield an error. Instead, it will return a single result, as all NetSuite accounts must have at least one subsidiary. For non-OneWorld, the subsidiary record still exists, but it is limited to one and remains hidden. 

This approach could be problematic as there could potentially be One World accounts configured with only one subsidiary.

An alternative method involves executing a query on the Company Features to verify the availability of an Intercompany feature, which are exclusive to One-World accounts. For example:

SELECT *
FROM CompanyFeatureSetup
WHERE Id IN ('INTERCOMPANYAUTOELIMINATION', 'INTERCOMPANYFRAMEWORK', 'INTERCOMPANYTIMEEXPENSE')

A Non-OneWorld account will return:

A OneWorld Account will return:

SuiteScript – SDF Installation Script

An error can be triggered to halt the installation of a SuiteApp in a non-OneWorld account using an SDF installation script. However, unlike the Bundle Installation Script, this type of script does not support multiple entry points, thereby limiting the ability to specify when the logic should be executed (e.g., beforeInstallation, afterInstallation, beforeUpdate, afterUpdate, etc.). While this can be circumvented by incorporating custom logic, you may want to enforce this validation consistently in this context.

The following is an example of an SDF installation script that verifies if the account is OneWorld. If it isn't, the script generates an error to prevent the installation or update of the SuiteApp in the NetSuite target account.

/**
* @NApiVersion 2.1
* @NScriptType SDFInstallationScript
* @NModuleScope TargetAccount
*/
define((require) => {

    const runtime = require('N/runtime');

    const validateOWAccount = () => {
        if (!runtime.isFeatureInEffect({feature: 'SUBSIDIARIES'})) {
            throw `This SuiteApp is only available for One-World NetSuite Accounts and cannot be installed in your account.`;
        }
    };

    return {
        run: validateOWAccount
    };

});

The Best Solution

It is certainly possible to create two SuiteApps–one supporting OneWorld and a second supporting non-OneWorld accounts. While this approach works, it adds unnecessary overhead to your development and QA and to the BFN verification process.  You will be required to submit bi-annual testing reports and BFN Questionnaires for both SuiteApps.As there is no fool-proof method for determining account types, our recommendation is to create a OneWorld / non-OneWorld feature toggle that can be set after installation.

Again, non-OneWorld accounts are fairly anomalous, yet still possible depending on your intended market.Above all, it is important to provide clarity to the end customers. Your SuiteApp listing should clearly specify if it is intended solely for OneWorld NetSuite accounts.