User Tools

Site Tools


ServiceNow Dynamic Share


Setting up a Dynamic Share allows a ServiceNow instance to share table data as it updates in real time. The Subscriber (consumer) of this data can be any Perspectium supported integration: another ServiceNow instance, the Perspectium Replicator Agent, or one of Perspectium's supported SIAM integration endpoints.

You will define these Dynamic Shares per table that you want to share and specify the format, conditions, and destination of the messages. This setup can share multiple tables through the table hierarchy, run through advanced filters and scripts, share out related/auxiliary records, and more.

This page documents each of the core components of the Dynamic Share and the features related to it:

  • Creating a Dynamic Share
  • Trigger Conditions
  • Additional Settings
  • Filter and Enrichment
  • Advanced Settings
  • Notes
  • UI Actions
  • Related List Tables

Creating a Dynamic Share

Initial Setup

1. Go to the Replicator > Dynamic Share option under the Perspectium app:

Here you should see the list of your current Dynamic Shares, what they trigger on, and what queue they are pointing to. We will cover these settings further down.

2. Choose the “New” option at the top to go to the table share configuration form:

3. On the table share configuration form, the following options are available:

To quickly set up a table for sharing you will have to specify the following fields:

Field Description Example
Name The name of this Dynamic Share, just used for display purposes Incident DB Sync
Table The table that you want to share from incident
Active Whether the Dynamic Share will replicate data or not True (checked)
Create Trigger the sharing when a record is created True (checked)
Update Trigger the sharing when a record is updated True (checked)
Delete Trigger the sharing when a record is deleted False (unchecked)
Target Queue The destination queue that you will be sharing to psp.out.replicator.example

If you have not created a target queue yet you can see here on creating them.

Once those fields are populated the Dynamic Share will be created and records should be getting shared out per your specifications. There are a lot of options available to you for Dynamic Share, so the further sections will cover how you can customize, filter, enrich, and backup your Sharing.


The following sections are broken down by tab of the Dynamic Share covering the tabs:

  • Trigger Conditions (when to Share)
  • Additional Settitngs (what and where to Share)
  • Filter and Enrichment (what to skip and add)
  • Scheduled Sync Up (how to backup)
  • Advanced options

Trigger Conditions

The Trigger Conditions control how and when the Dynamic Share is activated for a given base record. Base record referring to the table you specify in the “Table” option. This involves what type of operations you are triggering on, when the Business Rule is fired, and how to interact with the parent/child hierarchy.

Interactive Only

When True (checked) this checkbox indicates to the Dynamic Share to only replicate data when a User has performed the operation, not some background job. For example: an interactive update is a user commenting or resolving an incident. A non-interactive update is a job closing resolved incidents after 7 days, the email engine creating records, discovery updating CI records.

From a technical standpoint this utilizes ServiceNow's interactive check to determine if the session is a user session or not.

Business Rule

The Dynamic Share is the configuration on how to share out a record. These are triggered by Business Rules on the table you specified. If you are unfamiliar with Business Rules, these are rules/actions defined per table that are ran when you create, update, or delete a record.

Through the Dynamic Share you can specify when this Business Rule runs with respect to other Business Rules and the actual update. This may impact your sharing with regards to Sharing between ServiceNow instances or other platforms such as for comment handling.

The options are:

  • Before (share the record before the insert/update/delete)
  • After (share the record after the insert/update/delete)
  • Async (share the record asynchronously to the insert/update - deletes not allowed)

For more information on this option, see Business Rule When.

Create / Update / Delete

These will correspond to the created Business Rule's allowed operations for the Dynamic Share. By marking these True (checked) the Dynamic Share will be triggered for each action of:

  • Creating a record
  • Updating a record
  • Deleting a record

A message will be generated with respect to each action type. For example an incident message will generate a message with the following respective name:

  • incident.insert
  • incident.update
  • incident.delete

Which will be handled by the Subscribing source as that action.

Update Or Insert

When marked True (Checked) messages will be marked as “bulk” (incident.bulk). The Subscribing source will then treat this as an “upsert” message and will query to see if this records exists. If so update that record otherwise insert that record. Checking this will automatically check the “Create” and “Update” checkboxes.

You may want to use this if the destination may not have been pre-seeded with the Dynamic Share's data.

Audit Delete Listener

