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.
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.