Team and roles

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.

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, 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 and SCIM provisioning.

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 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 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, 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.”

Authenticate your admins through your identity provider with Single sign-on.