This feature allows Dynamic Share configurations to capture delete events for records that may have bypassed the ordinary “delete” business rule, for example an up stream business rule that calls “setWorkflow('false')” or cascade deletes. Setting this option will create an “on insert” business rule on the Audit Delete [sys_audit_delete] table and enqueue deleted records noticed through this approach.

For more information on this option, see Use Audit Delete Listener.

Delete on Class Change

This is a feature was introduced in Carbon. If you are changing the Class of a record, for example converting it from an Incident to a Problem you may want this. When you convert the class of a record you are retaining the primary key of the record, however, it belongs in new table. If you are sharing to a database this will mean that you have a record in the incident table that is orphaned as it no longer exists in ServiceNow. Enabling this will delete that orphaned incident record.

ServiceNow will handle class changes automatically, so you do not need to enable this for a ServiceNow to ServiceNow integration.

For more information on this option, see Delete on Class Change.

Parent / Child Hierarchy

When selecting a table to Dynamically Share it is important to keep in mind the parent/child hierarchy of the record. ServiceNow covers that here under their Tables and Classes documentation.

Child Table Only (Default)

By default we share out the records as the child class. This means that if you are sharing [cmdb_ci] you will receive Windows Servers, Linux Servers, Network Gear, etc. You will receive the record as it is defined (by the sys_class_name) in the single table it is defined by (Windows Server, Linux Server, Network Gear).

Share Base Table Only

If you check “Share base table only” you are sharing the base table only as defined in your “Table” reference. This means that you are explicitly sharing the version of this record for the table that you will select. So if you are sharing [cmdb_ci] you will receive all records as the base [cmdb_ci] record into the [cmdb_ci] table with only the columns related to [cmdb_ci].

Include All Child Tables

If you choose “Include All Child Tables Only” this will share out all the layers of the data. For our Windows Server example above that means a share on Configuration Item [cmdb_ci] will share out a Configuration Item, Hardware, Computer, Server, and Windows Server record, into the respective 5 tables.

You can read more about the handling for the ServiceNow Hierarchy here.

Additional Settings

The additional settings of the Dynamic Share control how you share out the base record, share out related records, and where you share them to.

Through the Dynamic Share you can also share out any records related to the initial table records. This includes any:

  • Attachments
  • Embedded Images / Videos
  • Journal Fields
  • Audit Log
  • Referenced Fields

Of the main record. By default this will share the related records per table as they are created.


The attachment options will share out the sys_attachment (metadata) as well as the sys_attachment_doc (data) records for the attachments. So if Sharing to another ServiceNow instance you will need to Subscribe to both sys_attachment and the sys_attachment_doc to get the entire attachment. Attachment deletes are not currently supported through this checkbox. This will require you to create a Dynamic Share against those if you want to support this.

When selecting the “Include attachments” option on a Dynamic or Bulk Share, Attachment records ([sys_attachment] and [sys_attachment_doc]) will be placed in a separate outbound table. This is the Outbound Attachments [u_psp_attachment_out_message] table found in the “Messages” section of the app. This was done to improve performance and place priority on your table's records. A separate scheduled job will run every minute (default setting) to process and share these records out.

Embedded Images / Videos

A checkbox to indicate if embedded images/videos related to this table should also be shared. This is in general more for legacy knowledge records where data was embedded in their wiki / html as opposed to an attachment.

You can read more about sharing embedded images / videos here.

Journal Fields and Audit

Comments in ServiceNow are stored within the table Journal Field [sys_journal_field] and are related to the base record. In other words, they are not stored directly on the base record.

You can read more about the handling for these two from the following:

Include Referenced Field Records

This feature can be used to share referenced field records related to you base table. For example, you can set this up on your Incident Dynamic Share to Share the “Assigned To” User [sys_user] and the Configuration Item [cmdb_ci] of the Incident, for each Incident.

You may want to use this if you cannot easily define the parameters to share out the referenced records otherwise. However, if you can we recommend you to set up individual Dynamic Shares for those records instead.

You can read more about this feature Include Referenced Field Records here.

Table Maps

This feature is used to customize the payload of the Outbound Message in a very granular way. These are utilized in our SIAM integrations to create a message that can be easily sent to other ServiceNow instances or platforms (Jira, Salesforce, Remedy, etc).

