1. Home
  2. AccessAlly
  3. Testing & Troubleshooting
  4. AccessAlly Troubleshooting Guide

AccessAlly Troubleshooting Guide

In this guide you’ll learn what to do to troubleshoot when your CRM and your AccessAlly site don’t seem to be communicating properly.

For example, if you’re seeing automations happening inside your CRM but the expected results aren’t being reflected on your AccessAlly site. Or vise versa, when an AccessAlly instruction doesn’t seem to make it your CRM to update a contact.

If at any point during this process you get stuck or confused, please reach out to us directly at your@ambitionally.com for support. This guide is considered fairly technical, and could also serve as a great resource to send to your website host or CRM company to help you troubleshoot.


Issue #1: Members Receive An Email With A Blank Password

Are your members signing up for a free course (or purchasing a paid one)… and then receiving an email with a blank password field? The likely cause is your HTTP post/webhook.

Press here to reveal

STEP 1. Check the HTTP post/webhook

Check to make sure an HTTP post/webhook sends to AccessAlly in your campaign after someone opts in/purchases, and before the email is sent.

It’s possible that you forgot to add this step in your automation sequence. If that’s the case, simply add the proper webhook/ping/HTTP post automation and run through a test user to make sure it works now.

Please note that there are different types of HTTP post / webhooks, and double check to make sure you’ve added the correct one.

STEP 2. Check URL and parameters of the HTTP post/webhook

If the HTTPost is in the right location, check that the URL and parameters are correct (no spaces, etc.)

You can find the base HTTP post URL inside AccessAlly Settings > Initial Setup > System integration.

Notice that there’s a bracketed [operation] inside the URL, which should be replaced with the specific webhook genpass, which instructs AccessAlly to create the user and generate a random password in the custom field.

Issue #2: You’re Creating/Updating Multiple Users At The Same Time And It’s Timing Out

Are you launching a course – or otherwise creating/updating multiple users at once? Make sure the HTTP post/webhook you’re using is the “Batch Sync”, instead of the “Update User” or “GenPass”, which are used when users are updated one at a time.

Press here to reveal

STEP 1. Use “batch sync” instead of the usual update URL

Batch Sync does not generate passwords, it simply updates tags, fields, etc. Use Batch Sync when you have more than 30 contacts to process at the same time.

For more information on how this process works, see this tutorial.

STEP 2. For bulk user creation creation, use the “User Migration Wizard” plugin to import a CVS from your CRM

When you’re migrating numerous users to AccessAlly, it’s best to use the User Migration plugin.

This plugin must be downloaded separately inside the AmbitionAlly membership site.

You can find an in-depth tutorial on how the plugin works here: https://access.ambitionally.com/accessally/accessally-add-ons/accessally-user-migration-wizard/

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.

Press here to reveal

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.

https://yoursite.com/aal_genpass=HIWcs5&contactId=[Contact Id]

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: your@ambitionally.com

Possibility 2: Make sure your CRM is sending the HTTPost command properly to AccessAlly

Press here to reveal

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.

Press here to reveal

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.

Ask your server to: whitelist the domain, IP address and the User Agent to allow it to come through

Updated on December 5, 2017

Was this article helpful?

Related Articles