AppStore in Lumos is a curated catalog of “requestable” apps and permissions, enabling employees to discover, request, and obtain necessary access. It’s the front-facing portion that handles requests, approvals, and advanced provisioning.

With the AppStore API you can create, read, update, and delete permissions, attach provisioning groups to them, and configure your AppStore apps and access request flows.

The AppStore API can be useful when there are too many objects for you to configure manually, when you want to create new objects from an automated process (e.g. permissions), or for other bespoke use cases such as creating alerting rules when an AppStore app does not have enough active app admins.

Typical Uses

Access Requests: A homegrown self-service portal allows employees browse available apps or roles (like “Salesforce Admin”), submit a request, and track approval.
Pre-Approval Rules: For commonly granted roles or short-term access, automatically approve requests without manual intervention.
Fine-Grained Permissions: Distinguish different permission levels within the same app, e.g., “Read-Only” vs. “Admin.”

A Note on Group Identifiers

Groups in Lumos (i.e. those that have been synced from Groups in third party applications like Google or Okta) have two identifiers: an internal id (Lumos’s identifier for the object) and an integration_specific_id (the identifier of the Group in the third party application). You can create an AppStore requestable permission with a provisioning group by passing in the id OR by passing the integration_specific_id.

In either case you have to pass in the app_id of the app that owns the Group (e.g. the Okta app in Lumos, or the Google Workspace app in Lumos). If you pass in the integration_specific_id we will check to see if there’s a Group with that external already synced into Lumos for the given app and use that one.

Synced v Native Permissions

There are two types of requestable permissions in Lumos: synced and native.

A synced permission is created and deleted based on the state of a third party object. In Lumos, synced permissions are created when you have an Okta app that has groups associated with it. We pull the groups as synced permissions.

A native permission is created natively in Lumos either by pointing and clicking or via the API. The native permission can be linked to a provisioning group (e.g. an AWS okta push group), but the overall lifecycle of the permission is managed in Lumos and not tied to any third party system.