Once you have installed and configured DataSync for ServiceNow, and have successfully set up a dynamic share and understand how it works, there are various optional dynamic share settings that you can configure. These optional features can help you customize your DataSync experience and leverage DataSync's robust capabilities to make your organization's integration processes more powerful and streamlined.
Explore all of these available features below!
Data Alignment provides conflict avoidance to minimize the possibility of records becoming out of sync. For example, Instance A updates a record at the same time Instance B updates the same record—you now have the risk of conflicting records. Data Alignment (using dynamic share), is designed to minimize that risk.
There are two connected features to achieve data alignment (enable them in the following order):
This feature is enabled in the queue record. If a dynamic share is targeting a queue that has this property enabled, it will cause their messages to be posted immediately, rather than waiting to have the multioutput processor post these messages on a scheduled basis. If the outbound message is unable to be posted immediately, it will be put into the ready state and then sent along with other outbound messages during the next execution of the multioutput processor job.
Here's how to enable the post immediately feature in a dynamic share:
Using polling intervals for publish/subscribe messaging creates a potential issue for records to become out of sync if they are updated at the same time. By posting outbound messages immediately, the time frame for this issue is decreased. To further mitigate this potential issue from occurring, the subscribing system will check if the local record has been updated more recently when receiving an update. If so, the update is ignored.
In order to enable this feature, you need to create a create a subscribe record and enable the post immediately feature outlined in the previous section.
Then, follow these instructions to ignore delayed updates:
This feature sets up a recurring “catch up” job that incrementally bulk shares out a previous interval of created, updated, or deleted records. Enable this option to capture dynamic record creates, updates, or deletes that may have been missed (if business rules are bypassed programmatically (e.g., via setWorkflow('false');) or automation does not trigger business rules).
A scheduled sync up can be run with or without trigger conditions set up on your dynamic share. If your dynamic share has trigger conditions, records will be shared both out in real time and on the scheduled interval you select. If your dynamic share does not have trigger conditions, records will be shared out on the scheduled interval only.
|
Here's how to enable the feature:
This feature allows you to specify when business rules should run for dynamic shares. Dynamic shares can replicate data before an action is taken on the record or after an action is taken. These before and after values can be specified in the Business Rule When dropdown of a dynamic share.
Dynamic sharing a record using the before option allows you to share the record with journal fields as part of the record's XML. For example, if you share an incident record and specify “before”, the record will come with both the comments and work notes in the incident record's XML. Additionally, using the before option will cause the record to be shared before any after business rules are run. For example, if you have an after business rule that runs to update the record's state based on a specific condition, the after option will share the record out with the updated state, whereas the before option will share it with the previous state.
If you dynamic share a record using the after option, the comments and work notes will not be part of the record's XML but instead will be records in the sys_journal_field table (upon saving a record into the database, ServiceNow will separate journal fields from the record and save them into the sys_journal_field and sys_audit tables which is why you want to subscribe to the sys_journal_field and sys_audit tables when subscribing on a ServiceNow instance).
NOTE: In Iodine 7.0.9, support has been added for the new async_always option available with Rome+ and the legacy (deprecated) async option has been removed when creating new dynamic shares. If you have a current dynamic share set with the legacy async business rule when, this will not be changed to the new async_always so as to not disrupt your current active dynamic shares and since the legacy option continues to work. You can edit your current dynamic share and choose the new async_always option to upgrade to the new option.
When running as async, records will be sent out as .bulk, since the records are shared in the background and we will not be able to determine if the record was an insert or update at that point. Also, there is no dependency on “current” or “previous” in the Before Share script (such as checking for a condition where a field “changes”) and the “sequence” of other records being replicated cannot be guaranteed. So a change created when an incident is created where both have dynamic shares may result in the change being shared out before the incident is).
Selecting the async option will cause the trigger condition Update or Insert to be activated and the Delete trigger condition to be deactivated. |
Here's how to configure business rule timing for a dynamic share:
By default, dynamic shares have a setting that causes data to be shared out only when interactive actions are performed (for example, if a user comments on or resolves an incident), and not when non-interactive actions occur (for example, if a ServiceNow job closes resolved incidents after 7 days or an email engine creates records).
If you want to enable dynamic sharing of non-interactive updates, here's how:
Historical data fields refer to fields that were created or updated prior to running your initial dynamic share. You can use this feature to allow for the sharing of the following historical data fields to other ServiceNow instances:
Here'w how:
This feature allows you to dynamic share only the fields of a record that have been updated, instead of resending the entire record. This can be useful when your sharing instance is updated frequently and your subscribing instance(s) is relatively static. Here's how:
MySQL error may occur when using Share system fields. When that error is received on the agent, the database will still recover and save the record. However, each record that follows will replace one another since the primary key is altered and not defined. |
This feature allows you share only specific attachment file types (such as .xlsx, .jpg, .csv). If you want to share all attachments with your dynamic share, see ServiceNow attachments.
Here's how to enable the sharing of specific attachments only:
On the resulting dynamic share page, in the Miscellaneous tab, check the Advanced box. This will cause an Advanced tab to appear.
This feature allows you to share out attachments that were updated before your dynamic share was created. You will likely want to use this feature if you have already set up your dynamic share to share out all existing ServiceNow attachments, but also want to share out any previously uploaded attachments. Here's how:
On the resulting dynamic share page, in the Miscellaneous tab, check the Advanced box. This will cause an Advanced tab to appear.
This feature allows you to view any business rules that may have an impact on the dynamic share actions that occur (inserts, updates, and/or deletes). This is useful to view since the business rules that run before a dynamic share is executed often have an impact on the order of dynamic share execution. Here's how to view:
On domain-separated ServiceNow instances, dynamic shares are defined in ServiceNow's domain picker, and data will only be dynamic shared within that selected domain.
Here's how to view the domain for a dynamic share's business rules:
If your ServiceNow instance is on Washington DC or a newer version, you will need to create the glide.db.audit.lazy system property in your instance and set the value to true for this feature to work properly. With Washington DC, ServiceNow has disabled running business rules on the sys_audit_delete table for actions on this table that happen in the background (i.e. deleting records from an audited table such as the incident table and having it captured in the sys_audit_delete table). So this system property is needed in order for the Use audit delete listener feature to work properly. Click here for ServiceNow's documentation on this property. |
If you're using dynamic share on deletes, this feature ensures that records which may have bypassed the ordinary delete business rule are included in your dynamic share.
|
Here's how to use the audit delete listener:
If choosing to dynamic share on deletes, you may want to enable the Use Delete Recovery Listener feature. This feature will ensure that records that may have bypassed the ordinary delete business rule are included in your dynamic share. Unlike the Use Audit Delete Listener feature, this option will always appear regardless of the table being audited or not.
|
Here's how to use the delete recovery listener:
These features allow you to either enable or disable dynamic share of your records when specific fields are updated. Here's how:
This feature allows you to include only specific fields in a dynamic share when it is triggered. This can be useful when you don't want to or don't have permission to view names.
Alternatively, you can enable the sharing of selected fields only for ALL ServiceNow dynamic shares in your instance by navigating to Perspectium > Control and Configuration > Properties > DataSync Settings and checking the Share fields that belong to the selected table only option. |
Here's how to share only selected fields for a specific dynamic share:
In Iodine 7.0.0, there is a known error where having Share only selected fields enabled may not share out all the selected fields based on sharing setup options. |
This feature allows you to schedule a bulk share to run for this table. This may 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. This 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.
Here's how:
The dynamic share will save at its current state. For example, if the active box is selected, the dynamic share will save as activated. |
This feature allows you to set up a dynamic share to share out records when the display value changes for a referenced field. This is useful because it ensures that the record has the latest display value field.
For example, consider a dynamic share for the incident table, where this feature is enabled and the assigned_to reference field is set to share on updated display value field. In this case, if the display value of a sys_user record changes, incident records matching the dynamic share conditions with this updated user in the assigned_to field will be shared out with the dv_assigned_to value updated to the new display value.
Here's how to enable this feature:
On the resulting dynamic share page, in the Runtime Settings tab, under Triggers, check the Share on updated display values box.
When you manually set all fields in a table to not be a display field, no records will be shared for updated display values for that table immediately or after that. This is for cases of choosing a display field and after disabling the old display field in a short amount of time. The share will turn on again once a field is selected to be a display field. |
|
This feature allows you to limits which specific child records are shared when dynamic sharing to another instance. This is useful if you want to share some child records but not others. Here's how:
On the resulting dynamic share page, under General Settings, in the Sharing setup dropdown, select Share all table records and child records or Share the last descending child of each table record.
If you have created a new table since creating the dynamic share, the new table will not appear in the Table dropdown. If this is the case, you will have to create a new dynamic share and follow the above instructions during that creation. |
This is an advanced feature! For more information or assistance, contact Perspectium Support. |
If you are bonding your ServiceNow instance to another ServiceNow instance using Common Documents, you have the option to share deleted attachments. This feature enables deleted attachments to be captured and sent to the subscribing instance to delete the same attachments.
On the resulting dynamic share page, in the Miscellaneous tab, check the Advanced box. This will cause an Advanced tab to appear.
This feature allows you to create table maps for:
To enable the feature, you need to configure your dynamic share to display the PSP Share Table Map related list. Here's how:
Want to validate that your dynamic shares are being shared out correctly? Read how to do so here.