User Tools

Site Tools


Dynamic Share

Setting up dynamic share allows a ServiceNow instance to share table data in real time. The consumer or subscriber of this data can be another instance of ServiceNow or a Perspectium Agent. You will need to create a share configuration for each table you want to share.

Creating a Dynamic Share

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

2) The Perspectium app comes with some of the more common tables to be replicated such as incident and problem. Click on one of those tables or 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, choose a table from the dropdown and then have the “Active”, “Create”, “Delete” and “Update” checkboxes all checked. You can choose the “Activate all” (15) option at the bottom of the form and this will checkmark all four checkboxes (and “Deactivate all” (16) will in the opposite case uncheck all four).

Name: The name of Dynamic Share configuration. This helps to distinguish and organize different configurations i.e. Oracle Database, ServiceNow DEV to UAT, SIAM Jira, etc. C Release

Table : The name of the table to share data.

Active : A checkbox to indicate if this table is actively sharing.

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]

When selecting a table to dynamically share, keep in mind that the actual child table record could be shared instead. See ServiceNow tables and classes. For example, when sharing cmdb_ci_server table will produce shared output for any child table records like cmdb_ci_unix_server or cmdb_ci_win_server because these tables extend cmdb_ci_server. This design will prevent parent records from being shared without their absolute child records which would cause data corruption at the subscriber.

Direction : Share - This field will not be editable as it is used for both share and subscribe configurations and indicates the type of configuration.

Shared Records : The number of records that have been shared as of this time. This field can be ignored.

Trigger Conditions

Interactive Only : a checkbox to indicate if the replication should only happen when a record changes from the user interface (i.e ignore replicating changes from background jobs).

Business Rule When


Specifies when the replication business rule should run. For more information on this option, see Business Rule When.

Business Rule Order

v3.2.7 patch3

Specifies the order number for the replication business rule. In certain situations, you may want to change this value in order for the dynamic share trigger to execute prior to any other business rules. There may be a situation that a system our custom business rule executes the setWorkflow(false) API such that our trigger is bypassed, you will want to identify that business rule and adjust our trigger to run before that.

The default value is 50 but changing the value may be useful for when conflicts with other business rules on the table lead to the following error:

Exception (TypeError: Cannot convert null to an object. (; line 1)) occured while evaluating'Condition: 
PerspectiumReplicator.isReplicatedTable(current.getTableName(), "share", current.operation().toString())'
in business rule 'Perspectium Replicate' on cmn_location:Test; skipping business rule

In this case you will want to change the business rule order to a lower number (such as 1) so that dynamic sharing happens before other business rules are processed which create this error.

Update or Insert : A checkbox to indicate that this dynamically shared record is subjected to an update (by sys_id) or insert if current record is not found, at the consumer. v3.1.8

In general, it is suggested to select this option. If this option is not selected and an update to a record is shared where the record does not exist on the consumer, the consumer will skip processing the message since it does not have the record to update. Selecting this option ensure the record will be created in this scenario.

Not selecting this option is usually only best for performance considerations (such as a table that is dynamically sharing thousands or millions of records each day) and when you know this sharing instance and its consumers have the same records when dynamically sharing was enabled for this table.

Share Base Table Only : By default, Dynamic Share will share the child table records of the configured table. By checking the new option Share base table only, you are instructing the dynamic share process to only share the table records of the table that is configured.

Create : A checkbox to indicate if this table will share records on creation.

Delete : A checkbox to indicate if this table will share records on deletion.

Use 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 sys_audit_delete table and enqueue deleted records noticed through this approach.

Update : A checkbox to indicate if this table will share records on update.

Delete On Class Change : This is a feature introduced in vCarbon. You can read more about it here. In summary it is to delete the “orphaned” record left over in your external database when you change the class of a record.

Additional Settings

A checkbox to indicate if sys_journal_field entries related to records in this table should also be shared.

When this option is selected, the “Include audit log” checkbox option will appear allowing you to specify if you want to share related sys_audit records as well.

