On Belay

Functional groups & permissions

Groups are how you point Claude. They decide what Claude knows about each team, and which tools each person can reach through it. Set a group up once, and everyone in it inherits the same context and the same guardrails on every session.

What a functional group is

A functional group is a named team unit — "Marketing," "Engineering," "Finance" — that bundles everything Claude needs to work well for that team in one place:

  • Strategy — the team's goals and priorities, so Claude's work pulls in the right direction.
  • Claude role — how Claude should behave for this group (its voice, focus, and ground rules).
  • People Guidelines — guidance the people in the group should follow when working with Claude.
  • Integration access — which integrations, and which specific operations, Claude can use on the group's behalf.
  • Members — the people who inherit all of the above when they use Claude.

A person can belong to more than one group. When Claude calls get_my_context, On Belay merges the context from every group that person is in. To understand how groups sit alongside the rest of the model, see core concepts.

Create a group

  1. Go to Dashboard → Groups.
  2. Click New group.
  3. Enter a name and an optional description. The name is how Claude refers to the group — keep it clear and consistent.
  4. Click Create. The group editor opens.

The five editor tabs

The group editor has five tabs. Each one feeds Claude a different layer of context, except Permissions, which sets guardrails.

| Tab | What it controls | |-----|------------------| | Strategy | The team's goals and priorities. Returned to Claude as part of the group's context. | | Claude Role | How Claude should behave for this group — its focus, tone, and operating instructions. | | People Guidelines | Guidance for the humans in the group: how to work with Claude, what to check, what to avoid. | | Permissions | Which integrations the group can use and which operations are allowed. Admin-only. | | Members | The people in the group. |

Strategy, Claude Role, and People Guidelines are returned to Claude through get_my_context (for the signed-in person) and get_group_context (for a named group). Edit them whenever the team's direction changes — the new context is picked up on the next tool call. No session restart needed.

Assign integrations

Integrations are connected at the org level first, then granted to the groups that need them.

  1. An admin connects the integration once at Dashboard → Integrations.
  2. In the group's Permissions tab, add that integration to the group.
  3. Choose which operations the group is allowed to use.

Two groups can have completely different access to the same connected integration. Marketing might get read-only Shopify; Operations might get more. Connecting an integration to the org does not, on its own, expose it to anyone — access flows to people only through group grants. See integrations for the full picture.

Grant only what a group needs. Minimal access is easier to audit and limits the blast radius if a credential is ever compromised.

Set operation permissions

Permissions are not broad "read / write / admin" tiers. Each integration is granted to a group as an allowlist of individual operations — the specific named API actions Claude may call. An operation is a single action like "list orders," "get a contact," or "create a deal."

For example, Shopify granted to a Marketing group might allow:

  • list_orders — allowed
  • list_products — allowed
  • update_product — not on the allowlist

The allowlist only restricts when the group is in enforce mode. Every group/integration grant has an enforcement mode:

  • Passthrough (the default) — the allowlist does not gate operations. Claude can call any operation the integration supports. Use this when you trust the group with the full integration and just want it connected.
  • Enforce — the allowlist is the boundary. Any operation not explicitly allowed is rejected by the proxy, and Claude is never offered a way to call it.

This distinction matters: an allowlist sitting in a passthrough group does not block anything. Switch the group to enforce mode when you want the allowlist to be the rule. Operations surface to Claude through list_my_integrations, so in enforce mode it only ever sees what you've permitted.

Tip: The simplest way to keep a group read-only on an integration is to set enforce mode and leave write or destructive operations off the allowlist.

Add members

Open the group's Members tab and add people by name or email.

  • Membership takes effect on the next tool call — Claude picks up the new context immediately, no re-login.
  • Removing a member revokes their access to that group's Claude role and integrations right away.
  • People can belong to multiple groups; their combined context is merged when Claude calls get_my_context.

Inviting people, changing org roles, and setting up non-human principals (Service Identities) are all done from Dashboard → People.