1. SuiteCloud Platform
  2. SuiteBundler
  3. SuiteApp Installation and Update
  4. Resolving Conflicting Objects

Resolving Conflicting Objects

When you install a customization bundle, the objects in the bundle are checked against preexisting custom objects in your account to identify possible conflicts. In the same manner, when you update a previously installed customization bundle, any newly added bundle objects are checked against preexisting custom objects in your account. The results of this check are displayed on the Preview Bundle Install page or Preview Bundle Update page. When you review these pages, you'll see options for resolving these conflicts.

For managed bundles, you cannot override bundle installation preferences during bundle installation. For more information, see Bundle Object Preferences.

Important:

Updating bundles from sandbox to production works differently to meet the special needs of sandbox-developed bundles. See Selective Update of Sandbox Bundle Objects.

Note:

Updating bundles from a development account to a sandbox account works the same as updating other bundles. The usual update process overwrites all target account objects with those from the source bundle. For updates from a development account to sandbox, the Preview Bundle Update page always shows the Update action for all objects, even if they haven't changed since the last update.

How Conflicts Are Identified

Conflicts happen when bundle objects have the same script IDs or names as existing objects in your account. Generally, a conflict exists for one of the following reasons:

NetSuite checks for conflicts first by script ID, or by name and type if there's no script ID. For example, custom fields, which have script IDs, are identified by their script IDs, whereas custom forms, which do not have script IDs, are identified by their form name and type.

Bundle authors can avoid conflicts by giving each custom object a name that's unique to its function in the bundle.

Options for Resolving Conflicting Objects

For each bundle object that is identified as conflicting, you can choose one of the following actions on the Preview Bundle Install page and Preview Bundle Update page:

Typically, you would choose Add and Rename if the conflicting ID or name is a coincidence, and you would choose Replace Existing Object if you are sure the bundle object and the preexisting object in the account are the same object. You can still choose Add and Rename even if the objects are the same, but this will create a duplicate object.

Installation of a bundle from a sandbox account to a production account almost always involves conflicting objects. In this case, you'd usually pick Replace Existing Object.

Warning:

For any bundle object conflict where the Preview Bundle Update page displays both a Delete action, and a dropdown to select either Add and Rename, or Replace Existing Object, a bundle update causes deletion of the object and removal of its data from the target account.

Impact of Choosing Add and Rename

If you choose to add and rename a bundle object, a number is appended to the bundle object's name or script ID, to differentiate it from the preexisting custom object. Additionally, all references to the custom object in SuiteScript change to reflect this renaming. For example, if the bundle includes a custom field with the ID custentity_deptaddr and the target account has a custom field with the same ID, then the field in the bundle is given the ID custentity_deptaddr2, and any of the SuiteScript code in your bundle that referenced custentity_deptaddr2 is updated automatically to reference custentity_deptaddr2 instead.

Impact of Choosing Replace Existing Object

For a custom field, choosing Replace Existing Object generally does not have any impact on data that has been entered to the existing field, if the bundle field has the same data type as the existing field. This option causes the field definition to be updated to match the definition for the bundled field. If the bundled field has a different data type, data may have to be deleted from the existing field because the bundled field type, for example, INTEGER, cannot store the existing type of data, for example, TEXT. In this case, you'd probably want to pick Add and Rename to create a new field and give it a unique script ID.

For custom records with data or custom lists, when you pick Replace Existing Object, you can set the bundle preference to Replace Data, Preserve Data, or Merge Data. The Replace Data option overwrites existing target account object data with bundle object data. The Preserve Data option, which is the default, preserves existing data in target account objects. The Merge Data option retains any data added to target account objects after bundle installation and at the same time updating data that was previously installed with the bundle. See Set Bundle Installation Preferences and Set Bundle Update Preferences.

If you choose to replace a preexisting custom object with a bundle object, the bundle object keeps the same name or script ID, and the preexisting custom object no longer exists in the account. For example, if the bundle includes a custom field with the ID custentity_deptaddr and the target account has a custom field with the same ID, then the field in the bundle keeps the ID custentity_deptaddr and the preexisting custom field no longer exists in the account.

Warning:

If you choose the Replace Existing Object option for a conflicting object during bundle installation, the preexisting custom object is PERMANENTLY replaced by the bundle's object. Even if you choose to uninstall the bundle later, changes to the replaced object remain and the original object is not restored.

Related Topics

General Notices