Permissions

Every member of your organization has a role that controls what they can do. On hosted withHuman, you can also give members and teams custom permission policies.

Membership management covers invitations, suspension and removal. API keys covers access for scripts and shared integrations.

Roles

withHuman has four predefined roles. A role applies across the whole organization.

The Permission reference shows which permissions each role holds.

Changing a role

Open Members and choose Change role from a member's menu. The new role applies immediately. It replaces all of the member's direct permissions, including any custom permission policies. Access they get from their teams stays as it is.

Only an owner can make someone an owner. You can't change your own role. Directory-managed members get their access from your identity provider.

Custom permission policies

Custom permission policies are part of the hosted edition. In the open edition, the Permissions page says the deployment offers predefined roles only.

A policy has two parts: Permissions says what someone can do. Scope and Applies to say where. You can assign a policy to a member or a team.

Reading, editing and activating are separate permissions. For example, someone can edit an approval pipeline without being allowed to activate it.

Sensitive marks powerful permissions, such as granting access or deciding requests assigned to someone else. Changing these permissions may require you to sign in again.

flowchart TD
    actions["Permissions: what you can do"] --> policy["Permission policy"]
    scope["Scope and Applies to: where you can do it"] --> policy
    policy -->|Assigned directly| member["Member"]
    policy -->|Assigned to| team["Team"]
    team -->|Inherited by| roster["Every member of that team"]

The Permission reference lists every permission, what it allows and its available scopes.

Scope

Scope answers where the selected actions are allowed.

The available permissions depend on the scope. Managing escalation paths and creating new teams, agents or pipelines require Organization scope.

Assigning a policy to a team gives its members access. Choosing Teams as its scope controls which teams they can manage.

Example: A team that owns a pipeline

Our support team owns the Support pipeline. We'll give the team a policy with Pipelines scope, select Support in Applies to, and choose View approval pipelines, Edit approval pipelines and Activate approval pipelines. Everyone on the team can now change the Support pipeline's rules, but not the entry pipeline or any other pipeline.

Direct and inherited access

Members receive access directly, from their role and any custom policies, or through their teams. Their access combines both. Team permissions are part of the hosted edition.

Inherited from names the team that provides a permission. Changes to that team's policy affect all its members. People gain the team's permissions when they join and lose them when they leave. Team administration covers membership.

Removing a policy does not cancel access granted elsewhere. If their role, another team or a direct policy gives someone the same permission, they keep it.

Review access and routing

Reading, claiming and deciding requests are separate permissions. They use Organization scope. The Owner and Reviewer roles hold all three. Permission to manage an agent does not include permission to approve its requests, so admins can't decide requests.

Permission to approve or deny lets you decide requests assigned to you or your team. You don't need to wait for a notification.

flowchart TD
    access["You have approval permission"] --> decision["Together, these let you approve or deny"]
    assignment["The request is assigned to you or your team"] --> decision

The Review queue explains claims, adding reviewers and decisions.

Example: Refund reviewers

On hosted withHuman, we'll give our Payments review demo team permission to read, claim and decide requests. An escalation path assigns refund reviews to the team. We leave emergency decisions outside routing out of this policy.

Decisions outside routing

Decide requests that were routed to other people (break glass) lets you step in when a request is assigned to someone else. You still need permission to approve or deny.

withHuman asks you to confirm that you're deciding outside routing. It records this in Audit log.

Your organization's sign-in requirements still apply. Expired or finished requests cannot be decided.

When no escalation path applies, the rules in Organization policies allow either anyone with approval permission or only people with this emergency permission to decide the request.

Organization ownership

Ownership is the Owner role. Owners have full access, including decisions outside routing.

Only an owner can make someone an owner or change another owner's role. You cannot change your own role or direct permissions. The organization must always have at least one active owner.

Changes and access

Changing a role or saving or removing a policy changes access immediately, including for requests already waiting for a decision.

Viewing and changing policies require separate permissions. You can grant only access you already have, within a scope you can manage. The editor explains any restrictions.

Inherited permissions are changed on the team that provides them. Directory-managed memberships and policies are changed through your identity provider. Inactive members must be reactivated before their permissions can change. Archived teams are read-only.

On hosted withHuman, Audit log records role changes and policy additions, changes and removal.