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

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!

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.

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?

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.

​@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.

​@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!

​@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.

​@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.

​@domenico.carboni 

Regarding the “daily schedule” for ERB in the MVP, I appreciate that an MVP will have limitations, but I’m concerned about the impact on onboarding across our global workforce.

I would expect a newly onboarded staff member to be enrolled in their required courses upon first login. If accounts are created through SSO, that could happen at any time and in any region. Would those users then need to wait until the next daily ERB run before they can begin their onboarding courses? Depending on the timing, that could create delays and confusion.

If that’s the expected behaviour, would it be better to wait for a post-MVP release before using ERB for this onboarding scenario?

The other common use case I see is conditional enrollments. Specifically, if a user completes Course A, put them in a group that triggers an enrollment rule to enroll them in Course B. I assume this would be a scenario for post MVP but would need to be captured somehow to not lose currently supported use cases. 

Hi ​@domenico.carboni 

The ambiguity of daily schedule leaves this less than desirable to migrate over when this is released. There will be multiple use cases in which automations/FTPs are purposefully scheduled in the early hours of the morning to ensure training is ready for new starters. Other use cases are reliant on the training being made available as soon as the criteria is met on the group conditions.

I would consider extra settings similar to how notifications are configured allowing the Admin to decide when the Enrollment Rule is fired out with one of the options being immediate. This allows customers to adjust when the learning is deployed and also allows to cover other use cases when training needs to be deployed X amount of time after meeting the conditions without requiring workarounds or additional fields being used up.

Regarding the CSV builds for the ERB, when will more information on this be released? Will this be user friendly, leveraging values that are available from the platform or will this drive off ID’s that are used on the platform?

Will other features with ERB such as the rule being turned on and off at a certain Date/Time. This can also alleviate Admin pressure where training is deployed out for a certain period and having to perform this manually.

With the move to ERB, will it come with an option to begin deployment of training to users who now meet the criteria or will it also come with an option to deploy retroactively? This too can also solve for a number of use cases which require manually intervention today.

Thanks in advance!

Hi ​@pat.ev ,

Thanks for such a thoughtful set of questions - exactly the kind of thinking we'd expect from a team with your level of investment in the current system, and it's genuinely useful for us to have all of this laid out together. Let me go through each point.

Biggest benefits beyond automatic unenrollments Even setting unenrollments aside, mature architectures like yours run into pain points ERB is specifically designed to solve:

• Long-term scalability: as enrollment volumes grow, the current architecture is exposed to performance degradation and rising operational complexity. ERB centralizes enrollment computation into a single, purpose-built engine designed for that scale.
• A consolidated admin experience: today enrollment logic is spread across automatic groups, enrollment rules, and in some cases Connect recipes. ERB brings that into one consistent tool and removes the need for Connect recipes for this use case entirely.
• Monitorability: it's hard today to see the current state of your enrollment process. ERB runs on a schedule and produces a dedicated Enrollment Log, on top of the Audit Trail, giving you the visibility you need for compliance and troubleshooting.
• Deterministic behavior: ERB generates enrollments/unenrollments deterministically from your rule definitions, so your enrollment structure stays aligned with what's configured rather than drifting from it, which makes anomalies far easier to catch and fix.
• Attribution: every enrollment is tagged with the rule ID and source that generated it, surfaced directly in the UI, so you always know why someone is enrolled.
• Per-rule unenrollment policies: you'll be able to configure post-unenrollment behavior, instead of handling it case by case.

Benchmarks/limits We don't have benchmarks we can publish yet, and honestly we don't think it would be responsible to put numbers out before the product has shipped and been tested at scale in real environments. What I can commit to is publishing concrete limits and reference values as we get closer to GA, so you have something solid to plan against.

Near real-time / event-driven options Fair question, and worth being upfront about the "why." Batch processing isn't a limitation we're settling for; it's a deliberate choice to avoid the kind of congestion and unpredictability a fully event-driven model creates at scale (part of what drives the scalability pain points today). That said, we know a daily-only cadence doesn't serve every use case, onboarding being the clearest example, so multiple runs per day is already something we're working toward post-MVP. Beyond that, we're exploring whether specific trigger types (e.g., account creation) could get a faster path without reintroducing congestion risk for everything else, nothing to commit to yet, but it's on our radar, shaped directly by feedback like this.

