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.

You can only grant operations On Belay knows about

The operations listed on the Permissions tab come from On Belay's operation catalog — the same catalog described in integrations. You pick from that list; there is no free-text field, so in normal use you cannot grant something that doesn't exist.

On Belay also checks the allowlist against the catalog when the grant is saved, and refuses to save if it names an operation the catalog doesn't have. You may see an error naming the operation. This is rare and usually means the page was left open while the catalog changed underneath it — reload the group and set the permissions again.

If an operation you need isn't in the list at all, that is not a permissions problem and reloading won't help: the operation isn't defined in the catalog yet, so it cannot be granted to anyone. Contact support with the integration and the action you're trying to allow, and we'll add it. Until then the group can use every other operation you've allowed on that integration.

Why the check exists: an allowlist entry that doesn't match a real operation looks like it grants something, but On Belay can't check the shape of a call it has no definition for. Refusing the save keeps what the Permissions tab shows you and what the proxy actually enforces from drifting apart.

Operation limits cover live calls, not cached data

For a few integrations, On Belay keeps a scheduled copy of some data so Claude can answer historical questions quickly without hitting the live API. Today that is Shopify, Klaviyo, HubSpot, Google Search Console, and Microsoft Clarity.

The operations you pick for a group control every live call that group makes. They do not narrow what it reads from the cached copy. Any group with one of those integrations turned on reads all of that integration's cached datasets, whatever operations you pick.

Turning the integration off for a group is the control that takes cached data away from that group.

The group's Permissions tab states this on each affected integration and lists the exact datasets involved. Dashboard → Cache shows everything On Belay currently keeps cached for your organization.

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.