> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flexible Approvals

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).