maestro
latest
false
UiPath logo, featuring letters U and I in white

Maestro user guide

Last updated Oct 30, 2025

BPMN patterns and practices

This page introduces typical BPMN modeling patterns used to represent business logic clearly and consistently in process diagrams. These patterns help structure the process visually and conceptually, even when not all elements are supported at runtime.

Flow and routing

  1. Straight‑through flow (step-by-step)

    Use when
    • You want a simple, linear process.
    • Each task must finish before the next begins.
    • There is at most one decision near the end.
    Pattern in simple words
    1. Start.
    2. User task: Collect compliance forms.
    3. Service task: Validate information.
    4. Exclusive gateway: Complete?
      • If Yes: User task Approve supplier. End Approved.
      • If No: User task Request resubmission. End Needs update.
    Note: Keep the main path short. Defer exceptions to separate patterns.
    Other scenarios
    • Finance: Process payroll batch. Approve. Send to payment.
    • Insurance: Register claim. Verify data. Route to adjuster.
    • Healthcare: Intake form review. Approve patient registration.
    • Manufacturing: Material intake. Check specs. Approve supplier.
    • Retail: Product listing. Check completeness. Publish or revise.

  2. Either‑or decision with default path (exclusive)

    Use when
    • A single decision is mandatory.
    • One branch should always run, even when conditions are not met.
    • You want to prevent unhandled cases.
    Pattern in simple words
    1. Start.
    2. Service task: Check inventory.
    3. Exclusive gateway: In stock?
      • If Yes: Service task Ship order. End Shipped.
      • Default: Service task Create backorder. End Backordered.
    Note: Mark the default path on the gateway.
    Other scenarios
    • Finance: Check budget. Approve or hold request.
    • Healthcare: Prescription renewal. Dispense or contact doctor.
    • Retail: Confirm stock. Fulfill or backorder.
    • Public sector: Verify data. Approve or return for correction.
    • Telecom: Check coverage. Activate or escalate.

  3. Do tasks at the same time, then continue (parallel)

    Use when
    • Several steps can run concurrently without dependencies.
    • All branches must complete before moving forward.
    Pattern in simple words
    1. Start.
    2. Parallel gateway: split.
      • Service task: Blood tests.
      • Service task: Imaging.
      • User task: Consent verification.
    3. Parallel gateway: join.
    4. User task: Review results.
    5. End Ready for procedure.
    Note: Use a matching parallel join to synchronize.
    Other scenarios
    • Finance: Tax filing, payments, and confirmations run together.
    • Insurance: Collect claim evidence, police report, and adjuster notes in parallel.
    • Manufacturing: Run QA, design validation, and material checks concurrently.
    • Retail: Update pricing, marketing, and stock lists together.
    • Public sector: Conduct budget, legal, and policy reviews in parallel.

  4. Run any needed subset, then merge (inclusive)

    Use when
    • One, several, or none of the branches may be required.
    • The process must merge cleanly regardless of which branches ran.
    Pattern in simple words
    1. Start.
    2. Inclusive gateway: split.
      • User task: Request photos.
      • User task: Request repair estimate.
      • User task: Request police report.
    3. Inclusive gateway: merge.
    4. User task: Assess claim.
    5. End Decision made.
    Note: Use inclusive merge to handle variable combinations safely.
    Other scenarios
    • Finance: Optional compliance or fraud checks.
    • Healthcare: Trigger labs and imaging only when required.
    • Retail: Gather optional marketing or packaging assets.
    • Public sector: Collect specific applicant forms when applicable.
    • Manufacturing: Run optional quality audits.

  5. First event wins (event‑based gateway)

    Use when
    • The process waits for either a reply or a deadline.
    • You need “whichever happens first” behavior.
    Pattern in simple words
    1. Start.
    2. Send task: Send approval request.
    3. Event‑based gateway: wait for one of the following.
      • Message event: Approval received. Then user task Process request. End Approved.
      • Timer event: Seven days elapsed. Then user task Escalate decision. End Escalated.
      Note: Keep exactly one message and one timer attached to the gateway.

    Other scenarios

    • Finance: Loan documents received versus deadline leads to auto‑decline.
    • Healthcare: Lab results received versus escalate to specialist.
    • Manufacturing: Engineering sign‑off versus escalate to production.
    • Retail: Supplier quote versus alternate sourcing.
    • Public sector: Public comment versus policy vote.

