> This page is for Workforce. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.merge.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server. # Team and roles > How to invite dashboard members, what each built-in role grants, how to build a custom role, and which permission gates which surface. This page is about dashboard access for the people who administer Workforce: your IT, security, and platform admins. It is not employee tool access, which resolves separately and lives in [Groups and access](/merge-workforce/provisioning/groups). Every member holds exactly one role, and a role is a flat set of permissions with no inheritance between them. Five built-in roles cover most teams; custom roles cover the rest. > **Only Admin reaches the Workforce console** > > Signing in to the Workforce console needs **Manage workforce** or **View workforce**, and among the built-in roles only **Admin** carries either. Developer, Security, and Read-only can sign in to the Agent Handler console but not this one. To give someone narrower Workforce access, build a custom role that includes one of those two permissions. ## Inviting a member From [Settings → Organization](https://wf-develop.merge.dev/settings/organization), click **Invite team member**, enter their email, pick a role, and click **Send invitation**. They get a link that lands them in the dashboard with the role you assigned. Inviting requires the **Manage users** permission. Invitations expire after 7 days. The **Pending** tab beside **Members** lists the ones outstanding, badges an expired one, and carries **Edit invite**, **Resend invite**, and **Cancel invite** on each row. If your organization requires SSO or runs SCIM, members arrive through your identity provider instead. See [Single sign-on](/merge-workforce/provisioning/sso) and [SCIM provisioning](/merge-workforce/provisioning/scim). ## Built-in roles The built-in roles cannot be edited or deleted, so the baseline stays predictable. To grant a slightly different set, create a custom role. | Role | Intended for | What it grants | | ------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | Org owners and senior platform engineers | Every permission, including billing, API keys, roles, Workforce, and SSO or SCIM configuration | | **Developer** | Engineers running the day-to-day configuration | Manage Connectors, Tool Packs, security rules, security alerts, webhooks, and workflows. View API keys, credentials, skills, logs, and the Audit trail. No member, role, billing, Workforce, or SCIM management | | **Security** | Security and compliance owners | Manage security rules, alerts, users, roles, credentials, API keys, and SCIM. Read-only on Connectors, Tool Packs, skills, and logs. No billing or Workforce management | | **Read-only** | Auditors, support, executives | The view permissions, no writes. Not the Playground, billing, or Workforce | | **Non-Admin** | Employees who only manage their own access | Their own connections, credentials, skills, logs, alerts, and tool access requests, plus the tool catalog. Nothing organization-wide | ## Which permission gates which surface Permission checks are enforced on the server and mirrored in the dashboard: a control you cannot use renders disabled, with a tooltip naming the access you are missing. The gates worth knowing: | To do this | You need | | -------------------------------------------------------- | --------------------------------------------- | | Sign in to the Workforce console at all | Manage workforce, or View workforce | | Configure SSO | Manage users | | Generate a SCIM token, and set default or Group access | Manage users, or Manage SCIM | | Grant a Connector or Tool Pack to a Group or an employee | Manage users, or Manage SCIM | | Set a Group's routing policy, approved models, or budget | Manage workforce | | Create, rotate, or revoke API keys | Manage organization API keys | | Create or edit a custom role | Manage roles | | Edit security rules and resolve violations | Manage security rules, Manage security alerts | | Read tool call logs and the Audit trail | View logs, View audit trail | Permission names read as they appear in the dashboard. Never the all-caps codename. ## Picking the right split * **Small team.** Everyone is Admin. Move people off Admin once someone owns security or billing * **Separated security.** Platform engineers as Developer, the security or compliance lead as Security, leads as Admin. The most common pattern, with the caveat that only the Admins reach the Workforce console * **Large organization.** Add custom roles for your own shapes: a Workforce reader who holds View workforce and nothing else, or a Connector owner who cannot touch routing Do not default everyone to Admin. Admin can rotate API keys and disable other members, both disruptive to recover from. ## Custom roles Open [Settings → Roles](https://wf-develop.merge.dev/settings/roles) and click **Add custom role**. The form lives inside the permission matrix itself: a new editable column appears at the right edge, you name the role above it, then toggle permissions row by row and save. Four rules apply: * Role names are unique within an organization, so reusing a name fails * A role needs a name and at least one permission checked. Save does nothing until both are true * Built-in roles render as read-only columns and cannot be edited or deleted * A role with members assigned cannot be deleted. Reassign those members first Creating a role changes nothing for existing members. Assign it from the member's row in Settings → Organization. ## When members leave From the member's row in Settings → Organization, open the overflow menu and click **Disable account**. They are logged out and cannot sign in until someone re-enables them, which is the reverse action on the same menu. Nothing is deleted, so their Audit trail history stays readable. Members provisioned through your identity provider have no **Disable account** action here: deprovision them in the IdP and let [SCIM](/merge-workforce/provisioning/scim) carry it through. Their role can still be changed from the row. In regulated environments, change their role to **Read-only** first, using the role dropdown in their row, let the change land in the [Audit trail](/merge-workforce/logs/audit-trail), then disable the account a few days later. Nothing stops you disabling your organization's last Admin, so promote a replacement before you do. Every invitation, role change, and account disable is recorded in the Audit trail, with a field-level diff on role edits, which is what answers "who granted this person Admin, and when." ## Next Authenticate your admins through your identity provider with [Single sign-on](/merge-workforce/provisioning/sso).