Skip to main content
Design dynamic, policy‑driven approval flows that adapt to who’s requesting access, which app/permission is requested, and your risk/compliance rules. Use ordered if / else‑if / else branches and multi‑stage chains to automate the right path every time.

​
What you can do

  • Route by attributes. Build ordered logic using user, app, permission, risk, location, and custom fields.
  • Create multi‑stage chains. Add as many sequential stages as you need.
  • Use “Manager” anywhere. Insert Manager approval at any stage.
  • See why a branch matched. Workflow records show the evaluation order, the branch that ran, and the match reason for audit.

​
Common recipes (copy and adapt)

  1. Department‑based scrutiny
    If user.department = Finance → add CFO/Finance Controller after Manager.
    Else → Manager → App Owner.
  2. Role/level rigor
    If user.role = Contractor → Manager + Security.
    If user.role = Full‑Time Employee → Manager only.
  3. High‑risk apps
    If app.risk = High → Manager → App Owner → Compliance Officer.
    Else → stop after App Owner.
  4. Cost center owners
    If app.cost_center = Marketing → Marketing Finance Partner.
    If app.cost_center = Engineering → VP Engineering.
  5. Regional compliance
    If user.location = EU → Data Protection Officer.
    Else → Manager → App Owner.
  6. Team ownership
    If user.team = Engineering and requesting GitHub → add DevOps Lead after Manager.
    If user.team = Customer Support → skip DevOps, go to App Owner.
  7. Sensitive job families
    If user.job_family IN [Finance, Legal, HR] → Security/Audit stage.
    Else → normal flow.
  8. New hires / transfers
    If user.tenure < 90 days → Manager + HR.
    Else → Manager only.
  9. Role elevation checks
    If user.current_role = Analyst AND requesting Admin entitlement → Director approval.
    Else → standard flow.
Tip: Start from the example closest to your policy, then tweak attributes, operators, and stages.

​
How branching works

  • Rules are evaluated top → bottom.
  • The first matching branch runs.
  • If nothing matches, a required fallback chain runs so every request has a path.
Best practices
  • Put your most specific rules first.
  • Always include a comprehensive fallback.

​
Supported conditions and operators

  • Standard if / else‑if / else routing with ordered evaluation.
  • Expressions over: user, app, permission/entitlement, risk, location, title/level, and custom attributes.
  • AND / OR, equality, set membership, comparisons (e.g., tenure < 90), and nested conditions.
Examples
  • department = Finance AND risk = High → add Security stage.
  • location = EU → add Data Protection stage.
  • title >= Director → skip Manager stage.

​
Build it: from zero to working in 5 steps

  1. Define attributes. Confirm the fields you’ll route on (e.g., user.department, app.risk, user.location, custom fields).
  2. Order branches. Add branches from most specific to least specific.
  3. Add stages per branch. For each matched branch, add the sequential approver stages (e.g., Manager → App Owner → Security).
  4. Place Manager exactly where needed. Manager can appear at any stage.
  5. Add fallback + validate. Include a final fallback chain, run validation, and fix any flagged errors.
Load‑test complex rulesets if you expect high volume.

​
Visibility and auditability

Use Workflow records to see:
  • Which branches were evaluated and in what order
  • Which branch matched and ran
  • The explicit match reason
This makes troubleshooting and audit reviews straightforward.

​
Performance guidance

  • Flexible Approvals supports complex rules and long chains. Extremely large configurations can increase evaluation latency and time‑to‑approval.
  • Recommendations:
    • Keep to ≤ 10 branches (chains) per approval workflow when possible.
    • Keep to ≤ 50 condition rules per workflow when possible.

​
FAQs

Are parallel approvals supported?
Approvals run sequentially across stages. For “parallel‑ish” behavior, put multiple approvers in the same stage; those approvers are evaluated with OR logic. What happens if an approver becomes unavailable mid‑stage?
Product policies apply to auto‑removal or reassignment. If not auto‑handled, the request is blocked with an actionable error until resolved. Will my existing approvals migrate?
Yes. Migration is designed to be transparent with safeguards to prevent disruption. What prevents broken configurations?
Validation blocks malformed chains until fixed.

​
Troubleshooting

  • A request skipped the branch I expected. Check branch order; more specific rules must appear above broader ones. View the match reason in Workflow records.
  • Manager stage didn’t trigger. Ensure Manager is explicitly placed at the intended stage of the matching branch.
  • Latency feels high. Reduce total branches/conditions; prefer simpler predicates where possible.
  • Compliance stage didn’t run. Confirm the risk/region attributes on the request match your condition logic (e.g., app.risk = High, user.location = EU).

​
Example: full configuration

Branches (evaluated top → bottom):
  1. If requester.department = "Finance" AND request.risk = "High"
    1. Manager
    2. Finance Ops
    3. Security
  2. Else if requester.location = "EU"
    1. Manager
    2. Data Protection Officer
  3. Else (fallback)
    1. Manager
The first true branch runs; otherwise the fallback executes.

​
Glossary

  • Branch - A conditional path (if / else‑if / else) that may run.
  • Stage - A sequential step within a branch with one or more approvers.
  • Fallback - The final, always‑present chain that runs when no other branch matches.
  • Match reason - Recorded explanation of why a branch ran (for audit/debugging).