2. AccessAlly Teams and Credits: The Challenge

Credits / Points

In order to implement the "unlocking" of modules, we waned to use the AccessAlly credit, or point system. That meant setting up a custom field in the CRM (ConvertKit in this case, but this can be done with any of the CRMs with which AccessAlly is compatible) to store the number of credits each user has. In addition, there's an automation that adds a fixed number of credits each month by running a custom operation that increments the credit field.

To unlock modules, we provide a button on the front end for each module. Behind the scenes, clicking the button runs a custom operation that decrements the credit count and adds the tag to unlock that particular module.

Teams

Lindsay wanted to allow any number of employees at a company to access her content for one price. This is the perfect scenario to use AccessAlly teams. A company representative ("Team Leader") can purchase a package of licenses (which translates into a number of AccessAlly users, or "Team Members"), and then either add those users themselves, or have the users self-register through a special, unique link. The team members can then log in and access the content under their own accounts.

The Sticking Point

When we began this project, we quickly discovered that there was no way to use AccessAlly Teams and Credits together in the way that we wanted. What we wanted was that each month, the Team Leader would choose a new module to unlock, and that content would then become available for all Team Members. We could make it work so that newly unlocked content was made available to existing team members. What we couldn't do was grant access to already-unlocked content when a new team member was added. Since a big advantage of using teams is that the company representative can add and remove team members at will, this was a big sticking point.

3. The Solution

Our Workaround

We started out by deciding that we'd always create teams of two: one team leader and one team member account. The team leader account would be able to unlock content, and it would be made available to the team member account. The login id and password for the team member account would be shared among all employees who needed access. It wasn't ideal, but it was the best we could do.

Almost there

AccessAlly already has a solution that allows you to show a portion of a page using the team leader's permissions, by wrapping it in the following shortcode:

[accessally_team_show_as_admin team_id='1']

This wasn't enough for us, though, as we needed to show the entire page according to the Team Leader's permissions.

The True Solution

As we were struggling with how to solve this problem, I reached out the AccessAlly support team and explained the situation to them. In true rock-star fashion, the next thing I knew, they had implemented a solution for us! Now, before you get the idea that you can always have a new feature added for you on demand, let me just say that isn't always the case. The AccessAlly team has a list of hundreds of feature requests that need to be prioritised. It happened that in this case, they recognised that we had a use case that seemed like it should be a natural fit for AccessAlly, but wasn't, and that a solution could benefit many users, and so they implemented it for us.

This solution became available in the AccessAlly 3.6 release. We were able to test it out in a beta version before the release, and I can confirm that it worked like a charm, and was extremely easy to use. Here it is in a nutshell:

On each page in AccessAlly, there's a new checkbox at the bottom of the page that allows you to set the permissions so that team members can view the page with the same permissions as their team leader. It's genius in its simplicity!

It allows you to show content at a page level based on the Team Leader's permission. That means that if you have multiple teams (in this case, multiple companies), the team members will see the page according to their own team leader's permission. If the team leader unlocks a particular module, then they have the corresponding access tag for that module, and so all their team members will view the page as if they have that access tag too.

As a bonus, this feature is available wherever you can set AccessAlly permissions, so it's also available for Posts and Protected Content. That means that even our downloadable files make use of this feature. A member can only access the file if the Team Leader has permission.

4. Choosing Modules

We had one other technical challenge to address in this implementation. Over time, Lindsay expects to add many modules to her program. We wanted a user-friendly way to be able to display them all.

FacetWP Plugin

To make it easy to find and choose modules, Lindsay categorised them by level (beginner, intermediate, or advanced), and according to which of 13 psychosocial factors they address. A module can belong to one level, but may address multiple psychosocial factors.

So that we could make use of WordPress' built-in categories and tags, we created each of the modules as a WordPress Post. We used categories to assign a level, and tags to assign psychosocial factors. We then purchased the FacetWP plugin (and the Elementor add-on, since we were using the Elementor theme). That allowed us to augment the Elementor Posts widget with filters for tags and categories:

Team Leader versus Team Member View

In the Posts widget, we elected to display the post excerpt so that we could show the a grid of course icons and unlock buttons in the Posts widget. We crafted the post excerpt as follows:

[accessally_icon post_id='739' target='same' hide_disable='always']
[accessally_team_is_admin team_id='1']
[accessally_missing_any_tag tag_id='2321348' comment='MHIM_LANG_Has_Access']
[accessally_custom_operation operation_id="7"]
[/accessally_missing_any_tag]
[/accessally_team_is_admin]

The first line shows the course icon for the module. Since this page has the new checkbox ticked for "Team members will view this page with team leader's permission," Team Members will see the locked or unlocked version of the icons according to what the Team Leader has unlocked.

Underneath the course icon, we want to display the custom operation button to unlock the module. We only want Team Leaders to see this button. Because this page is being viewed under the Team Leader's permissions, we need to add an extra conditional around the button display to only show if it's the team admin ([accessally_team_is_admin]).

Finally, we only want to show the button if the module has not already been unlocked. For that, we use another conditional to check whether the contact has the access tag for the module ([accessally_missing_any_tag]).

The innermost shortcode displays the custom operation button to unlock the module.

In this way, Team Leaders who view this page will see the locked or unlocked module icons with unlock buttons underneath the ones they have not yet unlocked. Team members will see the same locked or unlocked module icons, but no buttons.

Locked modules

We linked each locked module to an overview page that describes the module. That page has a conditional display ([accessally_team_is_admin]) to show Team Leaders how many credits they have remaining. It also displays the unlock custom operation button using the same conditional logic as we used in the post excerpt.

5. The Results

Using the new feature of AccessAlly, we were able to create an elegant and user friendly solution that allowed us to use AccessAlly teams in conjunction with a credit / point system to unlock content for Team Leaders and their Team Members. The FacetWP plugin provided a means of filtering the content according to categories and tags, which made it easy to find content when faced with many choices.

Thanks to the incredibly helpful and responsive AccessAlly team, we're ready to launch this project with the new feature in place just as AccessAlly 3.6 goes live.

Learn more about AccessAlly teams and credits / points.

Want help building your own AccessAlly membership site? Contact me today!