As of release v3.19.0 the sys_journal checkbox option is no longer needed for the Include audit log checkbox to appear. This allows the user to share the sys_audit records without sharing the sys_journal records.

For ServiceNow to ServiceNow replication you will want to select both journal field and audit log options to accurately update the history/activity log on the subscribing instance. As well, you will want to either have a “global” subscribe or subscribe to both the sys_journal_field and sys_audit tables on the subscribing instance to receive these records.

Prior to v3.11.0, selecting the “Include journal fields” option would automatically share both sys_journal_field and sys_audit records. By upgrading to v3.11.0+, the “Include audit log” option is not selected by default on any current dynamic or scheduled bulk shares and thus sys_audit records will not be shared out. You will have to go into each dynamic or scheduled bulk share and select the “Include audit log” option in order to continue sharing sys_audit records.

2016/07/06 17:04 · Paul Nguyen

Include Attachments

A checkbox to indicate if attachments related to this table should also be shared.

Note that on the instance where you set up subscribe, you will need to set up the sys_attachment and sys_attachment_doc tables as active subscribers for this option to work.

Because attachments are included using script actions to capture them when they're attached to a record, attachment deletes will also require their own Dynamic Share as the “Include Attachments” button does not account for attachment deletes.

Attachments do not honor the ignore flag in the before share script and thus any attachments will be shared out if it meets the dynamic share's conditions.

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 will help 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.

2017/06/29 13:42 · Magdalena Ninette

Include embedded images/videos : A checkbox to indicate if embedded images/videos related to this table should also be shared.

For tables such as Knowledge (kb_knowledge) that have HTML fields where you can embed images and videos, the “Include embedded images/videos” option on both dynamic and bulk share configurations will also share the embeded images and videos so that subscribing instances can display them properly when displaying the table's records.

Only “HTML” or “Translated HTML” type fields are supported for sharing embedded images and videos. If your field is any other type (such as “String”) embedded images/videos will not be shared out properly.

By default, when you select “Include embedded images/videos”, the “Include attachments” option will also be selected as the actual embedded images and videos are stored in the attachment tables (sys_attachment and sys_attachment_doc) and thus must be shared from those tables for sharing to work correctly.

Note that on the instance where you set up subscribe, you will need to set up the following tables to also subscribe in order for this option to work properly:

