Members & App Permissions
Keelson controls access to each app within the context of workspace membership. The groups with view permission determine which apps a member can use, while the groups with manage permission determine which apps a member can manage.
This page explains member management, roles, and the ways users can join a workspace.
How access control works
Section titled “How access control works”Keelson combines workspace membership with permissions assigned per app.
- Joining the workspace is a prerequisite for using an app.
- Only members of groups with view permission can use a running app.
- Members of groups with manage permission can deploy and configure that app.
- View and manage permissions are independent. Manage permission by itself does not allow a member to use the running app.
- A user who has not joined the workspace cannot access any of its apps.
When you create an app, view permission is assigned by default to the group containing all members. Manage permission is assigned by default to the developer group containing Owners, Admins, and Developers. You can change or remove these assignments independently for each app. No role, including Owner, bypasses the app permission check.
For the login flow, see Auth & Login.
A workspace has four member roles.
| Role | Workspace administration | Default app permissions | Developer seat |
|---|---|---|---|
| Owner | Can manage all roles and settings | View and manage | Used |
| Admin | Can manage members other than Owners and manage settings | View and manage | Used |
| Developer | Not available | View and manage | Used |
| App User | Not available | View | Not used |
The app permissions in this table are default assignments made when an app is created. Actual access and management capabilities depend on that app’s group assignments. No role bypasses the permission check.
Owners can add and remove members, change roles, and manage workspace settings. They still need view permission to use an app and manage permission to manage it. Every workspace must have at least one Owner.
Admins can manage the workspace but cannot manage members with the Owner role. They need the corresponding app permissions to use or manage each app. This role is appropriate for team administrators.
Developer
Section titled “Developer”The Developer role is intended for members who build and deploy apps. By default, Developers have view and manage permissions, so they can use the app and can deploy it, change its settings, and edit its secrets. They cannot manage members or groups, change workspace settings, or change public URLs. Removing a Developer’s view permission for an app prevents them from using that app; removing manage permission prevents them from performing management operations.
App User
Section titled “App User”By default, App Users can use apps for which they have view permission, but they are not assigned manage permission. Removing view permission prevents an App User from using that app. An App User must be assigned manage permission to manage an app. App Users cannot administer the workspace and do not consume a developer seat. This role is intended for an app’s end users.
Ways to join a workspace
Section titled “Ways to join a workspace”There are three ways to become a workspace member.
Invitation
Section titled “Invitation”An administrator invites a member by email address and selects a role. The user becomes a member after accepting the unique invitation link.
For step-by-step instructions, see Invite Members.
Join URL
Section titled “Join URL”If domain auto-join is enabled for a workspace, a user from an allowed domain becomes a member immediately after opening the workspace’s join URL. An administrator does not need to approve the user.
Join request from Discover
Section titled “Join request from Discover”A workspace with domain auto-join enabled appears in Discover. A user from an allowed domain can request to join from Discover and becomes a member after an administrator approves the request.
Domain join policies
Section titled “Domain join policies”A domain can use an invitation-only, auto-join, or approval-based join policy. In the console, you can register and remove domains. On the Team plan or higher, you can also enable or disable the join URL to switch between auto-join and invitation-only behavior. The current console does not provide an operation for selecting the approval-based policy.
You can register only the domain of your own email address, and that domain must also match the workspace creator’s email domain. The same domain can be configured for more than one workspace.
| Policy | Behavior | Plan requirement |
|---|---|---|
| Invitation only (default) | Only users invited by an administrator can join | None |
| Auto-join | Users from the domain can join through the join URL or request access through Discover | Team plan or higher |
| Approval-based | The join URL and Discover requests are unavailable; users join by administrator invitation | None |
Members who join through auto-join receive the App User role. Auto-join is not available for public email domains such as Gmail and Outlook.
Changing the join URL setting does not affect existing members.
Blocking members
Section titled “Blocking members”You can block a member who no longer needs access from the console.
- A blocked member can no longer use any app permissions assigned to them.
- Blocking disables access; it does not delete the member’s account.
- You cannot block the workspace’s last Owner.
- You cannot block yourself.
- A blocked member can be reactivated from the member list.
Use this when someone leaves the organization or changes responsibilities.
Troubleshooting access
Section titled “Troubleshooting access”Is the user a workspace member?
Section titled “Is the user a workspace member?”A user who is not a workspace member cannot access an app. Ask an administrator to invite them.
Is the member blocked?
Section titled “Is the member blocked?”A former active member may have been blocked. Check the member list in the console.
Is the user signed in with the correct account?
Section titled “Is the user signed in with the correct account?”If the user has multiple Google or Microsoft accounts, they may be signed in with an account that is not registered in the workspace.
Is a join request awaiting approval?
Section titled “Is a join request awaiting approval?”When a user requests access through Discover, they cannot access the workspace until an administrator approves the request.
Are IP restrictions blocking the request?
Section titled “Are IP restrictions blocking the request?”The problem may be a network restriction rather than workspace membership.
Frequently asked questions
Section titled “Frequently asked questions”Does joining a workspace grant access to every app?
Section titled “Does joining a workspace grant access to every app?”No. In addition to workspace membership, the user needs view permission through a group assigned to the app. Manage permission is a separate permission for deployment and configuration; it does not grant use of the running app. Default permissions can be changed independently for each app.
What is the difference between an App User and a Developer?
Section titled “What is the difference between an App User and a Developer?”By default, an App User can use apps for which view permission is assigned. A Developer has both view and manage permissions by default but cannot manage members or workspace settings. Both roles’ default app permissions can be changed for each app.
Can I change the role of a member who used auto-join?
Section titled “Can I change the role of a member who used auto-join?”Yes. Auto-join assigns the App User role, but an Owner or Admin can change the role from the console.
What happens when I block a member?
Section titled “What happens when I block a member?”All app permissions assigned to that member become ineffective immediately.
Related pages
Section titled “Related pages”- Auth & Login — Authentication and the login flow
- Invite Members — Invitation procedures
- IP Allowlist — Restrict access by IP address