One way loop protection
SmartSYNC has built in loop protection to prevent changes in one system bouncing back and forward - it puts a 1 hour block to ensure data only flows one way after a change is made. So if you have a flow from Raiser's Edge to Mailchimp and another from Raiser's Edge to Mailchimp and want to test them you would:
- Make a change in Mailchimp and see if that change reaches Raiser's Edge
- Make further changes in Mailchimp and see if these changes also reach Raiser's Edge
- Note: If you make any changes in RE at this point they will not flow to Mailchimp i.e. it is one way for an hour since the last change in Mailchimp.
- Wait at least an hour (or to the next day)
- Then make changes in Raiser's Edge and see if those changes reach Mailchimp
- Make further changes in Raiser's Edge and see if those changes reach Mailchimp
- Note: If you make any changes in Mailchimp at this point they will not flow to Raiser's Edge i.e. it is one way for an hour since the last change in Raiser's Edge.
Transactional not bulk
SmartSYNC synchronises your chosen applications as and when changes are made so therefore is not suitable for bulk cleaning your database. It will pick up changes within 5 minutes for most applications (within 30 minutes for Raiser's Edge due to the way Blackbaud have made their APIs) and then flow the data to the other application. This keeps systems tightly in sync.
It is not designed to do a bulk sync such as take data from two systems and review all the data and make changes to both systems. This is bulk syncing and should be done as a one off task before using SmartSYNC. It is no longer necessary once SmartSYNC is running as changes will be made in near 'real-time' once the flows are in place but a one-off initial tidy is required.