If you are just replicating to a database you will likely not need these, however, if you are creating an integration between two parties this will likely be of assistance.

You can read more about this feature, Table Maps here.

PSP Share Table Map

As an advanced option you can configure Table Maps per referenced record. So when using the “Include Journal Fields” option you can apply a Table Map to modify the payload of the Journal Field message.

You can read more about this feature, Share Table Maps here.

Target queue

The specific queue that data from this table will be sent to for Subcribing/consumption by another instance. This queue will need to be defined in Shared Queues.

A target queue must be specified for a Dynamic Share to be created.

View Name

You may specify a view name within the Additional Settings to limit the fields shared out to just the fields available in a view. By default we share out all fields on the table.

You can read more about this feature, Field Restriction Using UI Views here.

Conditional Share

These are an advanced option to provide greater control within a single Dynamic Share. You may use them if for example you are sharing Incident to 5 clients. They each have their own Shared Queue and their own Table Map. Within this single Dynamic Share you can create 5 conditional shares to route off the data appropriately. It is helpful when you are Sharing the same table with several configuration with minor differences.

You can read more about this feature, Conditional Shares here.

Filter and Enrichment

The filter and enrichment tab allows you to control what type of operations you are skipping as well as giving you the option to use scripts to enrich the message you are sending out.


A set of conditions in order to share data from this table. For example, if you want to share only data related to one customer or one assignment group you would define that condition within here. Using this in combination with “Target queue” allows you to configure strict Sharing configurations to defined endpoints.

Before share script

This is a script that gets executed right before the shared message is being queued up. The object is in GlideRecord type and can be accessed via the globally available variable called current.

For an example of how to use this script, go here.

After share script

This is a script that gets executed right after the shared message is being queued up. The object is in GlideRecord type and can be accessed via the globally available variable called current.

For an example of how to use this script, go here.

Sharing column updates to ignore / share on

You can have greater control on when to Dynamically Share out records by selecting certain updates to trigger the Dynamic Share or certain updates to skip the Dynamic Share.

Select Column Updates To Ignore On

You may want to use this for example you are Sharing the User [sys_user] table. Every time a user logs in it updates the “Last Login Time” column. If this is the only column that was updated you might not care to share this out every time they login. Another common example is using discovery which updates the “Last Discovered” column frequently despite not anything else.

You will specify columns to ignore on. If you put in columns A, B, C and a message will only be sent if anything other than those columns are updated.

Select Column Updates to Share On

This is really the reverse of the previous option where you are specifying the updates to certain columns to trigger on. For example if you only want to update your CI information when the “Install Status” or “IP Address” changes than you can configure that here.

You will specify columns to ignore on. If you put in columns A, B, C and a message will only be sent if anyone of those columns are updated.


How to implement these two options are detailed here, along with how to manually configure the same within a Before Share Script instead.

Share only selected fields

You can specify within this to Share Only Selected Fields. After marking this True (checked) and saving the form you will add in records into the related list to specify which subset of columns you want to replicate. You may want to use this to restrict what data you are sending between destinations. You can equivalently use a Table Map to accomplish something similar.

You can read more about this feature, Share only Selected Fields here.

Share only updated fields

You can specify to share only the fields which have been updated. This is a fairly uncommon use cases as most of the Subscribing tools we have will account for this automatically. However, if you want to limit the outbound data you can utilize this feature.

You can read more about this feature, Share Only Updated Fields here.

Scheduled Sync Up

Scheduled Sync Up can be used to shared data out as a backup (for redundancy) or as an alternative option to the real time aspect of the Business Rules (for inserts/ updates).

For the most part if you want to utilize this you will just specify an “Interval” and hit “Activate Sync”. You can choose an interval of 5, 30, or 60 minutes to say every interval Share out all the records which have been updated since the last time I ran.

This can be helpful to provide redundancy in your Sharing or to account for records which are being updated without triggering the Business Rules.

You can read more about this feature, Scheduled Sync Up here.


This tab is only available if the “Advanced” box is checked

Enable Debug Logging

An option available in both Bulk and Dynamic Sharing that will enable debug logging for a particular share configuration. This will take precedence over the global debug logging property under Control and Configuration > Properties.

You may want to use this if you are running high volume in production and you don't want to enable debug logging within the whole Perspectium application on your instance.

