> ## 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. # Connecting an Integration The Lumos-side steps are the same for every integration, whether it's a dedicated connector from the Integration Library, a generic connector, or one you built with the Connector SDK. This page covers those shared mechanics. ## The connection flow Every connection follows the same flow: 1. **Prepare the end system.** Create the service account, grant the permissions, or generate the credentials your connector needs. This is the part that differs per system, and it's what each connector's own page documents under **Required plan and roles** and **Instructions**. 2. **Find the integration card in Lumos.** Integrations are managed from the Lumos admin settings. Search for your app or generic method and open its card. 3. **Enter credentials and connect.** The card prompts for exactly what the connector needs, such as an API token, OAuth consent, or a database URI with a username and password. Click **Connect**. 4. **Wait for the first sync.** On a successful connection Lumos starts an initial sync, pulling accounts and entitlements from the system. Duration depends on the size of the system, from minutes for small apps to considerably longer for large directories. > **Some connectors take more than one step** > > A few connectors, such as JDBC, require a connector version download in **Configure Integrations** before the connection settings appear. When a card shows a download step instead of settings, complete it first. The settings screen follows. **Checking sync status.** The integration card shows the connection state and last sync. If a sync fails, start with the connector page's **Troubleshooting** section, which is keyed to the error strings Lumos surfaces. Screenshot 2026 07 26 At 11 40 14 PM **Reconnecting.** Click `Configure Integration` to rotate credentials or upgrade a connector's scope set. Reconnecting replaces the stored credentials without losing the app's history. Some integrations have reconnect specific caveats listed in the integration-specific document. **Disconnecting.** Disconnecting removes stored credentials and stops syncs. Your synced data history stays in Lumos. ## Access levels and capabilities Every connector page carries the same two building blocks: an access statement (what permissions the connection needs) and a **Capabilities** table (what Lumos can do once connected). Here's how to read both. ### Sync, provisioning, and deprovisioning **Sync** is read access. Lumos pulls accounts and entitlements from the system on a daily schedule, keeping its picture of who-has-what current. Sync alone powers visibility, Access Reviews, and reporting. **Provisioning** is write access. Lumos creates accounts, assigns and manages entitlement access, and grants access in the system, driven by access requests and lifecycle workflows. **Deprovisioning** is the write path for removing access: deactivating or deleting accounts, unassigning entitlements, and offboarding actions like transferring data or freeing licenses. The connector page's Capabilities section states exactly which deprovisioning actions the connector supports, because they differ by system. ### Reading a Capabilities table Connector pages show capabilities in a table like this: | Functionality | Type | Sync | Provision | Description | | :- | :- | :- | :- | :- | | Users | Account | Yes | Yes | User accounts in the system | | Groups | Permission | Yes | Yes | Group memberships | | Roles | Permission | Yes | No | Admin roles, visible but not assignable | A **Yes** under Sync means Lumos can see that object type. A **Yes** under Provision means Lumos can change it. A row that syncs but doesn't provision is possible: many systems expose reads their API doesn't allow writes for. ### The read-only trade-off Many connectors can run with reduced permissions in a sync-only mode. The trade is always the same: fewer permissions granted means limited actions Lumos can take, no provisioning. Every connector page documents this under **Read-only access vs provisioning**, including exactly which scopes the read-only path drops and which Lumos features stop working as a result. If your security review prefers minimal grants, start read-only. Moving to provisioning later is a reconnect with broader permissions, not a rebuild. ## Types of integrations An integration does one or more of these jobs. Knowing which job you need tells you which integration to set up. | Type | What it does | Examples | | :- | :- | :- | | User management | Reads users, accounts, and entitlements. With write access, it also provisions and deprovisions. This powers access requests, Access Reviews, lifecycle workflows, and license reclamation. | Almost every connector in the Integration Library | | Non-human identity (NHI) | Inventories non-human identities, assigns owners, and finds risky credentials and access. | [AWS IAM (NHI)](/integrations/library/non-human/aws-iam-nhi), [Entra ID (NHI)](/integrations/library/non-human/entra-id-nhi) | | ITSM | Opens a ticket for each access request and updates it until the work is done. For apps Lumos can't write to, the ticket routes the work to the app owner. | Jira ITSM, ServiceNow ITSM | | Messaging | Lets employees request and approve access in chat, and sends Lumos notifications there. | Lumos app for Slack or Microsoft Teams | | Incident management | Syncs on-call schedules, and makes offboarding on-call safe by moving open incidents before deactivating the user. | PagerDuty | ### One service, more than one integration The same service often has separate integrations for separate jobs, each with its own credentials. Connecting one does not give you the other. | Service | Integration | What it does | | :- | :- | :- | | Slack | Slack Provisioning | User management: accounts, user groups, offboarding | | Slack | Lumos app for Slack | Messaging: requests, approvals, and notifications in chat | | Jira | Jira Provisioning | User management: syncs Jira users into Lumos | | Jira | Jira ITSM | Tickets for access requests and removals | | Zendesk | Zendesk | User management for Zendesk agents and licenses | | Zendesk | Zendesk ITSM | Tickets for access requests and removals | Set up each integration from its own page, and grant only the scopes that page lists. ## Managing integrations programmatically Everything above can also be done from code. See [API](/integrations/managing/api) and [Terraform](/integrations/managing/terraform) to connect and manage integrations, and [Triggering Syncs Deep Dive](/integrations/managing/triggering-syncs-deep-dive) to run syncs from a script or scheduler.