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

# Approving AppStore Requests by Entitlement Owner

> Route each AppStore access request to the owner of the requested permission using the Entitlement Owner approver type.

## Background

Entitlement Owner is an approver type for AppStore approval workflows. It sends each access request to the owner of the requested permission, so you set up approvals once per app instead of once per permission. Lumos reads the owner from each permission's **Lumos Owner** and **Synced Owner** fields when the request is submitted. If a permission has no owner, Lumos blocks the request and notifies Org Admins.

For how approval workflows work in general, see [Flexible Approvals](/for-admins/appstore/flexible-approvals) and [Setting Up Permission-Based Approvals](/for-admins/appstore/setting-up-permission-based-approvals).

## When to use Entitlement Owner

* **You govern access through your source of truth.** You manage ownership in source of truth apps like Active Directory, Okta, or Entra, and each owner approves requests for their own entitlements. Add Entitlement Owner to the app's workflow once, and every group under that app routes to its owner.
* **You add permissions often.** New permissions use the app's workflow as soon as they sync, so owner approval applies with no setup.
* **Your owners live in a spreadsheet.** Upload owners by CSV as Lumos Owner, and requests route to them the same way.
* **Some permissions need different approvers.** Give those permissions their own approval workflow. They skip the app-level workflow and every other permission keeps routing to its owner.

## Prerequisites