Enable Data Obfuscation

You can enable Data Obfuscation to comply with the General Data Protection Regulation (GDPR) to obfuscate patterns/sets of data as they are leaving the instance.

You can read more about this feature, Data Obfuscation here.



The “Notes” box allows you to write notes for communication/organizational purposes. The notes field is not mandatory. Once any changes have been made it will automatically save the changes to the notes box.

Actions & Related Lists

UI Actions

Run a bulk share


The “Run a bulk share” button allows you to schedule a bulk share to run for this table. This can be useful for when you create a dynamic share and want to initially seed the subscriber (another instance or database) with the table's data.

Pressing this button will save the dynamic share and schedule a bulk share to be run. The bulk share will honor the dynamic share's configurations where relevant such as include journal fields, include attachments and filter conditions. The bulk share will be related to this dynamic share so you can see it in the dynamic share's related list.

If the dynamic share has the “Share base table only” option selected, the bulk share will unselect the “Include child only” option so that both are consistently sharing the same records (i.e. both are sharing child records only or sharing the selected base table only).

Outbound Messages


On each dynamic and bulk share, a related list will display all messages in the Outbound queue for the share:

The “Delete this share's messages” list button is provided if you want to quickly delete all messages related to this share in the Outbound queue. Note that if the messages are in a “Sent” state, they will have already been sent to the Perspectium MBS server so deleting them here will only remove the entries from the Outbound queue.

This option requires access to the “parent” global variable. If the variable is undefined (changed by another business rule) then this option will not be displayed.


Unsupported Tables

Users are validated from choosing tables that do not support dynamic share business rule. Here is the list of tables that are not supported:

  1. Sys Audit[sys_audit]
  2. User Role [sys_user_has_role]

Domain Handling

Domain separation


On domain separated instances you will have to take into account the domain of the Dynamic Share's Business Rule. Each Dynamic Share will have a corresponding Business Rule to process the insert/update/delete of a record. This Business Rule will be created in the domain of the current user. That Dynamic Share will then only apply to that domain of records.

For example, if the user creates a new incident record in the Top/Alpha domain, the record's domain will be saved as Top/Alpha. If the Dynamic Share was created by a user in the Top/Beta domain the Business Rule will be created in the Top/Beta domain. This will then mean that this Business Rule, and therefore this Dynamic Share, won't replicate the incident we just created in the Top/Alpha domain.

We recommend that you change your domain to “Global” prior to creating your Dynamic Shares. If the Dynamic Share was created under the Global domain than there is no issue as it will then apply to all domains. It is possible to set the domain of this to Top which in our example above would apply for both Top/Alpha and Top/Beta.

The following warning will display when creating a dynamic share with a domain that is not set to global:

You can see all your Dynamic Share's Business Rules, and their domain, by going to the Business Rules module under Replicator.

The Business Rule's domain will be set to the user's domain upon creation. This is handled internally by ServiceNow's scripts. So we cannot enforce / override this by setting the domain to global automatically. This issue currently being reviewed and may change at a future date.

Display Domain and Scope


If you are on domain separated instance, then you can now see the domain and application scope the share's business is created in under Business Rule. For example if you created a dynamic share's business rule in global domain and application scope, then it will look something like this

If you are not on domain separated instance, then the domain field in the business rule will be hidden. This is because the domain for domain non-separated instance will always be global. The business rule will look something like this for non-separated instances

You can also find a general picture of where all of your dynamic share business rules are created in on Dynamic Share Business Rule Dashboard. Click here for more information.

Create a Domain-specific Dynamic Share


As of the Europium release, you can create a dynamic share that will be run within a specific domain. To create a domain-specific dynamic share:

  1. Log into your domain-separated ServiceNow instance and navigate to Perspectium > Replicator > Dynamic Share or simply type and then select Dynamic Share in the left side navigation window.
  2. At the top of the form next to Replicator Configurations, click New to create a new dynamic share. Alternatively, to edit an existing dynamic share, click into the dynamic share you want to change from the list.
  3. Check the Advanced box on the right side of the form. Then, click the Advanced tab.
  4. Next to Business Rule Domain, click the magnifying glass icon and then click the domain that you want to run the dynamic share in.

replicator_snc_share.txt · Last modified: 2019/01/17 10:48 by timothy.pike