How to test where things might be going wrong between your CRM and AccessAlly site
If the previous steps have not uncovered/solved the issue, you can dig a little deeper into the cause.
Possibility 1: Check to make sure that AccessAlly is able to accept the command.
1. Manually generate the URL and run it via your browser to see if you get any errors
Once again, you can find this HTTPost/webhook URL in AccessAlly > General Settings > Initial Setup.
In most cases, you can simply copy and paste the post URL (aal_genpass) in the browser, it will run the operation, and you will see their site open up.
If there are no errors here, move onto the next step.
2. Check that the password was generated in the CRM after running the URL in your browser manually
When you are generating the HTTPost, you can add an ID string to the URL to have it call a user.
In the following example, you would replace yoursite.com with your own site URL, and [Contact Id] with the corresponding user contact ID from your CRM system.
To find the contact ID, look in the browser window when you’re editing the contact in your CRM.
Here’s an example of the ID location when you are editing a contact in Drip:
3. After running the HTTPpost/webhook in your browser, check AccessAlly for any errors.
You can find a list of errors in AccessAlly Settings > Maintenance Logs
4. If no errors appear in the AccessAlly logs, contact support: email@example.com
Possibility 2: Make sure your CRM is sending the HTTPost command properly to AccessAlly
1. First, check that the CRM is sending the ping/HTTPost by looking at a specific contact to find out whether they went through the right sequence.
To do this, go to AccessAlly > General Settings > Maintenance > Detailed Log.
Here, you can see the list of pings that went through successfully. You should see a field for Contact ID, and the last field will show whether it is completed.
If it is not there, you have a problem. The probable issue for a blank Contact_id field is that the HTTPost URL was incorrect.
That means you need to make sure that the “Contact ID” is set up properly inside your ping/webhook settings in your CRM.
2. If it says that the webhook/ping/HTTPost was sent but it didn’t send, replace the URL with one from https://requestb.in
https://requestb.in is a helpful resource to have when you are testing your links. It is a great reference point to see more data on what is happening.
Here’s how it works. Simply go to RequestBin, and click the “Create a RequestBin” button.
On the next page, you’ll be given a bin URL, which you will copy and paste in your CRM’s automation sequence.
The best way to do this would be to clone your existing automation campaign, and replace just the part of your campaign that is supposed to ping and send a webhook/HTTPpost back to your site, with this new URL.
Then run a test user through the campaign, and this URL will get pinged by your CRM.
At this point, after you know that your CRM ran the ping/webhook, you’ll refresh the original RequestBin page. You should see something like this, telling you what server pinged the URL.
If it doesn’t show any activity, then it means that the CRM did not successfully run the webhook or ping. Knowing this, you should contact your CRM’s support to see if their servers are down or experiencing other issues.
Possibility 3: The Server Is Timing Out and/or The Server Is Failing to Receive Anything
This issue usually happens with a shared hosting account or one that blocks HTTPosts/Pings.
You can tell whether it is a server timeout if your CRM pings are sending properly (as shown above with the RequestBin example), but not arriving inside your AccessAlly site.
If this is the case, contact your hosting provider for help in resolving this issue.
1. Look at your web server host’s Access Logs
Inside the server Access Logs, search for Genpass (the AccessAlly ping URL) and look at the status. If it’s not in the log, then the server is blocking it. If this is the case, contact your hosting provider for help in resolving this issue.
This is an example of a WPEngine access log screen, but each web host will have a slightly different back-end to display these logs.
NOTE: Some hosting providers do not let their clients see this information, so you may need to contact your host at this point.
If the Genpass IS in the log, move to the next step:
2. Examine the error code for the cause of the issue
You will likely need to contact your host at this point and ask them to look at NGIX logs. If those an unavailable, they can check Apache logs. Look for the following:
- A 200 status means it was successful
- 403 permission not granted
- 500 server timed out
3. Once you know the error, you can try to reproduce it and fix it… or contact AccessAlly and/or your server’s support with this information so they can offer further help.
The log errors will be listed in the server logs (NGIX/APACHE). One of them will indicate if the incoming ping was blocked. Once you’ve identified the issue, you can ask your server to whitelist the domain, IP address, and the User Agent to allow the communication for future pings.