* You can edit AppStore approval workflows.
* Your permissions have owners set by the source of truth app, or can be imported via CSV. Set owners in one of these ways:
  * **Synced Owner:** pulled from the connected app, for integrations that can list group owners. Lumos fills it only when a group has exactly one user as owner.
  * **Lumos Owner:** set on the permission in Lumos. See [Set Lumos Owners](#set-lumos-owners) below.
* Each owner is a Lumos user. Lumos ignores owners that are only synced accounts with no matching Lumos user.

## Configuration

### Add Entitlement Owner to an approval workflow

1. Go to **AppStore → \[app name] → Settings → Approval Workflow**.
2. Select the stage the owner should approve, or add a new stage.
3. In the approver picker, select "Entitlement Owner".
4. Click "Save".

The stage now shows **Entitlement Owner** as an approver. Every permission that uses the app's workflow routes to its own owner.

Entitlement Owner can share a stage with other approvers, such as a named user or App Admins. Everyone on the stage gets the task.

### Set Lumos Owners

Use whichever method fits your organization:

**In the UI, one permission at a time**

1. Go to **Apps → \[app name] → Permissions** tab.
2. Open the permission.
3. In the "Lumos Owner" field, select a user.
4. Click "Save".

**By CSV, for a whole app**

1. Go to **Apps → \[app name] → Permissions** tab.
2. Click the download CSV icon.
3. In the CSV, enter each permission's owner in the `Owner Email` column. Lumos matches the email to a user. To match by name instead, use `Owner Given Name` and `Owner Family Name`.
4. Click "Enrich Permissions".
5. Select the CSV file. Lumos supports files up to 10 MB.
6. Map your columns. The `Permission ID` column is required.
7. Confirm the update.

If Lumos finds no matching user, or several users share the same full name, it skips that permission and reports an error. For the full upload flow, see [Adding Permission Display Names and Descriptions](/for-admins/applications-entitlements/adding-permission-display-names-and-descriptions).

**By API**

* Set an owner with `PUT /v1/entitlements/{entitlement_uuid}` and the body field `lumos_owner_id: {user_uuid}`.
* List an app's permissions with `GET /v1/apps/{app_uuid}/entitlements`.

*(Both available in the V1 API.)*

Lumos doesn't send a webhook or event when a Lumos Owner changes. If another system reads owners from Lumos, poll the list endpoint to pick up changes.

## How Lumos picks the approver

| Situation | Who gets the approval task |
| - | - |
| Only Lumos Owner is set | The Lumos Owner |
| Only Synced Owner is set | The Synced Owner |
| Both are set to the same user | That user |
| Both are set to different users | Both users. Either one can approve the stage. |
| No owner is set on the permission | Nobody from Entitlement Owner. Other approvers on the stage still get the task. If Entitlement Owner is the only approver, Lumos blocks the request and notifies Org Admins. |
| The request names an app but no permission | Same as no owner. There is no permission to read an owner from. |
| The permission has its own approval workflow | Entitlement Owner on the app-level workflow doesn't apply. The permission's own workflow runs. |
| A pre-approval rule matches the request | Lumos skips approval. See [Setting Up Pre-Approvals](/for-admins/appstore/setting-up-pre-approvals). |

Lumos picks the approver when the request is submitted, using the owner data it has at that time. A change to an owner applies to requests submitted after the change.

Lumos treats Lumos Owner and Synced Owner as equals, with no priority between them. Lumos combines both, removes duplicates, and any one approver satisfies the stage.

## Edge cases

**Requests for several permissions.** If one request includes more than one permission, Lumos splits it into one request per permission. Each owner sees and approves only their own permission, even when two permissions share an owner.

**No owner on the permission.** If Entitlement Owner is the only approver on the stage, Lumos blocks the request and notifies Org Admins. The notification names the permission and the requester who is waiting. If the stage has other approvers, they still get the task. Lumos never auto-approves a request because an owner is missing.

**Owner isn't a Lumos user.** Lumos drops owners that are only synced accounts with no matching Lumos user, and treats the permission as having no owner. Link the account to a Lumos user, or set a Lumos Owner instead.

**Owner changed in the connected app.** Synced Owner updates when Lumos next syncs owners from the app. Requests submitted before that sync use the previous owner.

## Limitations

* **Synced Owner covers only some groups.** It fills only for integrations that can list group owners, and only when a group has exactly one user as owner. If the source lists several owners, or a group as owner, Synced Owner stays empty. Set Lumos Owner for those permissions.
* **Each owner field holds one user.** A permission gets two approvers only when its Lumos Owner and Synced Owner are different users.
* **One approval satisfies the stage.** Lumos doesn't support requiring every owner to approve.
* **Don't rename the Lumos Owner or Synced Owner attributes.** Lumos finds owners by those attribute names. After a rename, owners stop resolving and requests follow the no-owner path. A custom attribute you create with the same name doesn't confer approval authority.
* **Custom directory attributes don't sync as owners.** Synced Owner reads the integration's owner field only.
* **Resource-scoped permissions aren't supported.** Entitlement Owner resolves owners for app-wide permissions only.
* **The legacy approval API can't edit these workflows.** Writes to the legacy approval fields on an app that uses Entitlement Owner return `403`. Reads don't report the Entitlement Owner approver. To manage these workflows through the API, use the Workflows API, which accepts Entitlement Owner as a defined approver.
* **AppStore approval workflows only.** Entitlement Owner isn't available in Flows manual-task steps or as a notification recipient.
* **Previews show the approver type, not the person.** When you preview approvers through the AppStore agent or the Lumos MCP server, the approver appears as "Entitlement Owner" rather than the owner's name.
* **Ownership doesn't transfer automatically.** When an owner leaves or changes roles, update the Lumos Owner yourself.

## Troubleshooting

### A request is blocked and Org Admins got a notification

The permission has no Lumos Owner and no Synced Owner. Set a Lumos Owner on the permission. New requests for that permission route to that owner.

### A permission's owner didn't get the task

Check these in order:

1. The permission doesn't have its own approval workflow. If it does, that workflow runs instead.
2. A pre-approval rule didn't match the request. A match skips approval.
3. The owner is a Lumos user, not an unlinked synced account.

### An owner I changed in the connected app still isn't getting tasks

Synced Owner updates on the next owner sync. Set a Lumos Owner to apply the change now.

### Several people received the same approval task

The permission's Lumos Owner and Synced Owner are different users, so both receive the task. Any one of them can approve the stage.

## FAQs

### Do I need to update the workflow when new groups are added?

No. New permissions use the app's workflow as soon as they sync, and Entitlement Owner picks the owner at request time.

### Can a permission have more than one approver?

Yes, when its Lumos Owner and Synced Owner are different users. Both get the task, and either one can approve. Each field holds one user.

### Is Entitlement Owner the same as Permission Owner?

Yes. Entitlement Owner was previously labeled Permission Owner, including in Access Reviews.