How long will (legacy) Enrollment Rules remain supported? No fixed end-of-support date yet. What we can say clearly: we won't ask you to drop Enrollment Rules until ERB is a genuinely complete replacement for what you rely on today, and until you've had a defined transition window to migrate and validate on your own schedule, as described above. We'll share exact dates as we get closer to GA.

Testing / simulating rules Yes. Whether you're testing rules generated through the automatic migration or new rules you build directly in ERB, you'll be able to preview exactly what it would enroll or unenroll before anything actually changes. Nothing runs for real until you deliberately promote ERB to active.

Governance at scale This centers on the dedicated Enrollment Log (complementing the Audit Trail) and the per-enrollment rule attribution mentioned above, both fully visible in the UI. On top of that, formal rule versioning is on our post-GA roadmap for managing change over time across large rule sets.

I hope it answers your questions! 

Hi ​@voss13,

Thanks for raising this; worth being direct about it rather than hedging.

The daily-run approach for ERB at MVP reflects a deliberate architectural trade-off: it's designed to prioritize scalability and reliability at volume, not synchronous or near-real-time execution. That's the same trade-off behind the benefits I mentioned above (a single engine that stays predictable and stable as rule count and learner base grow, instead of degrading under load the way the current architecture can).

We understand near-real-time behavior matters for some onboarding flows, including the SSO scenario you describe, where account creation timing is effectively unpredictable. That said, based on what we've seen across the broader customer base, enrollment generally doesn't need to be processed synchronously to work well operationally.

At this stage, we can't commit to a near-real-time or event-driven option on the roadmap. We are planning to move from a single daily run to multiple runs per day post-MVP, which will narrow the worst-case wait for scenarios like yours, but that's still batch processing, not synchronous execution. We'll keep collecting feedback like this and evaluate further as the product evolves.

Thank you!

Hi ​@Jamie at GuyKat ,

Good use case to flag, and I want to make sure the mental model is clear because I don't think this one needs to wait for a "post-MVP" answer.

With ERB you don't need the group as the trigger anymore. Today that scenario needs an automatic group plus an enrollment rule pointing at it; in ERB, "completed Course A" becomes a condition you put directly inside the rule that enrolls someone in Course B: one rule, no group in between.

Course completion as a condition is available from MVP, so the exact example you gave (Course A completion → enroll in Course B) is covered from day one. Using completion of a Learning Plan or Certification as that same kind of trigger condition, so you could chain off an LP or a Cert, not just a course, is one of the first extensions we're planning right after MVP. So the broader version of what you're describing is close behind, not lost.

I hope this answers your doubt!

Hi ​@DPatel,

Really solid, detailed feedback; genuinely useful to have this broken down point by point, thank you for taking the time.

On the daily schedule / configurable timing To be straightforward: at MVP it's a single daily run, not configurable to a different cadence. We hear you and others in this thread on why that's a real constraint for early-morning/new-starter scenarios, and extending this to multiple runs per day is already something we're planning right after MVP for exactly this reason. Your specific suggestion, notification-style settings where an admin chooses the firing behavior, including something closer to immediate, is compelling, and it connects to a broader question we're actively exploring: how to support more time-sensitive scenarios without reintroducing the kind of processing congestion that batch scheduling is designed to avoid in the first place. I don't want to commit to a specific mechanism yet, but I'm logging this as direct input into that work.

On CSV-based rule building We don't have that experience finalized yet, so I'd rather not give you a half-answer; we'll share concrete details on this (including whether it's driven by platform-friendly values or by underlying IDs) as we get closer to sandbox availability.

On scheduling a rule to be active only within a date/time window Good suggestion, and a real use case (time-boxed training deployment) we don't have committed for MVP. I'm flagging it as roadmap item for sure, rather than promising a date today.

On retroactive application Based on how ERB is designed to work, this shouldn't need a manual intervention: each scheduled run evaluates your full learner population against the rule's conditions, so when you activate a new rule, anyone who already meets the criteria gets picked up on the next run, not just people who meet the criteria from that point forward. 

I hope this answers your points!

Hey ​@domenico.carboni - The use case I’m flagging is regarding the timing. If I understand everything explained for initial plans, the logic wouldn’t trigger until the next daily run. I understand that the group no longer is needed and the logic is in MVP but if I complete Course A now but I don’t get Course B until the next daily run, that’s going to be an odd experience for the user. It would require a notification or some type of message to user saying thanks for completing Course A, you’ll now get access to Course B within the next 24 hours. That would be a pretty big shift from current workflow and likely would cause some friction with users.