<style> .release-box { height: 30px; width: 100px; padding-top: 8px; text-align: center; border-radius: 5px; font-weight: bold; background-color: #828995; border-color: #FCE28A;} .release-box:hover { cursor: hand; cursor: pointer; opacity: .9; } </style> <meta name="robots" content="noindex"> <div class="release-box"> <a href="https://docs.perspectium.com/display/Lithium" style="text-decoration: none; color: #FFFFFF; display: block;"> Lithium </a> </div> |
A dynamic share is a job that allows for real-time sharing of ServiceNow records as they are created, updated, and/or deleted. In other words, dynamic shares are caused by some triggering event (such as when incidents are created, updated, or deleted). The data is shared to a subscriber, which can be another instance of ServiceNow, the DataSync Agent, or any number of the other applications that Perspectium can integrate with.
Dynamic shares can be configured per ServiceNow table. This setup can be used to control the format, conditions, and destination of the share, share multiple tables through the table hierarchy, run through advanced filters and scripts, share out related/auxiliary records, and more.
To access dynamic shares, go to Perspectium > Perspectium Core > Shares. Then, click Dynamic Share.
When creating a dynamic share in ServiceNow, you have the option of doing so with either business rules or flow designer. The major difference between these two options is that flow designer allows you to use dynamic share features without having to code. Click the hyperlinks to learn more.
Dynamic shares created with flow designer cannot be changed to business rules, and vice versa. If you want a dynamic share to use the alternate approach, you will have to delete it and create a new one. |
The context and instructions around creating dynamic shares are different between the two approaches. Skip to whichever approach you're interested in below.
These instructions are for creating a dynamic share using business rules. Instructions for creating a dynamic share using flow are in the next section.
Because this approach uses business rules to trigger sharing records out, if a user is updating records with setWorkflow(false) to turn off executing business rules (including async business rules), records will not be shared. In this case, consider using alternative approaches like Scheduled Sync Up, Scheduled Bulk Share or Flow. |
Prerequisites:
Use the Encryption Method dropdown to select a method to encrypt the data.
Cipher options include:
Encryption Method | Dynamic shared data will... |
---|---|
TripleDES | be encrypted with Triple DES. |
AES128 | be encrypted with AES-128. |
AES256 | be encrypted with AES-256.
|
Base64 Encode Only | have Base64 encoding only. |
Unencrypted | not be encrypted. |
To set the trigger conditions for this dynamic share, check the Create, Update, and/or Delete boxes, depending on the conditions on which you want your share to run:
Action | Record data will be shared out of your ServiceNow instance when... | |
---|---|---|
Create | new records are created.
| |
Update | record data is changed.
| |
Delete | records are deleted.
|
Alternatively, you can use Update or Insert under Runtime Settings.
When Update or Insert is selected, Create and Update actions will be grayed out and not selectable. Furthermore, when the messages are pushed out to Perspectium Cloud Server, the name field will contain:
|
This will instruct the consumer or subscriber to implement an update (by sys_id) or insert action when the sys_id is not found.
Choosing Flow Designer for dynamic shares makes use of ServiceNow’s Flow Designer to create a flow that will send records out of your ServiceNow instance as they are created and/or updated.
Because business rules may not always trigger when records are created and/or updated (due to changes done utilizing a script where setWorkflow is set to false to disable running business rules), this option is an alternative to ensure these changes are captured and shared out of your instance.
For more information, see ServiceNow Flow Designer and setWorkflow.
Starting with ServiceNow's Paris release, setWorkflow applies to Flow Designers to prevent flows from executing. |
Because of the many tables used by ServiceNow to build the Flow Designer engine, records will be inserted/updated in the following tables when a flow is created/updated and the first time each flow is triggered:
sys_hub_action_input
sys_hub_action_output
sys_hub_action_type_snapshot
sys_hub_flow
sys_hub_flow_block
sys_hub_flow_input
sys_hub_flow_snapshot
sys_hub_step_ext_input
sys_hub_step_ext_output
sys_documentation
This will result in text_index events being created for these tables for updates by Flow Designer. The approximate updates are as follows:
Action | Number of Inserts/Updates |
---|---|
Dynamic share creates flows for insert and update | 28 |
Insert flow is triggered for the first time | 9 |
Update flow is triggered for the first time | 12 |
Delete a dynamic share | 1 (sys_metadata_delete) |
NOTE: To ensure that the tables listed only grow to reasonable size, use ServiceNow's table rotation on the tables listed above. See ServiceNow Table Rotation on how to apply table rotation in your ServiceNow instance.
Once the dynamic share is created using Flow Designer, every field, except Active, will be read-only. You can only use the Active field to enable or disable the flow created with this dynamic share to ensure replication. |
NOTE:
In the Encryption Method dropdown to select a method to encrypt the data.
Cipher options include:
Encryption Method | Dynamic shared data will... |
---|---|
TripleDES | be encrypted with Triple DES. |
AES128 | be encrypted with AES-128. |
AES256 | be encrypted with AES-256.
|
Base64 Encode Only | have Base64 encoding only. |
Unencrypted | not be encrypted. |
Scroll to the Trigger Conditions tab and check as many of the following boxes as you wish:
Action | Record data will be shared out of your ServiceNow instance when... | |
---|---|---|
Create | new records are created.
| |
Update | record data is changed.
|
NOTE: Flow does not support delete. This is a platform limitation where Flow Designer only works on inserts and updates. To capture delete actions, you will need to create a dynamic share using business rules for delete, and have a separate dynamic share using flow for insert and/or update. If you choose to create a dynamic share for deletes, you may want to enable the Use Audit Delete Listener feature.
Additionally, dynamic share provides other options that can enhance sharing your record. Share base table records only, interactive only, and much more.
See optional features for dynamic share or optional features for dynamic shares and bulk shares.
NOTE: Scheduled sync up can be enabled with flow. However, this option is primarily used for capturing dynamic record updates and creates that may have been missed due to business rules being bypassed programmatically (e.g., via setWorkflow('false');) or automation that does not trigger business rules, which flow handles.
Editing the flow in the Flow Designer will not reflect on the dynamic share. Doing otherwise may cause some of the records to not replicate correctly. Calling the Flow Designer as a Sub-Flow may also cause some of the records to not replicate correctly. |
|
You can view information about the business rules created by each of your dynamic shares in the Dynamic Share Business Rules Dashboard.
To view your dashboard, go to Perspectium > Perspectium Core > Shares > Dynamic Share > Dynamic Share Rules Dashboard.
The first column of the dashboard displays the name of your dynamic shares, which you can click on to be redirected to the dynamic share record. And the second column specifies which table each share is targeting.
For the domain and application columns, a green checkmark indicates that the business rule is created in the global domain or application, whereas a red X indicates that the business rule is created in a non-global domain or application.
The last column checks whether or not the the business rule is unique. A green checkmark indicates that the business rule created by the dynamic share is unique, meaning no other share targets the same table. A red X indicates that the business rule is not unique, meaning at least one other dynamic share targets the same table.
When one or more dynamic shares accesses the same table, you may need to reset the dynamic share business rules for those dynamic shares (see next section).
When one or more dynamic shares accesses the same table, you may need to reset the dynamic share business rules for those dynamic shares.
You can reset dynamic share business rules for individual dynamic shares by navigating to Perspectium > Perspectium Core > Shares. Then, go to View Dynamic Share and click into the dynamic share you want to reset business rules for, and then click Reset Dynamic Share Rule under Related Links.
Alternatively, you can reset the business rules for all of your dynamic shares by going to Perspectium > Perspectium Core > Shares > Dynamic Shares > Reset Dynamic Share Business Rules. Then, click Confirm.