Roles and permissions

Knock uses an account-level roles model, where a given account member's role determines what they'll be able to do in your account.

You set an account member's role when you invite them to the Knock dashboard. You can update their role on the Members page under the Admin section of your account settings. Learn more in our managing members documentation.

Knock provides a set of built-in roles for common team functions.

Here's an overview of the built-in roles available to Knock account members:

• Owner. For your primary admin who manages billing. This role can invite and manage members, manage billing, and do anything available in the admin role. Your account must always have at least one account owner.
• Admin. For admins who need to manage account-level settings. This role can invite and manage members (excluding owner and billing roles), manage account branding, manage environments and channels, and manage advanced developer concepts such as signing keys, enhanced security mode, variables, and webhooks. This role has all permissions available to the member role.
• Member. For users who are editing notification workflows and templates in Knock. This role can manage workflows, guides, broadcasts, and other content, as well as users, objects, and tenants. It can commit and promote changes to subsequent environments, and has full access to message and API logs for debugging.
• Production-only member. Available when production write access is enabled in your account settings. For team members who should only work in production (such as lifecycle marketers managing in-app announcements). This role has the same permissions as the member role, but only has access to the production environment.
• Support. For users who should be able to view workflows and content and dig into message and API logs for debugging, but shouldn't be able to make changes.
• Billing. For account members who shouldn't have access to anything in Knock but billing.

For a complete overview of which permissions are available to which built-in roles, see the lookup table below.

Custom permission groups enable you to define your own roles with specific capabilities. Create and manage them under Settings > Permissions.

When you create a permission group, you set a unique key (lowercase letters, numbers, underscores, and hyphens). The key cannot be changed after creation. Directory sync uses this key to map identity provider groups to the permission group.

When you create a permission group, you choose which capabilities members in that group receive. Capabilities fall into two scopes:

• Account. Settings and resources that apply across the whole account, such as members, billing, integrations, and API keys.
• Environment. Resources that live in an environment, such as workflows, guides, content, broadcasts, audiences, recipient data, observability, and release management.

Most capabilities support none, view, and manage. Release management uses a different set of levels:

• None. No commit or promotion access in that environment.
• Commit. Commit changes in that environment.
• Manage. Commit and promote changes between environments.

For environment-scoped capabilities, you control both what members can do and which environments they can access:

1. Same access in every environment. Apply one set of environment capabilities across development, production, and any additional environments.
2. Per-environment access. Use granular mode to set different capability levels in each environment. For example, grant manage access to workflows in development, and view-only access in production.
3. No access to an environment. Deny an environment to hide it from members in the group and block all environment-scoped permissions there, including on its branches. Account-level capabilities still apply. At least one environment must remain accessible.

Custom permission groups can enable customer data obfuscation under environment access. When enabled, all message, user, and object data will be obfuscated in the Knock dashboard for members of that group.

You set the rule in the same all or granular mode you use for environment capabilities:

1. Same access in every environment. Enable obfuscation once to apply it across every environment.
2. Per-environment access. Use granular mode to enable obfuscation in specific environments.

A group's rule for a parent environment also applies to that environment's branches.

If a member belongs to more than one custom permission group, Knock hides customer data when any assigned group enables obfuscation for that environment.

If customer data obfuscation has been enabled at the environment level, that setting applies to every member and cannot be overridden by a permission group. Built-in roles have no per-role obfuscation setting. Only the environment setting applies to them.

You assign custom permission groups when you invite a member or change their role. You can also add members from a permission group's detail page, or assign groups through directory sync.

• Choose either a built-in role or one or more custom permission groups. You cannot combine a built-in role with custom groups on the same member.
• When you assign custom groups, the member's role becomes Custom. Their effective permissions are the union of every assigned group.
• An environment is accessible to a custom member if any of their assigned groups grants access to it.
• When directory sync is enabled, Knock uses your identity provider as the source of truth for synced users. If a synced user belongs to any group that maps to a live custom permission group, that custom assignment replaces their built-in role, including owner and admin.

Archiving a custom permission group removes its grants from any members who had it assigned. If that was their only group, they keep the Custom role and have no permissions until you assign another group or a built-in role. Knock does not fall back to the support role.

For directory-synced users, Knock recomputes the assignment when you archive a mapped group. Those users fall back to their highest-privilege mapped built-in role, or to support if none is mapped.