Broadcasts are not real-time, nor are meant to be. This means there’s delay between data changing in Ardoq and the Broadcast message being sent.
So if you’re building a Broadcast that uses time-based filter rules - for example, new business processes added in the past week - it’s important to understand how those rules and the scheduler interact (especially if you’re building a workflow made up of multiple Broadcasts).
It helps to think of it like traditional (snail) mail:
- The filter rules determine what goes in the outbox to be sent.
- The schedule determines how often the post guy checks the outbox for messages and takes them away to be distributed.
So if the scheduler runs every two days, then messages that meet the filter rules will accumulate for two days before being sent out.
Only components that meet the filter rules at the time the scheduler runs will be included.
For example, if a component field value is updated so that it meets the filter rules, then changed again so it no longer meets them before the scheduler runs, then that component will not be included in the Broadcast.
A good general rule is that the periods in the filter rules and the scheduler should match.
For example, if you set up a filter rule to look for all new projects logged in the past week…
...then the scheduler should be set to run weekly.
If the scheduler runs more frequently than the filter rule, then you may Broadcast the same component multiple times.
If it runs less frequently then you may not Broadcast some components at all.
But there may also be times when you do want to filter rule and scheduler to have different periods.
For example, if you want a rolling three-month summary of all contracts coming up for review to be sent out every month, then the filter rule can look three months ahead...
...while the scheduler can run monthly.
The key is always to test that your Broadcast is giving the results you want before you publish it.