Membership Accesses + Course accesses
This has been a recurring topic in the past,
but Iβd love to know how you guys are managing the coexistence of one-time purchases for individual courses/content alongside memberships.
Weβre currently using Access Management with FCRM + tag sync: super handy!
However, this creates a challenge on our side:
adding a one-time purchaser to a specific content area that is shared with the membership content (manually or via automations) automatically applies the Access Management tag⦠which then grants access to the entire membership.
How are you handling this?
Any advice or best practices?
Should we stop using Access Management?
Thank you!
PD.: Bring to us the chance of managing accesses with User Roles please π Shahjahan JewelΒ . Or any other way to allow multiple ways to have access to a space/course/content: a role, a tag, etc.
Would this work?
- Create a Fluent CRM tag called βCourse 1.β
- Map that tag to the space that Course 1 is in.
- Apply that tag in Fluent CRM to Course 1 purchasers and regular members.
- Every course that can be purchased a la carte would have its own tag.
Kaneisha G.Β not sure if this could be scalable for tons of courses that had one time limited offers.
Iβm thinking of how many tagsβ¦ should we be adding on automations for members π
But definitely, a worth researching workaround for having a couple of one time courses!
Thank you for the approach Kaneisha!
Jorge de los ReyesΒ maybe the Role Based Tag Mapping in fCRM could be helpful? You could create tags for each of your user roles, which would be updated automatically by fCRM, and assign access to courses using the role-based tags, as well as the course-specific tags Kaneisha G.Β described to grant access separately from role-based tags π
Jesse BenjaminΒ Thatβs actually, also, a great idea!
Thank you Jesse!
I think that one of our main problems here is that we can only choose one tag for granting access while using βAccess Managementβ feature.
This is, eg.: the user role tag; or the specific course one.
And that we are trying to avoid filling the members tags lists with all those specific course tags just because there are one time users π
Would love to have an approach of: βuser has tag A, B, C orβ¦β etc.; or something like βhas role A, or tag Bβ
Until then: Iβll toy around with this approach too!
π
