Members & Access

Members & Access

Spaces let you control who can see and use specific sets of tools. By managing space membership, you can ensure each team only sees the tools relevant to their work.

Understanding access

There are two layers to consider when setting up access:

LayerWhat it controlsWhere you set it
Space membershipCan the user see this space?Console → Space → Members
Schema permissionsCan the user run this action?@permission in your schema

Space membership determines visibility: whether someone can see the space and its tools in the console. Schema permissions determine authorization: whether someone can actually execute an action when they click the button.

⚠️

Being a space member doesn't automatically grant permission to run tools. A user might see a tool but get a permission denied error if your schema doesn't allow them access. See Permissions for details on @permission rules.

Who can access a space

There are two ways someone gains access to a space:

Project members

Anyone who is a member of your Keel project can access all spaces within that project. This is inherited access, so they don't need to be explicitly added to each space.

This keeps administration simple: your core team (developers, admins, ops leads) can see everything without managing individual space memberships.

Direct members

You can invite additional people to specific spaces by email. These direct members only have access to the spaces they've been invited to, not the entire project.

This is useful for:

  • External contractors who need access to specific tools
  • Team members who only need a subset of functionality
  • Temporary access for training or onboarding

Adding members

To invite someone to a space:

  1. Open the space in the console
  2. Click the Members button in the toolbar
  3. In the dialog, type an email address or select from existing project members
  4. Click Invite member

You can invite multiple people at once by typing or pasting comma-separated email addresses.

Invitations are sent by email. Until the recipient accepts, they appear in the members list with an Invited tag.

When selecting from existing project members, you're giving them direct membership in addition to their inherited access. This doesn't change their permissions, but it's useful for tracking who actively uses each space.

Removing members

To remove someone from a space:

  1. Open the space and click Members
  2. Find the person in the members list
  3. Click the remove button next to their name
  4. Confirm the removal

For pending invitations that haven't been accepted yet, you can cancel them the same way.

Note: You can only remove direct members from a space. Project members have inherited access that can't be revoked at the space level. To remove their access, you'd need to remove them from the project entirely.

Space access vs tool permissions

It's important to understand that space membership and tool permissions are independent:

  • Space membership controls the console UI: what spaces and tools appear in the sidebar
  • Tool permissions are enforced by your schema: the @permission rules you define on your models and actions

This means:

  1. A user can be a space member but still get "permission denied" when running certain tools (if your schema restricts access)
  2. Adding someone to a space doesn't grant them any data access beyond what your schema already allows
  3. Your schema's permission rules are always enforced, regardless of space membership

For details on configuring permissions, see the Permissions documentation.

Example: Warehouse team access

Let's say you have a warehouse space with tools for receiving goods, picking orders, and managing stock counts. Here's how to set up access for your warehouse team.

The scenario

Your warehouse staff need access to:

  • Receive goods and create goods receipts
  • View and confirm pick lists
  • Record stock counts

But they shouldn't see finance tools, customer data, or system configuration.

Setting up access

Step 1: Create the space

Create a "Warehouse Operations" space and add the relevant tools, organized into groups like "Receiving", "Picking", and "Stock Counts".

Step 2: Configure schema permissions

In your Keel schema, create a role for warehouse staff and grant them access to the relevant actions:

role WarehouseStaff {
  domains {
    "yourcompany.com"
  }
}
 
model GoodsReceipt {
  fields {
    reference Text
    receivedAt Timestamp
  }
 
  actions {
    create receiveGoods() with (reference)
    list listGoodsReceipts()
  }
 
  @permission(roles: [WarehouseStaff], actions: [create, list])
}

Step 3: Invite the team

Open the Warehouse Operations space, click Members, and invite your warehouse team members by email. They'll receive an invitation and can start using the space once they accept.

What happens

  • Warehouse staff see only the Warehouse Operations space (unless they're also project members)
  • When they click a tool, the schema checks if they have the WarehouseStaff role
  • If they try to access a tool that isn't covered by their role, they get a permission denied error
  • Finance and admin tools remain invisible to them (in other spaces they can't access)

For frontline staff who only need specific tools, inviting them directly to spaces (rather than making them project members) keeps the console focused and reduces accidental access to unrelated areas.

Troubleshooting

"I can see the space but can't run an action"

This means you have space access but lack the schema permission for that specific action. Check your @permission rules. You may need to add the appropriate role or expression. See Permissions.

"I invited someone but they can't see the space"

Make sure they:

  1. Accepted the email invitation
  2. Are signed into the console with the same email address you invited
  3. Are looking at the correct environment (spaces are environment-specific)

"I removed someone but they can still access the space"

If they're a project member, they have inherited access to all spaces. Removing them from a specific space only removes their direct membership. To fully revoke access, remove them from the project.