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 are presented with options for how to resolve these conflicts.

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

Important:

The process for updating bundles installed into production from sandbox is different from the update process for other bundles, to meet the specialized requirements of bundles developed in sandbox accounts. See Selective Update of Sandbox Bundle Objects.

Note:

The process for updating bundles installed into a sandbox account from a development account is the same as the update process for other bundles. The normal bundle update process updates all bundle objects in the target account, overwriting target account objects with source bundle objects. For bundle updates from a development account to a sandbox account, the Preview Bundle Update page always shows the Update action for all objects, even for objects that have not changed in the source account since the last bundle update.

How Conflicts Are Identified

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

The same object already exists in the account, typically because it was already installed as part of another bundle installation.
A different, unrelated object coincidentally has the same ID or name.

NetSuite identifies conflicts first by the script ID of the object, or when there is no script ID, by the name and type of the object. 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 potential conflicts with target accounts' custom objects by giving each bundle's custom objects names unique to their function in that 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:

Add and Rename the bundle object, leaving the preexisting custom object intact, or
Replace Existing Object with the bundle object.

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 if the objects are the same, effectively creating a duplicate object.

Installation of a bundle from a sandbox account to a production account almost always involves conflicting objects. In this case, you usually would choose the Replace Existing Object option.

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 should probably choose the Add and Rename option to create a new field, and change the script ID so it is unique.

For custom records that include data and for custom lists, when you choose Replace Existing Object, you can set a 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.

How Conflicts Are Identified

Options for Resolving Conflicting Objects

Impact of Choosing Add and Rename

Impact of Choosing Replace Existing Object

Related Topics