Skip to main content

Enrollment Rules Builder (formerly ERE) update: what we've built, what's coming next, and how the migration will work

  • September 9, 2026
  • 7 replies
  • 198 views

domenico.carboni
Docebian
Forum|alt.badge.img

You have known this initiative as the Enrollment Rules Engine (ERE).
Going forward, we’ll call it Enrollment Rules Builder (ERB).
The new name reflects what it does: helping you define and manage rules for automatic enrollments and unenrollments.

 

We know it's been quiet. We've been focused on building ERB for real customer use as quickly and responsibly as possible. Here's where things stand, and what to expect over the next few quarters.

 

Timeline

  • MVP in your sandbox environment by the end of 2026. 
    You'll be able to enable ERB in your existing sandbox and start building and testing rules there.
  • General availability in Q1 2027.
    ERB will become available in production environments.
  • Incremental releases throughout 2027.
    We'll continue adding capabilities after GA to support more use cases and give you greater flexibility.

What ships with the MVP

  • Automatic enrollments and unenrollments
    Automatic enrollments and unenrollments will be available from day one, across courses, learning plans, and certifications.
  • Archive on unenrollment comes later
    Archiving an enrollment when a learner is unenrolled is not part of the MVP. It's planned for a later 2027 release. Until then, unenrollment through ERB works the same way it does today: the enrollment record will not be archived.
  • Rules run in batch
    ERB evaluates and applies rules on a schedule; it does not run immediately whenever an individual learner attribute changes. Batch processing provides predictable, measurable throughput and helps keep the system stable as your rule count and learner base grow.
  • Conditions live inside the rule
    You will define who qualifies for enrollment or unenrollment directly in the rule's conditions. You would no longer need an automatic group to drive that logic.

 

What changes for automatic groups

Automatic groups will remain available for menus and pages, manual enrollments, and any other existing use case. With ERB, enrollment and unenrollment logic will be defined directly in the rule rather than through an automatic group.

 

How you'll access ERB

ERB will appear as a new app in your admin panel. It's native to the platform, not a separate tool or an external integration.

 

In the sandbox, you will be able to open ERB and explore the new experience without activating it. Your existing Enrollment Rules will continue to run unchanged. Enabling the app and migrating away from Enrollment Rules are separate steps, so you remain in control of when the transition begins.  

 

We will share more details about the app experience as we get closer to sandbox availability.
 

How ERB will replace Enrollment Rules

Our direction is clear: ERB will eventually replace the current Enrollment Rules feature. That transition will not happen on day one, and it will happen ith a defined migration and validation process. 

 

Here's how the transition will work:

  1. ERB and Enrollment Rules cannot run at the same time.
    The two engines cannot coexist in the same environment. This is not a preference; it is a hard constraint of how ERB is built.
  2. We will migrate your existing rules for you.
    When you are ready to try ERB, we will offer a semi-automatic migration. It will read your existing Enrollment Rules and generate equivalent ERB rules automatically, so you are not starting from a blank page.
  3. You will be able to preview the results before anything changes.
    After migration, ERB will show you what it would do without changing any enrollments or unenrollments. This is validation mode: you can compare the results with your current rules before activating it.
  4. You promote ERB to active when you are confident.
    Once you are satisfied with what validation mode shows you, you switch it to active. At that point, your existing Enrollment Rules are removed, and ERB takes over enrollment and unenrollment for that environment.
  5. You will have a defined window to make the switch.
    We are not flipping this on without notice. You will have a defined transition period to migrate, validate, and promote ERB on your own schedule before we set a final cutoff.

 

We will share exact dates for the migration tooling and the transition window as we get closer to GA. If you have questions about how this affects your setup, drop them below and we will get back to you here in the group.

Thank you,

Domenico

7 replies

kbrink1
Influencer I
Forum|alt.badge.img+4
  • Influencer I
  • September 9, 2026

Good morning!

This is interesting, and I am looking forward to testing this redesign. Currently, we're working toward a build that uses automatic groups and enrollment rules to assign required training to employees. We use an automated toggle to batch-activate the rules, based on a specific rule coding convention, to work around the system's limitations. 

Am I interpreting your message correctly that the legacy enrollment rules system limitations will change because the new ERB will natively run in batches?

Thank you!

 


Ahebert
Influencer I
Forum|alt.badge.img+1
  • Influencer I
  • September 9, 2026

Thank you for this. We are excited to test this, especially the automatic unenrollments. 

We currently have a very large amounts of groups and enrollment rules in the system (in the thousands) so the migration aspect is a bit of a watch for us. But looking forward to having more details about how this is going to work.


Jamie at GuyKat
Novice II
Forum|alt.badge.img+2

Hi Domenico - glad to hear this is progressing. Do you have any insight on the batch logic - how frequent/quick can they be scheduled to run? I’m asking for onboarding scenarios where someone might need training assigned at creation of the user, when would the batch pick it up in that type of scenario? Is it hourly or some other set cadence or can it be defined?


