> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/integrations/iam/jumpcloud.md). # JumpCloud Connect JumpCloud to Siit to sync your users and groups, and run identity actions — add to group, reset password, reset MFA — directly from Siit request side panels, workflows, and IT Agent playbooks.
### What you get * **Live directory** — JumpCloud users and User Groups sync into Siit with profile attributes and group memberships. * **Identity actions from any request** — add to group, reset password, reset MFA, directly from the request side panel. * **Workflow-driven automation** — use JumpCloud actions in any workflow, with approvals where needed. * **IT Agent native support** — JumpCloud actions are first-class in IT Agent playbooks. ### What syncs from JumpCloud | Category | Fields | | -------- | --------------------------------------------------------- | | Identity | First name, last name, email, username, JumpCloud user ID | | Profile | Job title, department, manager, location, employee type | | Groups | User Groups, memberships | | Status | Active / suspended | Work email is the canonical identifier. ### Actions available * **Add user to group** * **Remove user from group** * **Generate temporary password** (Siit creates the password, the user changes it at next sign-in) * **Reset MFA** (clears enrolled factors, forces re-enrollment) * **Recovery Key** (the FileVault or BitLocker key escrowed for the user's computer) — the menu entry reads **Show Recovery Key** when you take the key yourself, so the two modes it offers are visible before you open it * **Suspend user** * **Activate user** Actions are available from the request side panel, in workflows, and in IT Agent playbooks. Sensitive actions can be gated behind approvals. **Generate temporary password** and **Recovery Key** both hand the employee a value only they should read. Siit delivers it privately — a Slack or Teams direct message behind a **Reveal** button, or a reply on the request only the requester can open — and takes it back when it expires. The value never reaches the request thread, the AI agent, or an export. See [Secret codes](/request-management/secret-codes.md). **Recovery Key** is only offered on a computer that has a key escrowed in JumpCloud, that Siit holds for that employee, and whose JumpCloud system owner maps to their account. JumpCloud does not rotate the key, so it stays valid until you rotate it yourself. ### Note on device and system management JumpCloud can also manage devices, SSH keys, LDAP, and RADIUS. Siit's integration currently focuses on **identity** (users, groups, password / MFA). If you rely on JumpCloud for device management and want those actions in Siit, reach out via in-app chat — we're collecting interest. ### Before you connect * You'll need a JumpCloud **Administrator** account with at least the **User Admin with Billing** role (or higher) to generate an API key. * Decide which admin's API key Siit will use. The integration inherits that admin's permissions. ### Connect JumpCloud 1. In JumpCloud, generate an API key: * Sign in to the JumpCloud Admin Portal. * Click your initials (top right) → **My API Key**. * Click **Generate New API Key** (if you don't have one) and copy the key. 2. In Siit, go to **Settings → Workspace → Integration library**. 3. Find **JumpCloud** in the IAM section and click **Connect**. 4. Paste the API key and your JumpCloud organization ID (visible under **Settings → Organization** in JumpCloud), then click **Authorize**. 5. Siit runs an initial import of users and groups. 6. Review the imported data and click **Finish setup**. > **Tip** — API keys in JumpCloud are tied to a specific admin user. Use a dedicated service admin account rather than a personal one so the integration survives admin turnover. ### After the connection * **Check your People list** — confirm user counts match JumpCloud's active users. * **Scope the groups** — in **Settings → Workspace → Integration library → JumpCloud**, you can scope which User Groups are synced if you only want a subset. * **Try an action from a request** — open any request and use the side panel to add the requester to a group. * **Build a workflow** — a classic starter: access request → manager approval → JumpCloud add to group → DM confirmation. ### Sync frequency JumpCloud data refreshes automatically every few hours. Actions run on demand, immediately, when triggered. To pull the directory in straight away, open the **⋯** menu on the JumpCloud card in **Settings → Workspace → Integration library** and pick **Synchronize**. The action hides itself while a sync is running and for 15 minutes after the last one. Group memberships are heavier to read, so Siit refreshes them on their own weekly cycle rather than on every scheduled sync. **Synchronize** refreshes them too, so a group you have just changed in JumpCloud is correct in Siit without waiting a week. ### Common workflows **Access request.** *Trigger: Request submitted (service = "Request group access"). Actions: manager approval → JumpCloud add to group → DM requester.* **Password reset (self-service).** *Trigger: Request submitted (service = "Reset password"). Actions: identity verification → JumpCloud generate temporary password → close request.* The step sends the password to the requester itself, so there is no message action to add after it. **MFA reset.** *Trigger: Request submitted (service = "Reset MFA"). Actions: manager approval → JumpCloud reset MFA → DM requester with re-enrollment instructions.* **Day-1 onboarding (with HRIS).** *Trigger: Start date. Actions: JumpCloud add to baseline groups → notify manager.* **Offboarding on end date.** *Trigger: End date. Actions: JumpCloud remove from all groups → suspend user → equipment pickup request.* ### IT Agent integration JumpCloud actions are available inside IT Agent playbooks via slash commands: * `/jumpcloud add to group` * `/jumpcloud generate temporary password` * `/jumpcloud reset user mfa` * `/jumpcloud fetch recovery key` See IT Agent for playbook examples. ### Troubleshooting **Connection fails with "invalid credentials".** The API key is wrong, revoked, or the admin owning it has been deactivated. Regenerate in JumpCloud and update in Siit. **Users missing from Siit.** Check whether suspended users are excluded (they are by default) and whether the admin's role has access to all user groups you expect. **Group not visible in the action picker.** It's likely scoped out. Review group scope in **Settings → Workspace → Integration library → JumpCloud**, or confirm the group exists in JumpCloud (User Group, not System Group). **Generate temporary password failed in a workflow.** The step sends the password to the requester itself, so it fails before JumpCloud is called when the request has no private channel to send through. People workflows have no request at all and do not offer the action. **Recovery Key isn't offered on a computer.** JumpCloud has no key escrowed for it, Siit doesn't hold that computer for the employee, or the JumpCloud system owner doesn't map to their account. Run a JumpCloud sync and check the device's owner. **Action fails in a workflow.** Open the workflow run in **Workflows → \[workflow] → Runs** — the JumpCloud error response is shown inline. Common causes: admin role lacks MFA management permission, or the user is already suspended. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.siit.io/integrations/iam/jumpcloud.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.