Repetition

  1. Same task over a list, one by one (sequential multi‑instance)

    Use when
    • Tasks must occur in order.
    • Each step depends on a prior result.
    • Sequence integrity matters.
    Pattern in simple words
    1. Start.
    2. Service task with sequential multi‑instance: Reconcile transaction over the collection.
    3. End All reconciled.
      Note: Sequential mode preserves order.
    Other scenarios
    • Finance: Post invoice lines in sequence.
    • Insurance: Review claims in received order.
    • Healthcare: Process test results per patient.
    • Retail: Approve store returns sequentially.
    • Manufacturing: Inspect items per batch.

  2. Same task over a list, all at once (parallel multi‑instance)

    Use when
    • Items are independent.
    • Items are independent
    • Order does not affect outcome.
    Pattern in simple words
    1. Start.
    2. Service task with parallel multi‑instance: Run security scan for each server in the collection.
    3. User task: Review results.
    4. End Scan complete.
    Note: Use aggregation to collect per‑item outputs.
    Other scenarios
    • Finance: Client credit checks simultaneously.
    • Insurance: Evaluate multiple policies in parallel.
    • Manufacturing: Inspect multiple lines concurrently.
    • Retail: Update store prices at once.
    • Public sector: Review permits across districts together.

  3. Nested repetition inside a subprocess

    Use when
    • Two levels of iteration exist, such as batch and item.
    • You need a clean structure that keeps loops organized.
    Pattern in simple words
    1. Start.

    2. Subprocess with sequential multi‑instance: Inspect batch, one batch at a time.

      • Inside the subprocess: Service task with parallel multi‑instance: Inspect item for each item in the batch.

    3. End Batch complete.
    Note: Use sequential outer and parallel inner when batches must not overlap.
    Other scenarios
    • Finance: Process monthly statements with multiple entries.
    • Healthcare: Audit patients by department.
    • Retail: Reconcile store sales by region.
    • Manufacturing: Audit batches by product line.
    • Insurance: Review claims by policy group.

Time and reminders

  1. Reminder attached to a task (non‑interrupting timer)

    Use when
    • You want periodic reminders while a task stays open.
    • The task should remain available until completion or timeout.
    Pattern in simple words
    1. Start.
    2. User task: Await submission. Attach a non‑interrupting boundary timer set to a schedule, for example every three days.
    3. On timer: Service task Send reminder. End Reminder sent.
    4. Main path: Exclusive gateway Submitted? If Yes, End Graded. If No and deadline reached, End Deadline missed.
    Note: The timer does not stop the user task.
    Other scenarios
    • Finance: Invoice approval reminders.
    • Healthcare: Appointment reminders before due date.
    • Manufacturing: Supplier update reminders.
    • Retail: Purchase order follow‑ups.
    • Public sector: Application completion reminders.

  2. Deadline breach stops the task (interrupting timer)

    Use when
    • A task must end automatically after a fixed duration.
    • There is a clear SLA or cutoff.
    Pattern in simple words
    1. Start.
    2. User task: Await confirmation. Attach an interrupting boundary timer set to a duration, for example 48 hours.
    3. On timer: Service task Cancel booking. End Cancelled.
    4. On message Confirmation received: Service task Schedule install. End Scheduled.
    Note: The interrupting timer ends the user task when time expires.
    Other scenarios
    • Finance: Month‑end approval deadline triggers escalation.
    • Healthcare: Consent not received by deadline leads to reschedule.
    • Retail: Quote expiration triggers closure.
    • Public sector: Unanswered notice triggers auto‑closure.
    • Manufacturing: Unacknowledged purchase order triggers auto‑cancel.

  3. Start on a schedule (timer start)

    Use when
    • The process must start on a recurring schedule.
    • Execution is independent of external input.
    Pattern in simple words
    1. Timer start: Every day at a specific time, for example 05:00.
    2. Service task: Optimize routes.
    3. End Routes ready.
      Note: Define the recurrence schedule and timezone.
    Other scenarios
    • Finance: Daily cash‑flow report.
    • Healthcare: Daily patient census updates.
    • Retail: Nightly inventory sync.
    • Manufacturing: Daily production scheduling.
    • Public sector: Nightly data consolidation.

  4. Staged escalation (laddered timers)

    Use when
    • You want multiple reminders before a final close.
    • Work continues until the final condition or message arrives.
    Pattern in simple words
    1. Start.
    2. User task: Await required documents.
    3. Non‑interrupting timer after three days: Service task Send gentle reminder. End Reminder one sent.
    4. Non‑interrupting timer after seven days: Service task Send urgent reminder. End Reminder two sent.
    5. Interrupting timer after ten days total: Service task Close case for no response. End Closed.
    6. Interrupting message Documents received: User task Review submission. End Reviewed.
    Note: Use non‑interrupting timers for reminders and one interrupting control for closure.
    Other scenarios
    • Finance: Expense receipts overdue — reminder, warning, close.
    • Healthcare: Missing pre‑op clearance — reminder, escalate, reschedule.
    • Manufacturing: Vendor compliance documents — staged reminders before cutoff.
    • Retail: Supplier purchase order confirmation — staged follow‑ups.
    • Public sector: Missing grant application forms — staged reminders.

