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

# Setting Up Pre-Approvals

## Background

Pre-approval rules let requests that match a rule skip the approval workflow. When someone covered by a rule requests the app or permission, Lumos grants it immediately instead of routing it to approvers. With the conditions framework, you define who a rule covers using identity attributes: team, title, manager, group membership, custom attributes, or start date. Conditions combine with `AND`, `OR`, and `NOT` logic, so a rule targets exactly the population that shouldn't need sign-off.

A pre-approval rule is not an approval workflow. An approval workflow decides who signs off when someone asks. A pre-approval rule means matching requests skip sign-off entirely. Requests that don't match any rule follow the app's normal approval workflow.

## When to use pre-approval rules

Pre-approval works best where an approval step adds delay but no real control:

* **Birthright tooling by team.** Everyone on the Engineering team gets Datadog. A manager approving every one of those requests is a formality, not a decision.
* **Role-based defaults.** Anyone whose title contains `Account Executive` gets the Salesforce `Standard User` permission, while `Admin` still routes through approval.
* **Employee-only fast lanes.** Pre-approve an app for full-time employees (`NOT` in the contractor group), so contractors still go through security review.
* **Scoped exceptions.** Pre-approve a single low-risk permission on an app whose other permissions keep their approval workflow.

If you're not sure which apps are good candidates, look at your completed approval tasks. An app with high approval volume and no denials is a strong signal that approval there is a formality.

## Prerequisites

* The app is in the AppStore and requestable.
* The identity attributes you plan to condition on (team, title, groups, custom attributes) are synced from your IdP or HRIS. A condition on an attribute Lumos has no data for matches no one.

## Configuration

1. Go to AppStore → \[App Name].
2. Click the "Pre-approval rule" section.
3. Choose the scope: the whole app, or specific permissions. Scoping to permissions keeps approval in place for everything you don't list.
4. Build the condition. Add a condition row, then pick an attribute, an operator, and a value. For example: `Team` `equals` `Engineering`.
5. Combine conditions with `AND` and `OR`. Use `AND` when every condition must be true, `OR` when any one is enough.
6. Save the rule.

When a request comes in from someone the rule covers, Lumos grants it without creating an approval task. Everyone else follows the app's approval workflow as before.

## Example attributes and operators

| Attribute | Type | Example condition |
| - | - | - |
| `identity.email` | String | `email` `ends with` `@lumos.com` |
| `identity.team` | String | `team` `equals` `Engineering` |
| `identity.title` | String | `title` `contains` `Engineer` |
| `identity.manager` | Reference | `manager` `equals` a selected user |
| `identity.groups` | List | `groups` `contains` a selected group |
| `identity.custom_attributes` | Varies | `Employment Type` `equals` `Full-time` |
| `identity.start_date` | Date | `start date` `>=` a selected date |
| `identity.end_date` | Date | `end date` `exists` |

String operators: `equals`, `does not equal`, `contains`, `starts with`, `ends with`, `in`, `exists`.

Date and numeric operators: `equals`, `does not equal`, `>`, `>=`, `<`, `<=`, `in`, `exists`.

Each operator also has a negated form, such as `does not contain`.

## Edge cases

* If a request matches no pre-approval rule, it follows the app's approval workflow. There is no error state; the rule doesn't apply.
* Conditions are evaluated when the request is submitted. A rule you add today does not retroactively approve requests already sitting with approvers.
* If an identity's attributes change after access was granted, the grant is unaffected. Pre-approval rules decide how requests are approved; they don't remove access.

## Limitations

* Pre-approval doesn't grant access proactively. The user still submits a request; the rule removes the approval step. For automatic birthright provisioning, use an access policy instead.
* Condition accuracy depends on your synced identity data. If titles or teams are stale in your IdP or HRIS, rules built on them will match the wrong people.

## FAQ

**How is this different from removing the approval workflow?**\
Removing the workflow makes the app self-serve for everyone who can see it. A pre-approval rule removes approval only for the population the condition matches. Everyone else still goes through approvers.

**Can one app have multiple pre-approval rules?**\
Yes. A request that matches any rule is pre-approved.

***

##