Question for Course Creators
Hello Community!
I’d love to hear how you handle two types of students inside Fluent Community:
- Students with access to a membership (multiple courses).
- Students with access to only one standalone course.
Manuel Müller — since you also work with Thrive Apprentice, your input would be especially valuable here!
As I shared in a previous feedback post:
- Managing single-license users vs. membership users is tricky.
- With Access Management tags, if you manually add a non-membership user to a course/space → the system still applies the tag and grants them all membership features.
- On the other hand, if you try to use specific tags for each course, and you have dozens (or hundreds) of courses, it quickly becomes unmanageable.
👉 Bottom line: Right now, handling both models (memberships + standalone courses) in the same ecosystem feels unnecessarily complex.
I run my community in exactly this mix: separate single courses and a membership with access to multiple courses.
Surprisingly, I don’t find it complex at all. Here’s what works for me:
One main Membership tag → This controls the all-access membership spaces/courses.
Individual course tags → Each standalone course gets its own access tag.
When someone buys a membership, they get the membership tag only.
When someone buys a single course, they just get that specific course tag.
The system checks those tags automatically, so members never accidentally unlock more than they should.
I never add users manually to a space, I simply let the FluentCRM automations assign the correct tags based on the purchase.
That keeps it clean and scalable, even with many courses. I understand this is unmanageable with dozens of courses, but for me personally this works fine.
Gee Adriaansz Mmm.
Could you please further elaborate on the setup?
Here’s my example:
- "CLIENT – MEMBERSHIP" → used in Access Management for all Courses (COMMUNITY).
- From our last setup: "CLIENT – COURSE" → used for individual courses (only in FCRM).
The issue:
- With Access Management, we can only assign one tag. We added "CLIENT – MEMBERSHIP".
- But now we also need to handle one-license users...
- If we add them manually or via FCRM, they automatically end up with the "CLIENT – MEMBERSHIP" tag as well.
Am I missing something? 🙈
In my setup all access is handled through FluentCRM automations only.
I don’t use the integrated “add users to space” or “Enable Access Management with FluentCRM Tags” option inside FluentCommunity.
If the membership tag is still applied on your end, it’s worth checking both places:
• FluentCRM – look for any automation or global rule that might also add the membership tag. Be sure that product purchases or other triggers do not have fallback rules that assign the membership tag.
• FluentCommunity → Access Management – if you do use this feature, double-check that each space/course is mapped only to the correct tag(s) (membership or specific course tag), not both unless intended.
If, like me, you manage access only via FluentCRM, this setting can stay disabled.
It should work separately, so somewhere an extra tag is being added unintentionally.
I hope this helps!
Gee Adriaansz thank you Gee!
I’ll try just FCRM with no sync option 😄
Actually, from the very first moment, I’ve been pretty sure of what it’s adding the tag. 😅
It’s actually the default behavior of Access management.
You can set a tag + sync or not.
It’s pretty useful. Because adding or removing the tag you can automatically add or remove someone.
But I guess it’s not compatible with this system of having both members and separate students.
I’ll definitely try your approach 🙏🏼♥️
Gee Adriaansz if i'm correct, you have a membership automation (TAG B), where you add a user to all spaces/courses for the time until cancellation, where you remove all access to spaces/ courses, correct?
so what happens, when someone bought a single course(TAG A), registers for your membership afterwards (TAG B) an cancels some time later? your "cancel membership" automation in FCRM would also remove access to the single course, would it?
Manuel Müller Then they will have 2 tags. One for the membership, and one for the single course. (Because yes, this scenario does happen!)
I also offer several free courses.
A customer might try the free course, then decide to buy a membership. If they decide to cancel the membership, they will be removed through the automation, but because they have an extra 'free course' tag, they keep access to that. Same with single (paid) courses.
I might overdone it, but I made for all I offer, tags and lists. So a customer that applied for a free course, is added to that list and with that tag. Same with all paid courses and with the membership. Then I also have a "All customers" list. Might be too much but in this case I know for sure it all works well 😆
Gee Adriaansz you said "but because they have an extra 'free course' tag, they keep access to that."
so you're telling me that your "membership access ended" automation contains 1000 checks if someone has certain tags before removing them from a space/course?
sorry if i don't get it, but tags and lists don't give access, as they are just triggers....or what am i missing?
What i mean: when a subscription of my community member ends, i remove the user from all spaces/ courses with an automation. So this user would also be removed from a course, this user might have bought before. So to avoid this, within the "subscription ended" automation i'd have to check every possible tag there is, before removing someone from something, which would be a real pain in the ass....
so can you share, how you do it from a technical standpoint (share, how your automation looks)?
Maybe i'm making my life harder than it should be 😂
Manuel Müller I get the point Manuel.
True!
I didn’t thoughtt about that use case (student who got a license and a membership) and that, once on a membership, cancels.
With the FCRM path (not access management), I am also curious to know what would happen to their previous courses 😄
I’m starting to miss product management on apprentice haha 😂
Gee Adriaansz can you please elaborate your use of tags?
Manuel Müller Mmm, I think that Gee may be using tags just for control on FCRM, and firing automations that give access to spaces / courses.
And not using the Access Management option with the sync.
Jorge de los Reyes she said that, yes....but my problem is (as we stated before): your 1. automation would be "give access to a course" (one time payment)....then you give this person a tag: "course-A"....
your 2. automation maybe would be "Membership Access", which gives a person access to everything inside the community....
So when the Membership ends, your 3. Automation would be: revoke access to everything from automation 2 (which would also remove access to the course from automation 1)....
Where i can't wrap my head around: at wich point do you check if there's another tag, so that with automation 3, not all access is removed
I mean, if we would use apprentice product management, it would be easy....but with automations, you'd either have to check other tags (like "course A"), before removing access in automation 3, or start another automation (give access to the course again), after automation 3.
But both of these options seem horrible, if you have multiple courses (or my head just can't imagine a simple solution at this point)
Manuel Müller I totally get the issue - I’m running into the same thing #apprenticemigrationdrama
I haven’t actually “got my hands dirty” trying to build automations for the single-license users yet, and honestly, I completely forgot about this limitation (again 😅 - I am focused on the members at the moment tbh, and leaving this for the end of the migration).
Because yes… if in a membership automation we set “remove from course” (or equivalent), the user also loses access to the single-license course.
That’s a big problemo…
Please keep me updated. I will do so!
Jorge de los Reyes Manuel Müller
How I structure tags, lists and automation.
Tags VS Lists:
Tags = detailed labels on a contact, e.g. VIP member, Single Course, Free Course.
Lists = broader groups, e.g. All Customers, VIP members, Free members.
Tags are what trigger access in FluentCommunity (courses/spaces).
Lists are mainly for email/newsletter organisation and reporting.
And because I’m a little bit crazy: for the single courses I sell separately I created both a tag and a list. But that’s only a few.)
Scenario 1: Free course > Membership > Membership ends
Person starts with a Free Course > gets Free Course tag + added to Free Members list.
Buys a Membership > automation adds VIP member tag and VIP Members list, giving full access.
Cancels > automation removes the VIP member tag/list and re-adds Free Member/Free Course tags, so they keep free content only.
Scenario 2: Single paid course > Membership > Membership ends
Person buys a Single Course > gets that name of single course tag + added to name of single course list.
Later buys a Membership > keeps all Single Course tags and also gets the VIP member tag/list for full access
Cancels > automation only removes the VIP member tag/list.
> Because the Single Course tags and lists remain untouched, access to those purchased courses continues
That’s it.
Since FluentCommunity grants access only when the required tag exists, all other tags and lists—like Single Course or Free Course stay untouched unless I explicitly mention them in an automation.
Because those tags remain, access to any purchased single course continues without interruption.
Removing the VIP member tag and list therefore has no effect on the access that is connected to other tags, such as Single Course or Free Course.
Jorge de los Reyes Yes, that’s exactly why I disabled the sync option from the start.FluentCRM handles all tags and automations for me, so I keep full control and avoid accidental removal of single-course access.
This way I can combine memberships and individual courses without conflicts.
Gee Adriaansz Thank you for the feedback, Gee!
I think I get the idea ("on paper") - pretty straightforward (though one list for each course could quickly turn into a nightmare when you have tons of them 🙈).
However, (I am not sure if Manuel fully got what you meant either), but in my case I'd really need to stumble into it myself, because I keep seeing the same problem:
- Membership Tag → Add to Course 1,2,3…100
- Course Tag → Add to Course 1
The issue I see is: even if they still hold the course tag (which once triggered their access), if the membership cancelation automation removes access from all courses (not the tag, of course), that tag alone won’t guarantee continued access. The cancelation would wipe everything - including single-course licenses that should remain.
Manuel and I are used to Thrive Apprentice, which works in a more granular way by creating “fictitious products.”
Those products can either give access to one single course or to a bundle.
So if someone buys a single course, they only access that. If they buy a membership, they get access through a different product which may include one or more courses.
That’s why I’m still not fully convinced how to replicate this flow here without running into conflicts.
Our minds may be apprentice-biased 🤣
Sorry for the confusion.
As I said, I think I'd need to do the testing first so as to really see what it's your approach 💪🏻
I really appreciate your answer. Hopefully we won't have to bother you again Gee 🙈
Gee Adriaansz thank you very much, buuuut when you say "Since FluentCommunity grants access only when the required tag exists," that means you're using both "FCRMAutomations" and "FCommunity Access Management" and not only "FCRM", correct?
Gee Adriaansz This is SUPER helpful. Thanks for sharing!