Messages and updates

  1. Handle updates without interrupting work (non‑interrupting boundary messages)

    Use when
    • You need to process updates while a task is in progress.
    • Updates should not halt the main work.
    Pattern in simple words
    1. Start.
    2. Subprocess: Deliverable preparation.
    3. Non‑interrupting boundary message Updated requirements received: User task Log new requirements. Service task Adjust project plan. End Requirements handled.
    4. Non‑interrupting boundary message Compliance rule change received: User task Review rule change. Service task Update compliance checklist. End Compliance handled.
    5. Main path: Deliverable preparation completes. End Deliverable completed.
    Note: Each message triggers a small side flow without stopping the main work.
    Other scenarios
    • Finance: Credit‑risk review receiving new market data.
    • Healthcare: Care‑plan preparation receiving updated lab results.
    • Manufacturing: Product design updates from regulation changes.
    • Retail: Campaign plan updates with product revisions.
    • Telecom: Network upgrade planning updates with compliance changes.

  2. Cancel during a task (interrupting message)

    Use when
    • Work must stop immediately on a cancel request.
    • A clear message should abort the task.
    Pattern in simple words
    1. Start.
    2. Subprocess: Process booking.
    3. Interrupting boundary message Cancel request: User task Stop and notify. End Cancelled.
    4. Normal path: Process booking completes. End Completed.
    Note: The interrupting message cancels the active work at the subprocess boundary.
    Other scenarios
    • Finance: Loan withdrawal cancels underwriting.
    • Healthcare: Patient cancels a scheduled procedure.
    • Manufacturing: Cancel production order before run.
    • Retail: Cancel order before shipment.
    • Telecom: Cancel new service setup.

  3. Event‑driven dispatcher (message start)

    Use when
    • A new external message should start a process.
    • Each event spawns an independent workflow instance.
    Pattern in simple words
    1. Message start: New email received.
    2. Service task: Create support ticket.
    3. Send task: Confirm receipt.
    4. End Ticket created.
    Note: Each incoming message creates a new instance.
    Other scenarios
    • Finance: Vendor request message starts onboarding.
    • Healthcare: Referral message starts patient intake.
    • Manufacturing: Defect report starts QA process.
    • Retail: Online order starts fulfillment.
    • Public sector: Citizen inquiry opens a case record.

  • Flow and routing
  • Repetition
  • Time and reminders
  • Messages and updates

Was this page helpful?

Support and Services
Get The Help You Need
UiPath Academy
Learning RPA - Automation Courses
UiPath Forum
UiPath Community Forum
Uipath Logo
Trust and Security
Terms of Use
Privacy Policy
Cookies Policy
© 2005-2025 UiPath. All rights reserved.