If you are re-sharing a record that a subscribing instance previously received and is showing broken images/videos (because the first time sharing didn't properly share these embedded images/videos), you will need to clear your browser's cache after the subscribing instance receives the re-shared messages for these images/videos to properly display. ServiceNow caches embedded images/videos, even ones that were previously broken but are now fixed.

2015/10/14 19:57 · Paul Nguyen

Include Referenced Field Records

A checkbox to indicate if referenced field records related to this table should also be shared.

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

Table Map : This feature is used to map and/or transform the outbound SericeNow field data for the record being replicated.

Target queue : A specific queue that data from this table should be sent to for reading by another instance. This queue will need to be defined in Shared Queues. This is useful for a case where you want to send specific data to one instance (such as a specific customer's data you indicate in the Condition section) and you don't want that instance to be able to subscribe to other data from your sharing instance. In general you can leave this option blank.

Filter and Enrichment


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 you would specify a condition here. Using this in combination with “Target queue” allows you to configure it such that only a specific set of data will be shared with one particular queue/instance so as to restrict that subscribing instance to only receive a set of data such as one customer's data.

Before share script

This is a script that gets executed right before the shared object 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. v3.1.8

After share script


The “After share script” section allow you to specify a script that will run after the dynamic share has shared a record. This can be useful for when you run scripts in the Before share script section that you want to then cancel out after the dynamic share has run.

This section expect server side javascript. Within your script you have access to the following variables:

current This represents the record that is being shared out
dynamicshare_gr B Release An object corresponding to the dynamic share configuration itself (i.e. you can use dynamicshare_gr.table_name to access the “table” field of the dynamic share)

One example use case is to use the Before and After share script sections together to specify a language to share out records in. In the Before share script section you would have the following script so all records shared out will have English translated text (for fields that support translation as mentioned in the language link above):

var lang = gs.getSession().getLanguage(); 
var gc = (typeof GlideController != 'undefined') ? GlideController :;
gc.putGlobal('user_lang', lang);

And then in the After share script section, you would cancel this change so it doesn't affect users who are using the system and want to see translations in their selected language:

var gc = (typeof GlideController != 'undefined') ? GlideController :;
var userlang = gc.getGlobal('user_lang');
2017/06/15 23:15 · Paul Nguyen

Ignoring records in before share script


In the Before Share Script of a Dynamic or Bulk share configuration, you can set the global variable ignore to the boolean value true to prevent the current record from being shared.

For example, the following script ignores the Dynamic sharing of an incident record when the priority field value is 1:

if (current.priority == 1) {
    ignore = true;

As another example, the following script will ignore sharing the record with a number value TKT0010001 during Bulk sharing of all ticket records:

if (current.number == "TKT0010001") {
    ignore = true;
Ignoring a share if only one field has changed

For cases where you have a table's records updated frequently but data doesn't actually change (such as a table that gets updated every single day via another integration or ServiceNow Discovery), you may not want the table's dynamic share (with interactive only not selected) to run and share out any records.

For example, say the field that gets updated every day is u_last_discovered_date. The rest of the fields don't usually change, and you don't want to share these records out again since the subscribing side (such as a database) doesn't really need the latest u_last_discovered_date.

In these cases, you can run the following script to ignore sharing the record:

function listChangedFields(obj){
	var flds = [];
	var aud = new GlideRecord("sys_audit");
	aud.addQuery("documentkey", obj.sys_id);
	aud.addQuery("record_checkpoint", obj.sys_mod_count);
	while ({
	return flds;

var changedFields = listChangedFields(current);
var ignoreFields = ["priority", "urgency"]; // If any changed field falls outside that list, the update will be sent

ignore = true;

var util = new ArrayUtil();
for (var i=0; i<changedFields.length; i++){
	if (!util.contains(ignoreFields, changedFields[i])) ignore = false;
Ignoring a share with multiple field changes

In v3.22.0 users can activate the checkbox “Select column updates to ignore” to ignore sharing records with multiple field changes. To begin, click the checkbox to see the related list which will allow you to select the fields.

Next you can select the fields that you want to be ignored when updated. Using the picture above as an example, the record would be ignored if the Description and Name fields are the ONLY fields that have been updated; if any other fields have also been updated the record will not be ignored.

Sharing on specific field changes

In Bismuth users can activate the checkbox “Select column updates to share on” to share a record only when one of any number of chosen fields are updated. To begin, click the checkbox to see the related list which will allow you to select the fields.

Note that clicking either “Select column updates to share on” or “Select column updates to ignore” will hide the other checkbox. Only one option can be selected.

Next you can select the fields that you want to trigger a share. Using the picture above as an example, the record would ONLY be shared if the Assigned To or Description fields have been updated; if these fields have not been updated, the record will be ignored.

2016/02/29 17:41 · Paul Nguyen

Share only selected fields

Share only updated fields

Scheduled Sync Up


Activate Sync : Check this box to start the sync.

Started : The time syncs started

Stopped : The time syncing stopped

Interval : The intervals for syncing, choice of 5, 30, or 60 minutes

Last Time Sync : The last time syncing occurred, this also marks when the data should start for each sync

Number of Records Synced Last Interval : The number of records from the Last sync time that needed to be sync

Note if you have multiple share configurations for the same table (such as different share configurations that each have a different target queue), any changes to the current object may affect any conditions you have to share since this same current object is referenced as we iterate through the table's different share configurations.

For example, if your have multiple share conditions for the ticket table (one will share to the target queue psp.out.servicenow.test and the other shares to the queue and all have the condition short_description is 'test' in order to share records, if one of your share configurations has the before share script of: current.short_description = 'test123'

Then other share configurations for this will not share the record to their target queues since the short_description of the current object has been changed to 'test123'.

4) Once done, click “Submit” (new table configuration) or “Update” (current configuration) to save your changes. Next you will need to setup a subscribe configuration on SNC instance you wish to receive data from this sharing instance.

Note if any fields do not appear on your form, right-click on the “Replicator Configuration” title and choose Personalize > Form Layout and then add the missing fields to the form.

Shared Queues

Shared queues are a way to specify message queues a table should share to when creating a share configuration. This can be useful in cases where you want a specific set of data (such as one company's data) be shared with one particular instance.

Please ensure you have the proper credentials to create the message queue or the queue has been created by the Perspectium team ( on the Perspectium server before creating it here inside ServiceNow.

1) To create a shared queue, go to the Replicator > Shared Queues option in the Perspectium app:

2) Click the “New” button at the top to create a new shared queue:

3) The Shared Queue form will appear with the following fields:

  • Name : This is the name of the message queue itself. This will generally be in the format of



    where <instance_name> is the name of the subscribing ServiceNow instance or <agent_name> is the name of the subscribing replicator agent that will be receiving messages on this queue. For any questions about the proper queue name for your subscribing instance, please contact

  • Endpoint URL : Click on the lock icon to edit the field and enter the server URL as provided by Perspectium (this will usually be the same URL as found in the Configuration > Properties page). Note the value here should be entered starting with “https:” and with an ending slash “/” such as
  • Queue user : The message queue username as provided by Perspectium.
  • Queue user password : The message queue password as provided by Perspectium.
  • Direction : The field will default with the value “Share” and should be left as is.
  • Order : The order for which the data is being processed, a smaller number will cause the data to be sent sooner.
  • Active : A checkbox to indicate if this shared queue is active and available to be used.

Note that in v3.16 multiple queues cannot have matching names and endpoint regardless of direction (share or subscribe).

Note that in v3.17 queues cannot have the default subscribed queue's name (i.e “psp.out.servicenow.<instance>”).

Note that in v3.20 the instance field is removed from the form as it is unused

4) When finished, click “Submit” to save this new shared queue. This shared queue will now be available for use in the “Target queue” field when creating a new share configuration.

Targeting a specific ServiceNow Instance or Replicator Agent

All ServiceNow instances that are integrated with Perspectium are provisioned with a message queue that is read by default. This message queue will have the format of


So for example, is provisioned to read from


However, to read or write to this message queue, the client would first have to have the credentials and the server endpoint configured. The Shared Queue entry allows you to configure all three of these parameters.

Replicator agents are similarly provisioned with a message queue that is read by default. This message queue will have the format of


and is based on the “Agent Name” as specified when first installing the agent. For example, the agent named demo_mysql is provisioned to read from


For the case when another Replicator agent or ServiceNow instance wishes to enqueue replication records specifically to target another ServiceNow instance or Replicator agent, just create a new Shared Queue entry with the right credentials, endpoint, and queue name for that instance and use it in your Bulk Share or Dynamic Share. The following example shows a Shared Queue configuration for the ServiceNow instance

Separate encryption and decryption keys per queue


Normally, within the same company implementation of Replicator the use of one universal encryption key for both outbound and inbound messages is sufficient and convenient.

There comes a time when an external integration with another company such as a service provider is required but giving out the universal encryption key is both insecure and unmanageable. This feature allows separate encryption and decryption keys to be defined for both outbound messages and received message symmetrically so that a pre-agreed key can be shared with an external consumer of integration data without risk.

Shared Queue Record Encryption Key

By specifying a 24 or more character encryption key in the following Shared Queue definition, ensures that all data flowing through this queue will be encrypted using only this key.

Subscribed Queue Record Encryption Key

By specifying a 24 or more character encryption key in the following Subscribed Queue definition, ensures that all data coming in through this queue will be decrypted using only this key.

2016/06/02 16:09 · David Loo

Update Queue Status

In v3.13.0, an “Update Queue Status” UI action has been added that will allow you to test the connection of the queue and display the current number of messages in the queue.

When clicked, “Update Queue Status” will use attempt to connect to the endpoint URL using the queue user and password to query the queue name for the number of messages it currently contains. The result of trying to connect and query the queue will be displayed in the “Status” field:

In v3.18.0 of both the update set and MBS, the message will display if the queue does not exist instead of displaying an error as in previous versions. We've also added the ability for include your Queue Status within the Replicator Overview page.

Purge Queue


Purging queues is only supported in you have been provisioned in a vhost. Please contact to set this up and for more information.

The “Purge Queue” UI action allows you to purge a queue of all messages in it. This is useful if you ran a large bulk share and no longer want or need a subscriber to consume these messages.

When clicked, “Purge Queue” will attempt to connect to the endpoint URL using the queue user and password to purge the queue of all the messages it currently contains. The result of trying to purge the queue will be displayed in the “Status” field.

Proceed with caution when purging a queue as the messages cannot be recovered.

In v3.24.0 the user can no longer purge a queue that contains over 1 million records. The user must contact support to purge the queue.

2017/03/07 13:47 · Paul Nguyen

Instance Created On

Dubnium Shared queues contain an “Instance Created On” field which is auto-populated based on the name of the instance in which the queue was created. This field is leveraged in cases of instance migrations where shares should not be triggered on migration.

Resetting "Instance Created On"

At the bottom of your shared queue, there is a UI action where you can reset the “Instance Created On” field to be your current instance. This should be used in cases where you migrated your instance and then want to reactivated a shared queue.

Perform a Load Test


You can determine the approximate time it will take for your bulk share to reach your Perspectium MBS server by enabling the Load Test option. To do this:

  1. Log into ServiceNow and navigate to the Shared Queues module.
  2. Create a new shared queue record or click into the shared queue record that you want to perform a load test for.
  3. At the bottom of the form underneath the “Status” field, check the Load Test box. Then, click Update
  4. Navigate to the Bulk Share module and locate any bulk shares with the same target queue which you have enabled a load test for. The Duration field will indicate the approximate time it will take for that/those bulk share(s) to reach your Perspectium MBS server.
2015/01/30 20:38 · Paul Nguyen

In version v3.16.0 users can create multiple dynamic shares with the same table and queue name. Dynamic Share's creation will be blocked on uniqueness only when there is a matching dynamic share with matching: Table, Target Queue, Business Rule when, Insert, Update, and Delete.

Field Restriction using UI Views


By default, dynamic and bulk share will share all fields available in a table. There are times when you want to control the number of fields being shared from your ServiceNow table. By specifying a UI Form View in the definition for Dynamic Share or Bulk Share you can limit the fields to only those that appear on the form view that you have personalized. See Personalizing Form Views in ServiceNow

Using Form View to restrict fields does not make sharing data run faster, rather it is slower because more work needs to be done to remove the fields you don't want to share

The dynamic share example below shows using the Self Service (ess) Form View for Incident to limit the sharing only to the fields in that view.

You want to use the actual Form View name, not the Title for the View Name value. For example, use ess instead of Self Service.

The example below show the same view being used in a bulk share.

The number of records returned in a view is based on the glide.db.max_view_records system property. Bulk shares of any views that have more records than this property will only be able to share this number of records and because of the way ServiceNow stores records, you will need to specify a condition on the bulk share to query based on a field that you know will not be empty on all records.

2015/04/02 16:50 · David Loo

Message Set Activity

Because of new application memory usage limits in Jakarta and to better optimize agent performance, message set activity is not tracked for outbound processing of messages to MBS and disabled by default in the agent as of the Argon release


To better track the status of messages as they move between various components (ServiceNow instances, Perspectium MBS, agents, etc.), messages are grouped into a “message set” distinguished by a unique id (in the case of messages that are replicated from ServiceNow instances, messages from the same dynamic or bulk share are grouped together in a message set and the dynamic or bulk share configuration's sys_id is used as the unique id).

So as messages leave ServiceNow and reach MBS, the message set is tracked so as to determine how many messages successfully make it through each component as well as any failures. This information is provided in the Message Set Activity related list located at the bottom of the dynamic and bulk share configurations:

To refresh the related list at any time with the current information available, click the “Update message set activity” form link above all related lists which will then make a call to the Perspectium MBS server that the messages were sent to so as to retrieve this data.

In v3.6.0, message set activity is refreshed automatically when loading the dynamic or bulk share configuration page. An error message will also be displayed on load if there are any failures in the message set activity:

As well, the duration, successes and failures are now summed to provide total values for each:

In v3.7.0, message set activity will display how many records the ServiceNow instance has processed for a dynamic or bulk share (“snc-processed”) and only display one record for each set of unique component name and component type combination so as to make it easier to view all activity:

In v3.8.0, message set activity will display the number of records “skipped” by a subscribing agent. “Skipped” applies to cases where the agent may skip subscribing to a record, such as when the agent was configured to exclude receiving records for a specific table.

In v3.9.0, message set activity will display the records ServiceNow instances actually share and subscribe. Since a separate scheduled job runs to actually send messages from the outbound messages queue (Perspectium > Messages > Outbound), “snc-shared” represents these messages that have actually been shared from this instance and sent to Perspectium MBS.

As well, if you are sharing messages to another ServiceNow instance, you can see how many messages this instance has received. “snc-subscribed” designates any ServiceNow instances that are subscribers (with their instance name listed in the “Component Name” field) and the numbers of records they have received.

In v3.13.0, message set activity will not display in a related list when a form is first loaded to decrease load time. Instead, click “View message set activity” to see the message set activity in a pop-up window. Note: it may take a few seconds to display the pop-up window because the message set is being updated.

In v3.14.0, message set activity's component types use a more understandable language to better what type of replication occurred. See the chart below to see the changes.

Component Types
Previous Value Current Label
mbs-https Processed-MBS
snc-processed Processed-ServiceNow
snc-shared Shared-ServiceNow
snc-subscribed Subscribed-ServiceNow

In v3.16.0, message set messages will be placed into the outbound queue and sent with other outbound messages to improve instance performance.

2016/01/15 12:32 · Paul Nguyen

Use 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 sys_audit_delete table and enqueue deleted records noticed through this approach.

You can identify this Business Rule within your Business Rule table by filtering for those on the sys_audit_delete table and whose name starts with “Perspectium DL”.

Known Issue: There is currently a bug set to be fixed with Update Set v3.20.0. This bug can allow multiple Business Rules to be created for a single Dynamic Share configuration with this enabled. This would happen with each subsequent update to the Dynamic Share form. If you are using this it is recommended to verify the “Perspectium DL” Business Rules match the expected number.

If you would like instructions on how to circumvent this without a full version Upgrade contact for instructions.

2015/09/18 14:40 · David Loo

Limit Journal Entries and Audit Records


If your implementation of ServiceNow creates a lot of journal entries or audit logs e.g. automatically created or updated task records, enabling Dynamic Share could result in blocking delays during interactive updates.

As a default, when Include journal fields is selected, up to 100 records will be shared. This limit does not affect Bulk Share and can be adjusted by changing the system property com.perspectium.dynamic.sys_journal_field.limit.

Additionally, a new default limit of 200 is also set for dynamically sharing audit log records. This limit does not affect Bulk Share and can be adjusted by changing the system property com.perspectium.dynamic.sys_audit.limit.

If the properties do not exist in the list of System Properties, you may have to create them first.

2016/07/06 17:56 · David Loo

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.

2016/09/13 13:34 · Paul Nguyen

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).

2017/06/21 14:05 · Paul Nguyen



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

2017/07/25 10:04 · Ashkan Ghafari


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

Enable Debug Logging

D Release

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.

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 you to 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.

2017/11/07 17:43 · Vinh Nguyen

Display Domain and Scope

D Release

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.

2018/08/07 12:25 · Seung Suh

PSP Share Table Map

replicator_snc_share.txt · Last modified: 2018/08/07 16:19 by seung.suh