domenico.carboni
Docebian
Forum|alt.badge.img

Good morning!

This is interesting, and I am looking forward to testing this redesign. Currently, we're working toward a build that uses automatic groups and enrollment rules to assign required training to employees. We use an automated toggle to batch-activate the rules, based on a specific rule coding convention, to work around the system's limitations. 

Am I interpreting your message correctly that the legacy enrollment rules system limitations will change because the new ERB will natively run in batches?

Thank you!

 

Hi ​@kbrink1 ,

Thanks for the kind words! To make sure I answer this properly: when you say "the legacy enrollment rules system limitations," could you tell me a bit more about which specific limits you're hitting today (e.g., number of conditions per group, number of automatic groups/rules, processing time, something else)? That'll help me give you an accurate answer on whether ERB removes that particular constraint rather than a general one.

 

Thank you for this. We are excited to test this, especially the automatic unenrollments. 

We currently have a very large amounts of groups and enrollment rules in the system (in the thousands) so the migration aspect is a bit of a watch for us. But looking forward to having more details about how this is going to work.

@Ahebert Thank you for the enthusiasm! We're excited about automatic unenrollments too, it's one of the capabilities we've heard the most demand for.

And yes, we completely understand that with a setup of that scale, migration is a critical piece for you, not an afterthought. It's front of mind for us as well, and we'll make sure to share concrete details on the migration process and tooling as we get closer to sandbox availability.

Thanks for flagging it, we'll keep this group posted.

 

Hi Domenico - glad to hear this is progressing. Do you have any insight on the batch logic - how frequent/quick can they be scheduled to run? I’m asking for onboarding scenarios where someone might need training assigned at creation of the user, when would the batch pick it up in that type of scenario? Is it hourly or some other set cadence or can it be defined?

@Jamie at GuyKat Great question, and this is exactly the kind of scenario we want to make sure works well.

To be clear on where things stand: at MVP, ERB will run on a daily schedule, it won't be configurable to a different cadence yet. We do plan to extend this to support multiple runs per day, which would help exactly with cases like the onboarding scenario you describe, but that's a capability we're still fine-tuning rather than something available at launch.

We'll share more specifics on scheduling options (frequency, whether it's configurable, etc.) as we get closer to GA; didn't want to leave this one vague given how directly it affects onboarding flows like yours.

Thanks for raising it!


kbrink1
Influencer I
Forum|alt.badge.img+4
  • Influencer I
  • September 10, 2026

@domenico.carboni we’ve been told by Docebo that there is a limit to automatic enrollment rules due to system limitations. They gave us a soft limit of 150, so we built a toggle that activates and deactivates enrollment rules so they process in batches and work around the limitation. Similar to someone else in this thread, we anticipate having large amounts of enrollment rules, over a thousand, by the time it’s all said and done, in order to capture role and programmatic needs across 4100 employees. 


domenico.carboni
Docebian
Forum|alt.badge.img

@domenico.carboni we’ve been told by Docebo that there is a limit to automatic enrollment rules due to system limitations. They gave us a soft limit of 150, so we built a toggle that activates and deactivates enrollment rules so they process in batches and work around the limitation. Similar to someone else in this thread, we anticipate having large amounts of enrollment rules, over a thousand, by the time it’s all said and done, in order to capture role and programmatic needs across 4100 employees. 

@kbrink1, thanks for clarifying! If I recall correctly, the constraint you've been working around is the soft limit of 100 active enrollment rules - which is why a toggle-based approach to activate/deactivate rules on a rotation became necessary.

With ERB, that specific constraint changes shape. Having 1000-2000 rules configured in ERB won't put you "outside the limits" the way it might today. The dimension that matters more is the volume of enrollments/unenrollments the engine needs to process within a given batch window, not the raw count of rules sitting in the system. That said, I don't want to overstate it; I'll just say that ERB is built to process significantly more actions than the current Enrollment Rules do, but we're still tuning performance as we get closer to GA.

In practical terms: you shouldn't need the activate/deactivate toggle workaround you're using today just to stay under a rule-count ceiling.


  • Helper I
  • September 10, 2026

@domenico.carboni Thanks for the update and transparency. We're a large enterprise customer with a significant investment in automatic groups, enrollment rules, onboarding workflows, and qualification programs, so we're evaluating whether the value of ERB outweighs the migration effort.

A few questions:

  • What are the biggest benefits ERB delivers for customers with mature enrollment architectures beyond automatic unenrollments?
  • Are there published scalability benchmarks or limits (learners, rules, enrollment actions per run, external data points used in rule logic)?
  • With daily batch processing at MVP, are near real-time or event-driven options on the roadmap for onboarding and other time-sensitive scenarios? 
  • How long will ERE remain supported?
  • Will administrators be able to test rules, simulate outcomes, and compare ERB results before activating?
  • What governance capabilities will exist for auditing, versioning, troubleshooting, and managing hundreds or thousands of rules at scale?

As we evaluate this internally, understanding why we should migrate is just as important as understanding how we migrate.