In AccessAlly 3.2 onward, AccessAlly has changed to a client activity-based update mechanism when a webhook is sent over.
This type of client-based updating helps to spread out the CRM API requests and prevents stress on the server.
ARTICLE CONTENT:
How Activity Based Updates Work
Instead of immediately updating the data from the CRM into AccessAlly with a webhook, AccessAlly will make the update when the client needs it.
There are several ways that a client’s tag information gets updated:
- When they click on an email link from your CRM to an AccessAlly page, or
- When they visit any page on the AccessAlly site and there was a webhook sent for that client, or
- When they visit any page on the AccessAlly site and it’s been 24 hours since the last update
- When a site Administrator visits a User’s Profile in WordPress
Benefits of Activity-Based Updates
One key reason for moving to client-driven updates is to help de-centralize server calls to reduce time outs and the potential for reaching API rate limits during launches or mass-updates.
It also helps buffer AccessAlly’s functionality against CRM webhook API changes, which have caused site-wide issues in recent months.
Do I still need to run a webhook when I change someone’s permission tags in a CRM Campaign?
Yes. The new update method requires the same CRM campaign setup, complete with webhooks.
Advanced: Revert to Legacy Operation
You may revert back to the full-update legacy operation in AccessAlly by going to:
General Settings -> Initial Setup -> Additional Features -> (Legacy) Perform full update on aal_updateuser and aal_genpass webhooks.
