There is a big difference between a site that merely protects content and a site that actually feels good to use. Enrollments are what close that gap.
With the Enrollments module, you can let someone join a course, workshop, or resource hub as a real participant, not just as a person who happens to hold a matching level. Better yet, you do not have to enroll them into every lesson one by one. One anchor enrollment can unlock the whole branch when your structure is configured properly.
This guide walks through the practical side of enrollments in BricksMembers: what they are, when to use them, how they work with structures, how users can enroll themselves, and how Drip fits into the picture.
What Enrollments Actually Do
Think of enrollments as access records tied to a specific post anchor.
- Levels are broad access categories.
- Enrollments say, “this user is currently in this course, event, or resource.”
- Drip decides what unlocks over time after that access exists.
That means you can build experiences like:
- a free catalog where users click Enroll to join a course
- a coaching program where staff manually add participants
- a level-driven setup where assigning a BRM level automatically enrolls the user into one anchor post
- a course where enrollment opens the door and Drip releases lessons over time
The Good News: You Do Not Enroll People Into Every Lesson
This is the part most course creators care about first, and for good reason.
If you have a structure like Course → Module → Lesson, the normal setup is:
- Set the course to Require enrollment.
- Set child content to Inherit from parent.
- Enroll the user into the course once.
That one enrollment can unlock the whole branch. BricksMembers resolves the effective enrollment anchor for the child content, so an inherited lesson can still check the course enrollment instead of demanding its own lesson-specific enrollment.
This is what makes enrollments useful instead of annoying.
The Three Enrollment Rule Modes
Every post can use one of three modes in the BRM meta box or structure UI:
- Require enrollment: this post defines the enrollment gate for this branch.
- Inherit from parent: this post reuses the nearest ancestor’s effective enrollment anchor.
- Disabled: this post is not enrollment-gated unless a descendant creates its own rule.
The important detail is that inherit does not simply copy the parent’s literal target mode. It reuses the ancestor’s already-resolved effective anchor. That is why inherited course branches behave sensibly even when the anchor uses Current post.
Choosing the Right Enrollment Target Mode
When a post uses Require enrollment, you can decide which post should own the check:
- Current post — the post itself is the anchor
- Parent level — useful when a lesson should follow its module
- Top level — useful when all child content should follow the course
- Tracking level — useful when your progress/drip anchor is a specific structure level
- Specific post — useful when access should point to one chosen anchor outside the normal branch
If you want the cleanest course setup, start simple: use Current post on the course and Inherit from parent on descendants.
How Users Can Enroll
BricksMembers now supports a few different enrollment paths, and each one has a different job.
1. Manual admin enrollment
Go to BricksMembers → Enrollments → Manual Enrollment and choose:
- the user
- the enrollment anchor post
- an optional start date
- an optional end date
This is perfect for staff-managed access, support workflows, or private cohorts.
2. Automatic enrollment from a BRM level
In Level Enrollment Rules, you can say: when a user gains this level, enroll them into this anchor post.
This is useful when your billing, onboarding, or manual staff process already assigns levels and you want course access to follow automatically.
3. Self-service enrollment from a normal Bricks Button
This is the simplest frontend path and, for most sites, the most important one.
Add a normal Bricks Button and use one of these dynamic tags in the link field:
{brm_enrollment:enroll_url}{brm_enrollment:unenroll_url}
That is enough to create a clean “Enroll now” or “Leave course” button. If the page is a lesson that inherits the course anchor, the button will still target the course enrollment correctly.
For guests, the enroll button sends them to login first. For logged-in users, the action completes and returns them to the current page.
4. Advanced Bricks Form actions
Bricks form actions still exist, but they are now the advanced path, not the main one.
Use them when you need things like:
- scheduled starts
- expiry dates
- custom source references
- admin-controlled targets or more complex workflows
How Enrollments Work with Drip
This is the clean way to think about it:
Enrollment opens the door. Drip controls what unlocks behind the door.
If a user enrolls into a course today and your lessons drip out over the next few weeks, Drip can now use the enrollment activation date as the starting point.
That is especially important for inherited structures. If a lesson inherits the course’s enrollment anchor, its drip timing can count from the course enrollment date, not from some arbitrary child-post event.
So yes, the common scenario now works the way most course creators expect:
- user enrolls into the course
- the course branch becomes accessible
- Drip releases lessons over time from that enrollment start point
Where to Manage Enrollments in the Admin
The Enrollments page has three tabs:
- Manual Enrollment — create or update a user’s enrollment directly
- Current Enrollments — review source rows, effective state, schedule, and actions like pause, resume, revoke, or cancel
- Level Enrollment Rules — automatically grant anchor-post enrollments when users gain matching BRM levels
There is also an Enrollment Redirect section in BricksMembers → Access Control. This lets you redirect users when enrollment is the only gate they are failing.
The Setup I Recommend First
If you are building courses, do this first before trying fancy variations:
- Enable the Enrollments module.
- Set the course anchor to Require enrollment + Current post.
- Set modules and lessons to Inherit from parent.
- Add an Enroll now button with
{brm_enrollment:enroll_url}. - Add Drip rules if you want timed release after enrollment.
That gets you a setup that feels natural to users and stays maintainable for you.
When to Use Enrollments Instead of Levels
Use enrollments when access is tied to a specific item or branch. Use levels when access is tied to a broad membership state.
- Use levels for Bronze / Silver / Premium style access.
- Use enrollments for “this user joined this course” or “this user bought this workshop.”
- Use both together when a level grants broad membership and the enrollment tracks participation in one specific item.
Final Thought
Good enrollment UX should feel obvious to the learner. They click a button, they are in, and the course behaves the way they expect.
That is what this feature is for: one clean enrollment anchor, inherited access through your structure, and Drip on top when you want pacing.