When Flowable CMMN repetition rules fit a case
Repetition rules fit a case when the same piece of work recurs per item, per attempt or per cycle, and the number of repeats is not known until the case runs. In Flowable CMMN, a repetition rule on a task or stage tells the engine to create another instance of that plan item each time it is triggered again, so the modeler does not have to draw every copy. The Flowable CMMN documentation describes how repetition interacts with entry criteria and plan item states, so confirm the exact behavior for your engine version before you build a design on it.
The core decision is whether the count is known at design time. A fixed set of tasks suits a case with a small, stable number of steps, because the model stays readable and each step has a clear owner. Repetition suits work driven by data. In an illustrative insurance claim with an unknown number of supporting documents, each document might need its own verification task, its own assignee and its own audit trail. Ask three questions: does the number of items vary from case to case, does each iteration need separate state or evidence, and will the business want progress reported per item rather than as one total.
Repetition without limits is the main risk. A repeated plan item can create instances faster than people complete them, and an unbounded collection or a retry loop can grow a case without anyone noticing. Before you model a repeating item, decide where its upper bound comes from: a maximum instance count, the size of a collection variable, or an exit condition that closes the repetition. Write that bound down as a requirement, and test it with a case that has the largest input you expect and one that has no input at all.
Repetition configuration options and when each fits
This table compares the four ways to make Flowable CMMN work repeat: a simple repetition rule, a max instance count, repetition over a collection variable, and repetition combined with entry sentries. Read each row for the use case, the main risk and the test that proves the model behaves before production. The main takeaway is that every option needs a bounded trigger, because an unbounded repeat creates plan items without a natural stop.
| Option | Use case | Risk it introduces | What to test |
|---|---|---|---|
| Simple repetition rule on a task | A single human or service task that must be done again each time its entry criteria are met, such as re-requesting a missing document | Repeated items can pile up if the entry criteria stay true after the work is done, and the same task may reopen without a clear stop | Confirm the task creates a new instance only after the prior one completes, and that the case completes when the required work is finished |
| Max instance count | A bounded retry or re-review pattern where the business allows a fixed number of attempts, such as two follow-up calls | The limit is only as good as the count variable or rule behind it, and reaching the limit may leave the case stuck if no exit path exists | Drive the case to the maximum and check the final state, the exit path and the reporting of the last attempt |
| Repetition over a collection variable | One task per item in a list, such as one review per line item or per applicant document, where the number of items is known at runtime | A large or unexpectedly empty collection can create too many items or none, and item counts are hard to predict without limits on input | Test with an empty collection, one item, and a large test collection, and confirm the collection size is validated before the case starts |
| Repetition combined with entry sentries | Work that should repeat only when a specific fact changes, such as re-checking a limit after each new payment event | Sentries evaluated on every change can trigger repeated work faster than intended, and overlapping sentries can create duplicate instances | Vary the triggering events in sequence and in parallel, then check for duplicate plan items and the order in which sentries fire |
| Stage-level repetition | A group of related tasks that must run as a unit again, such as a full verification stage repeated after a rejection | Repeating a stage repeats its children, so local variables, completion rules and open work from the previous pass can carry over | Check local variable reset, completion neutral children, and whether open tasks from the earlier pass block the new pass |
| Repetition with no exit path | Rarely appropriate, though it may appear when a team models a loop without a termination condition | Plan items are created without limit, which can exhaust database rows, job queues and case history | Review the model for a bounded trigger or exit criterion before deployment, and run a load test with a deliberately failing trigger |
| Testing with plan item counts | Any repeating model, to confirm the engine creates the expected number of plan items | Counts that look correct in a happy path can diverge under error handling, timers or retries | Assert counts of plan items per state after each scripted event and after a restart of the engine |
| Rollout to running cases | Changing repetition rules on a case definition already in use | Running instances may follow the old rule, and a new rule can alter how existing work repeats | Confirm with your Flowable version how new definitions apply to running instances before changing repetition rules in production |
Avoiding unbounded plan item creation
Repetition rules are the most common way a Flowable case creates far more plan items than the business intended. Each failure below has a model guard to add before the case ships and a check to run against the definition and a test instance.
Missing or loose max instance limits
A repeating task or stage without a maximum instance count can create plan items for as long as its entry criteria keep matching. Set an explicit maximum on every repetition rule, using a value the business can defend, and treat any repeatable element that lacks one as a defect. Before release, review each repetition rule in the CMMN model and confirm that its limit matches the number of real occurrences the process description allows.
Collection variables that grow during a case
Repetition over a collection variable creates one plan item per element when the rule is evaluated. If a running case appends items to that collection, new elements can trigger new plan items that were never part of the original plan. Guard this by copying the collection at case start, or by restricting writes to a separate variable that no repetition rule reads. Test by adding elements mid-case and counting plan items afterward.
Repetition that re-triggers on its own completion
When a repeatable task completes and its entry criterion still holds, the engine can create the next instance immediately, which makes the loop run without a business reason to stop. Add an exit condition based on a case variable or milestone that the repetition depends on, and make sure completing one instance changes the state the entry criterion reads. Verify this by completing instances one at a time in a test and confirming the loop stops when the expected condition is met.
Sentries that fire repeatedly
Sentries on a repeating element are evaluated again each time the surrounding state changes, so an on-part that matches a common event can keep re-creating plan items. Review each sentry that gates a repeatable element, check which events can satisfy its if-part, and ask whether a single occurrence should be enforced with a variable or milestone. Run a case through its normal events and count how many times each sentry fires.
Limits that differ across repeating elements
A case often contains several repeating elements that each have a limit, but no single limit covers the total number of plan items the case can create. Add up the maximum instances across all repeatable elements on the same path and compare the sum with the load the case can tolerate in the database and history tables. Confirm the total with the process owner before release, since each added limit compounds across the case.
Runaway cases in production
Model guards reduce risk but do not replace monitoring of live cases. Track the plan item count per case instance and alert when a case passes a threshold the team sets from its test results. Review the monitoring setup with operations before go-live so a runaway case is found by an alert rather than by a database that has grown unexpectedly.
Setting up a repeating task or stage in Flowable
This sequence takes a repeating case element from behavior design through tested deployment, so the team knows how many instances can exist, where the count comes from, and how history will show each repetition before the definition reaches production.
Define the case behavior and instance limits
Before opening the modeler, the case owner and a developer agree on what repeats, what triggers each repetition, and the most instances that can exist at once. Write down the business reason for each limit, such as a maximum number of line items or a maximum number of retry attempts, and decide what happens when the limit is reached. Done means a short written spec that names the repeating element, its trigger, its ceiling and the behavior at the ceiling, reviewed by the business owner. Without this agreement, the model tends to create plan items for every value a variable can hold.
Model the repeating plan item and repetition rule
In the CMMN model, add the task or stage that should repeat and attach a repetition rule to it, using the modeler's repetition rule settings for the element. Keep the entry sentry or manual activation rule that controls the first instance separate from the repetition rule, so the first start and the repeats are easy to reason about. Check the model in the modeler's validation output and confirm the element's name is clear in the case diagram. Done means the definition deploys to a local engine without validation errors and the repeating element appears once in the diagram definition.
Bind the collection variable and maximum count
If repetition is driven by a collection, bind the repeating element to a case variable that holds the collection and confirm the variable is set before the element can start. Set the maximum instance count in the model or in the start logic, as your design requires, and make sure the count is enforced in code rather than assumed from the collection size. Test with an empty collection, a single item and a collection larger than the maximum to see the behavior at each boundary. Done means each boundary case produces the instance count the spec defined, and no case creates a plan item for a value outside the agreed range.
Write unit tests against the case engine
A developer writes unit tests that start a case instance in the test engine, set the input variables and move the case forward by completing the repeated work items. Each test asserts the number of active plan items at each stage, the variable values that drive the repetition, and that the case completes or stops at the ceiling. Include a test for a repetition that is never completed so the team sees how the case behaves when work stalls. Done means the suite passes locally and in the build pipeline, and every boundary from the spec has a test that would fail if the limit were removed.
Verify history and plan item counts in a test environment
Deploy the case definition to a test environment that uses the same database type as production, then run representative cases through the engine. Query the runtime and history data to confirm plan items are created and closed as expected, and that the history shows one record per repetition with the correct variable values. Ask the operations team to confirm the chosen database type and history settings match production. Done means the counts in the test environment match the expected numbers from the spec for each scenario, and any mismatch is resolved before the next step.
Deploy the case definition after sign-off
Once the unit tests pass and the test environment counts match the spec, the case owner and the platform team review the evidence together and approve the deployment. Deploy the case definition through the same pipeline used for other definitions, record the definition version, and confirm the first live case creates the expected plan items. Keep the test scenarios so they can run again on the next definition version. Done means the production deployment is recorded with its version, the first live cases match the spec, and the test scenarios are stored with the case definition.
Repetition patterns by situation
Repetition fits well when the same steps apply to each member of a list that exists before the case starts, such as invoices in a batch, applicants on an approved roster, or assets in an inventory extract. The collection determines how many instances are created, so the bound comes from the data. Confirm how your Flowable version evaluates the collection expression and when it does so.
- Bound: the collection length, plus a defensive maximum instance count if user input can add items to the list.
- Parallel creation: repetition instances are created together, so confirm that the items do not need to be processed one at a time.
- Data validation: check the collection before the case starts, because an empty or null collection changes how the stage completes.
- When BPMN fits better: if each item needs a fixed sequence of gateways, timers and error handling that operations must monitor, a BPMN multi-instance activity is often easier to test and trace.
Check the collection limit against the largest batch you expect in production and test that batch size before go-live.
Retry loops suit work that repeats until a result is acceptable, such as an address verification or a payment confirmation check. This pattern works only when the exit condition is visible in case data and the attempts have a hard ceiling. Without a ceiling, a repeating task whose exit sentry never becomes true keeps creating plan items.
- Bound: a maximum instance count, followed by an escalation task or a timer once the last attempt fails.
- Observable exit: base the exit sentry on a variable the task sets, so the loop does not wait on an external event that may never arrive.
- Backoff: place a timer event listener between attempts to protect downstream services from rapid retries.
- BPMN alternative: a boundary timer with a loop back in a process suits retries where each attempt is a fixed technical call and operations needs to see the retry logic in one diagram.
Confirm with your Flowable documentation how the engine behaves when the maximum is reached, including whether the case moves on or the stage fails, and test both outcomes.
Reviews that recur on a schedule, such as an annual access recertification or a quarterly control check, fit repetition when each cycle is a new instance of the same work. The schedule usually comes from a timer, so the bound is normally the review end date or a fixed number of cycles set by the control owner.
- Timer driven: a timer event listener starts the next cycle, and repetition inside a single cycle stays small.
- Cycle identity: store the cycle number and period in case variables so reports can separate one cycle from another.
- Overlap: decide in advance whether a late cycle may run alongside the next one, because overlap changes the reports and the reviewer workload.
- BPMN or separate cases: a BPMN timer that starts one process per cycle is often simpler to schedule and query when each cycle needs its own approvals.
Record the cycle count, end date and overlap rule in the case model documentation and confirm them with the control owner before build.
Investigations and advisory work often need another round whenever a finding raises a new question, so the number of rounds depends on what the worker discovers. Repetition rules on this kind of work create instances the team cannot see or close easily, so the design should keep a person in control of each new round and enforce a ceiling in the model.
- Human decision: manual activation lets a worker start another round, and the case model caps how many rounds are possible.
- Avoid unbounded repetition: a repetition rule on an open-ended task can multiply plan items faster than the team can review them.
- Completion rules: use completion rules so the stage cannot close while a required investigation remains open.
- Reporting: milestones and history show progress across rounds, which matters when auditors ask how the work was decided.
- Child cases: when rounds grow large, one child case per investigation is easier to govern than a single growing list of plan items.
Agree the round ceiling with the business owner before build, and test the case at that maximum to confirm that the closing rules still work.
Security and operational considerations for repeating cases
Repetition rules multiply plan items, and every new instance inherits the security, data and audit exposure of the case it belongs to. The cards below cover the controls the engine leaves to your application: who can drive repeated work, how collection data is handled, how history grows, and how running plan items are watched.
Who can start and complete repeated work
The CMMN REST API lets callers create case instances and complete human tasks, so a repeating task can be driven by any caller with access to those endpoints. Check which roles can start a case, list plan items, and complete a repeated human task, and confirm that the application, not only the front end, enforces those rules. Test each endpoint with a user who should be refused, because a repeated task that a single user can complete many times changes the outcome of the case.
Sensitive data in collection variables
A repetition rule over a collection variable copies each element into its own plan item context, so personal or account data in that collection is replicated across every instance it creates. Decide which fields belong in the collection at all, and pass identifiers instead of full records where the child work can look up details. Confirm who can read case variables through the API and in history, since those reads expose the same collection.
History growth from repeated instances
Each repeated plan item adds rows to the engine history, so a loop that runs for thousands of elements grows the history tables faster than a fixed sequence. Agree a retention period with records and compliance owners before go-live, and check whether history is kept at the level you need. Ask your database team to size the history tables for the largest expected collection and to plan purge jobs that respect your retention rules.
Audit trail for repeated decisions
When a repeating stage completes or skips a plan item, auditors will ask which element triggered each instance and who approved it. Engine history records plan item transitions, but the business reason for a repetition often lives in your application data. Define which variables and user actions must be written to your audit log, and test that a reviewer can reconstruct the sequence for one case from start to finish.
Monitoring running plan items
Repetition can leave many plan items active at once, and a rule that never reaches its exit condition keeps them open indefinitely. Build queries that count active plan items per case definition and alert when a case holds more than the number you expect. Review those counts against the maximum instance settings in your model, because a count that climbs without limit usually points to a missing exit or an unbounded collection.
Limits set in the model and the application
Max instance counts in the model are only one layer. Reject oversized collections before the case starts, cap how many elements an intake form or API call can submit, and test what happens when a collection is empty or contains duplicates. Record these limits in your runbook so an operator changing a case definition knows which application checks must change with it.
Questions teams ask before building repeating case work
How much effort does a repetition-driven Flowable case take?
Effort depends mainly on how many repeating elements the case has and how well the business rules behind them are defined. A single task that repeats per item in a collection is a small change. A stage that repeats, with its own sentries, milestones and child cases, requires modeling, delegate code, and tests for each path that can run more than once. The main cost drivers are the number of repeating plan items, the number of distinct exit conditions, and whether repeated work calls processes or decisions. Ask any partner to break the quote down by repeating element, so you can see which parts scale with the number of items and which are fixed.
Can an in-house team build repeating case work on Flowable?
Yes, if the team already knows Java and Spring and has worked with CMMN models before. The Flowable open source engines are Apache 2.0 licensed and can be embedded in Spring applications, so the build itself does not require a commercial contract. The risks for an in-house team are usually less about the engine and more about unbounded plan item creation, which only shows up under realistic data volumes. Assess your team's CMMN experience honestly, and consider a short review of the case model by an experienced engineer before the first production release.
What does the project need from our side before work starts?
You need three things: written domain rules for when work repeats and when it must stop, realistic test data with collection sizes close to production, and a non-production environment that matches your database and deployment setup. The Flowable configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, so confirm which one you run. Without agreed stop conditions, a repetition rule has no correct end state, and the test data determines whether limits are tested under load.
How long does validating repetition rules against our own cases take?
Validation time depends on how many case types repeat, how many business exceptions you must replay, and how quickly your subject matter experts can confirm expected outcomes. Plan for a cycle that runs your recorded cases through the model, compares plan item counts with expected counts, and repeats after each fix. Ask for the validation plan in the written scope, including which cases are replayed, who signs off each result, and how many test rounds are included. No duration should be assumed until those items are defined.
How do repetition rules affect Flowable upgrades?
Repetition rules are part of the case model, so they must be retested whenever the engine version changes. Major Flowable releases can change the platform baseline. The 8.0.0 release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, and the 7.0.0 notes describe the move to Java 17, Spring Boot 3 and Jakarta EE. Check which baseline your application uses before planning an upgrade, and include regression tests for every repeating element in the upgrade scope.
Does repetition affect migration from Camunda 7 or Activiti?
It can. Flowable states that Camunda 7 and Activiti data can be migrated in place, including active process instances and history, and offers the free Flowable LEAP tool to report ahead of time what a migration involves. Repeating cases with many active plan items are more complex to reason about during migration, so ask the migration plan to cover running case instances separately. Confirm with Flowable which migration sources apply to your engine version before assuming a route.
Who is responsible for keeping repeating cases safe in production?
Ownership splits between your team and any implementation partner. Your team owns the business rules, the choice of limits, and the monitoring of plan item counts and job failures in production. The partner, if engaged, owns the model, the delegates, the tests and the documentation for the agreed scope. Long-term responsibility for upgrades and monitoring can be covered by a support retainer, which is available from DeployOpen. Write the split into the scope before work starts so that no repeating element is left without an owner.
How DeployOpen scopes Flowable case repetition work
DeployOpen plans, builds, tests and documents Flowable CMMN repetition rules inside your own infrastructure, starting from a written scope. Engagements are fixed-scope, so the repeating tasks and stages, their limits and the test evidence are agreed before development begins.
How we scope
- We list every task and stage that repeats, the business reason for each, and the expected maximum instance count.
- We define the collection variables that drive repetition over a collection and who is responsible for populating them.
- We agree which repetition limits, guard checks and cleanup behavior the written scope covers before any modeling starts.
- Ongoing support, upgrades and continuous testing for repetition rules are available as a retainer after handover.
How we build
- We model repetition rules in the case definition and set explicit maximum instance counts on every repeating plan item.
- We build the process and decision calls that repeating items make, and test them with unit tests against the engine.
- We test boundary cases such as an empty collection, a collection at its limit and a sentry that fires during repetition.
- We check that repeated plan items do not grow without bound under load, using engine test runs in a staging environment you control.
How we hand over
- You receive the case model, the repetition rule settings and the reasoning behind each limit, documented in your repository.
- You receive test cases that show how each repeating item behaves at zero, typical and maximum instance counts.
- You receive a runbook covering how to identify runaway plan items, how to tune limits and how to request a case instance migration when definitions change.
How we support
- Support covers questions on repetition behavior, limit changes and regressions after each Flowable version upgrade.
- We confirm compatibility of repetition rules against the Flowable release you run before you move to a newer version.
- Continuous testing of case behavior can be added to a retainer so changes to repeating items are checked before release.
