Name: managing-users
Author: celigo

Manage Celigo account users -- inviting users, updating permissions, configuring access levels (administrator, manage, monitor, integration-only), enforcing MFA/SSO, and disabling accounts. Use when adding team members, changing permissions, auditing access, or managing user lifecycle.

<! TIER:1 Managing Users A user (internally called an "ashare") represents a person's access grant to a Celigo account, defining what they can see and do. Concerns when managing users: Access strategy choosing between account wide access (administrator, manage, monitor) and per integration access for least privilege control Integration level permissions granting manage or monitor access to specific integrations, optionally combined with account wide monitor as a baseline Security enforcement requiring MFA or SSO per user to meet compliance requirements Feature flags whether monitor level and integration level users can edit retry data or create integrations Lifecycle inviting, disabling, and removing users as team composition changes Users are an account administration concern, not a flow or integration resource. Access Strategies There are four strategies for granting access. Choose based on the principle of least privilege. Administrator Full account administration. Can edit all resources, manage users, and change account settings. Cannot transfer ownership or manage owner permissions. Manage (Account Wide) Can edit all integrations and resources. Cannot view or edit account settings or manage other users, and can invite users only while the account's invite policy lets every user invite (an account setting, changed in the UI). Monitor (Account Wide) Read only plus operational access. Can view all integrations, run flows, and troubleshoot errors (retry/resolve). Cannot modify configurations, enable/disable flows, view connections, or see account API tokens. Optionally grant allowToEditRetryData so monitor users can edit retry payloads. Integration Only (Custom) No account wide accessLevel . Access is granted per integration via integrationAccessLevel[] , each entry specifying an integration ID and either monitor or manage . The user sees only the integrations they are granted. For access to specific integrations only, omit accessLevel entirely . Any account wide value, monitor included, shows the user every integration in the account, including ones created later, so adding one next to the per integration grants widens access instead of limiting it. A common hybrid pattern, for a user who should see everything: set accessLevel: monitor for baseline read only access across all integrations, then use integrationAccessLevel to grant manage for specific integrations the user owns. Effective Permissions A user's effective permissions are the union of both fields. On any integration granted by both, the higher level wins ( manage over monitor ). Account wide accessLevel also covers every integration created later, whereas integrationAccessLevel[] applies only to the integrations explicitly listed and must be extended by hand as new integrations are added. In the UI these composed shapes surface as Monitor all (account wide monitor ), Manage all (account wide manage ), and Custom (per integration only). Manage vs Monitor: Exact Allowances The same two levels apply at both the account wide and per integration scopes. On the integrations each covers: Manage create, view, modify, and delete the integration's resources (connections, flows, exports, imports, APIs, Tools, scripts, lookup caches) and troubleshoot errors (retry, resolve, edit retry data, view error history). Cannot view or edit account wide settings. Monitor view resources (read only on configuration), run flows on demand, and retry/resolve errored records. By default cannot edit the retry data payload being retried (grant allowToEditRetryData to allow it), cannot modify resource definitions, cannot enable/disable flows, and cannot change settings. Manage and monitor users can't see or create account (service) tokens, but each can create and manage their own personal access tokens, which carry exactly their own permissions (see [managing api tokens](../managing api tokens/SKILL.md personal access tokens pats vs account api tokens)). Quick Reference Access Strategy Decision Matrix User needs to... Strategy accessLevel integrationAccessLevel Administer the account, manage users Administrator administrator omit Edit all integrations, no account admin Manage manage omit View all, run/retry flows, no edits Monitor monitor omit View all + manage specific integrations Monitor + selective manage monitor [{ integrationId, accessLevel: "manage"}] Access only specific integrations Integration only omit (any value shows every integration) [{ integrationId, accessLevel}] Minimum Required Fields Inviting a user requires at minimum: emails the addresses to invite (the only required field; email , one address, on the single invite route) One of: accessLevel or integrationAccessLevel (technically optional; omitting both creates a user with no access) Schema Index All schemas are in [references/schemas/](references/schemas/): Invite fields: [invite request.yml](references/schemas/invite request.yml) POST /v1/invite/multiple body ( emails[] ) Update fields: [request.yml](references/schemas/request.yml) PUT /v1/ashares/{id} body (accessLevel, integrationAccessLevel, MFA/SSO, feature flags) Response shape: [response.yml](references/schemas/response.yml) includes accepted , dismissed , lastSignIn , sharedWithUser embedded object Related Skills [troubleshooting flows Diagnostic Workflow](../troubleshooting flows/SKILL.md diagnostic workflow) users with monitor access troubleshoot errors here [building flows How to Build a Flow](../building flows/SKILL.md how to build a flow) understanding what manage vs monitor users can do with flows [building apis Quick Reference](../building apis/SKILL.md quick reference) API Management, which only the owner and administrators can open ( allowAccessToAPIM records an administrator's first visit) [managing network policies Where a Policy Applies](../managing network policies/SKILL.md where a policy applies) restrict where workspace users (and their personal access tokens) can sign in from, by IP [managing end users How Access Composes](../managing end users/SKILL.md how access composes) MCP end users: a separate record type with its own grants, groups and roles <! TIER:2 How to Manage Users 1. Audit current users Before inviting or changing permissions, understand the current state: Review accessLevel , integrationAccessLevel , accepted (pending invitations), disabled , and provisionedBy . The default list rows omit integrationAccessLevel , disabled , dismissed , and provisionedBy , so without fields all an integration only user looks like a user with no access. The account owner has no access record, so the list never shows them (the MCP server's list users adds the owner as a row with accessLevel: "owner" and no ashareId ). Count the owner too when reviewing who can administer the account. No invite, update, disable, or delete applies to the owner, and only the owner can hand the account to someone else a transfer the receiving user accepts, which neither the CLI nor the MCP server offers. 2. Decide the access strategy Use the [Access Strategy Decision Matrix]( access strategy decision matrix) to determine the right level. Key considerations: Start with the least privilege needed. Integration only access is safest for users who only work with specific integrations. Monitor + selective manage is the most common hybrid the user sees everything but can only edit their integrations. Administrator should be rare. Only for users who need to manage account settings and other users. 3. Invite a new user Use the invite command (there is no workspace users create : users join by invitation, or from the identity provider when the account provisions users through SCIM). The owner and administrators can invite; manage and monitor users can too while the account's invite policy lets every user invite. The invite body takes the same access fields as an update accessLevel , integrationAccessLevel , and accountMFARequired (the CLI's force mfa ) so put the MFA requirement in the invite itself: a follow up update has to resend the grants and the MFA flag, or it clears them (gotcha 2). The body for monitor access to one integration only, with MFA required, has no accessLevel at all: That's the body of the published invite route, POST /v1/invite/multiple , which the CLI sends. It answers 200 with one result per address, so read every result (see [Common Errors]( common errors)). The MCP server's manage user invites one address per call ( email ), with the same access fields in its body . 4. Update permissions for an existing user Before re levelling, disabling, or deleting a user, check provisionedBy . scim means the identity provider manages them: its next push overwrites accessLevel and the enabled state, so make durable changes (access level, deactivation) in the IdP and treat a change here as temporary. Integration level grants made here are never touched by SCIM. Use set for simple field changes or update for full replacement: allowAccessToAPIM isn't a setting an update changes: the platform sets it when an administrator first opens API Management, and only the owner and administrators can open it. 5. Disable or remove a user Disabling is preferred over deleting when you may need to restore access later. disable and enable call the PUT /v1/ashares/{id}/disable toggle, the only way to change disabled : the CLI refuses set <id disabled=… and names these commands, and a disabled field in an update body is accepted but not applied. <id is the access record id from workspace users list (the MCP server's ashareId ), not the person's user id, and only an accepted invitation can be disabled: a pending one is refused, and disabling a declined one answers 204 without changing anything (delete it, or reinvite it). For a user with provisionedBy: scim , disable them in the identity provider: its next push overwrites the enabled state set here. A user's personal access tokens follow the user record: disabling blocks them until the user is re enabled, and deleting the user revokes them. Account API tokens stay valid whoever created them, and any administrator can reveal their values, so when an administrator leaves, rotate the ones they could have copied ([managing api tokens](../managing api tokens/SKILL.md personal access tokens pats vs account api tokens)). Workspace users aren't the only people with access. MCP end users have their own access records, listed separately ( celigo end users list ), and disabling or deleting a workspace user changes only the workspace record. When offboarding someone, check both lists an end user record shows hasWorkspaceShare: true when the person also has a workspace record and revoke the end user record too if their access should end ( celigo end users revoke <ashareId ; see [managing end users 8. Suspend, revoke, or offboard](../managing end users/SKILL.md 8 suspend revoke or offboard)). Celigo Support Access Separate from inviting people, an account can let Celigo's own support staff sign in to troubleshoot. This appears on the Users page as a single built in Celigo Support row ( support access@celigo.com ), disabled by default, that an administrator enables like a toggle. It is a distinct resource from a user : under the hood it is a support share , not an ashare, and there is exactly one per account (no per person records). It is never invited or listed alongside the other users, and it is managed only in the UI: on that row, an administrator turns it on, changes its scope or expiry, and turns it off. API tokens can't reach it and neither the CLI nor