When replicating data, you have to specify a shared queue. You can think of this as a lane of traffic for your replication. In general, this will cover 90% of what you want to do.

Keep in mind, this means that if you only have one shared queue defined, you only have one lane of traffic. This could cause an issue if you are replicating data that you depend on in real time, and someone else launches a large push of data into the same queue.

In order to combat this, a common strategy we recommend is to create two queues: one for general replication and one for much larger traffic - a priority queue and a secondary queue. You can use the same credentials as the first shared queue - you will just give it a new name.

NOTE: This is only recommended when sharing multiple tables.

Make sure the subscribing side of this will also have the matching subscribe queue set up as well (set up multiple subscribing queues to match).

When creating a dynamic and/or bulk share, you will need to specify a shared queue. It is best practice to avoid replicating a table to more than one queue, i.e. the incident table should not be configured to target more than one queue, as this can cause data discrepancies especially if multiple queues are read by one Agent/instance. 

A bulk share is a job that queries a table and sends out a record for each. It can be set to run on a schedule, as a scheduled bulk share, to run at X interval and share records updated since X minutes/hours/days ago. The strategy here is that you don't quite need real time replication for this data and you can load it at these intervals.

1. Each Bulk Share is a “job”. Most production instances will have 2-4 nodes which can each execute 8 jobs at a time (8 “workers”). If you are on a 4 node instance you can therefore execute 32 jobs at once. If you schedule 40 Bulk Shares to fire off at midnight, we may “take over” the instance and all available workers. So, in general, we recommend keeping the concurrent bulk shares under 50% of the total number of workers.
   
   

2. For example, if you are scheduled to run every 1 hour, it may actually run every 1 hour and 1 minute. The filter on “Updated in the last hour” would then have a gap. This is covered with the option to share since last execution time.

Dynamic sharing offers the near real time replication of data. It does this by placing a business rule on the desired table and firing the replication on inserts, updates, or deletes. This business rule can be configured for when it's executed as an onBefore, onAfter, or async, as well as its order.

1. Dynamic Shares work by placing a business rule on the specified table. You can modify when you want this executed in the context of other business rules. For most customers, this is not necessary. However, if you have hundreds of business rules in place, there may be one which would interfere with our business rule's execution. This may be difficult to trace.

An additional note is that each update to the record will be one message. If your workflow includes updating the same record several times in a short timespan and you only care about the final value, it may not make sense to send out each update.

The scheduled sync up is an option under dynamic sharing. It can be described as a middle ground between scheduled bulk shares and dynamic shares, in that it will perform many “mini” bulk shares. It uses the defined dynamic sharing configuration to capture all updates to the table at designated intervals. This interval can be set to 5, 30, or 60 minutes.

NOTE: If you have this option enabled, you can disable the Trigger Conditions for insert and update. Otherwise, you will essentially replicate the message twice, once in real time and again on the interval. If you want to replicate deletes, leave that Trigger Condition checked.

As of V3.22.0, a user can now be set to run the sync up using the Run as field. This can be useful in domain-separated instances where you want to share only records a certain user can see.