Using Precision Bridge without Service Now Admin Permissions

If you are using Precision Bridge to connect to a ServiceNow instance (source or target) and you don't have (or cannot set) the admin role for the connecting user then you need to add these roles instead:

soap

itil

personalize_choices

personalize_dictionary

usage_admin

web_service_admin

snc_required_script_writer_permission (additional requirement from Zurich onwards)

Additional roles may be needed depending on the migration projects being run and the tables that are being read/written to. In addition, some tables may not have the required ACL's defined to allow non Admin access. See the section below for more detail.

NOTE: for Zurich or later instances the role snc_required_script_writer_permission is needed even for an Administrator user.

Adding additional ACL's to tables

There are some key tables that may be included in projects that do not allow non-administrator access OTB. To allow Precision Bridge to read from these tables, you may need to add a read ACL to the table and add the pb_migrator role (see Best Practice Approach below) to it. This action needs to be carried out by a system administrator with the security_admin elevated role. The following commonly referenced tables have been identified as having this restriction, but there may be others:

• Data policy (sys_data_policy2)
• Journal Entry (sys_journal_field)
• Application File (sys_metadata)

The image below shows an ACL added to allow users with the pb_migrator role to read from the sys_journal_field table.

Precision Bridge generally requires only read access to tables if the migration method selected is import set (scripted) - which is the default, however with other migration methods, create/update access may also be required.

Best Practice approach is as follows

1. Create a role named pb_migrator (the name is important)
2. Add the above roles to it, together with any others required by specific projects.
3. For some specific tables, you may need to add a read ACL and assign the pb_migrator role to it to ensure access. (see above)
4. Create a user with this role. If domain separation is to be deployed on the target server, this user must also be in the required target domain.
5. Run the project using the import set (scripted) migration method. This will reduce the possibility of access issues preventing the creation and update of the target records.

The pb_migrator role is automatically created on first generation of an import set table, however it is not automatically added to the current user, so running a project without this role will generate an error.