Add teammates and assign roles

← Administer

Organization membership and Workspace membership are separate choices. Workspace roles determine what members can do. A colleague can belong to your organization without being able to enter a workspace.

Create an organization

Select New Organization on the Workspaces page or in the workspace switcher, enter an Organization name, and select Create Organization. Every organization supports Members and Workspaces, including an organization with only one member. A Free user can be an Admin of up to five organizations, including the first organization created at signup. Someone who signs up by accepting an invitation joins the inviting organization instead and doesn’t get an organization of their own; they can create one later with New Organization.

Create a workspace for your team

As an Organization Admin, open Workspaces in the organization’s settings and select New Workspace. Enter Workspace name, select a member as Initial Owner, and select Create Workspace. The initial Owner receives direct membership and all Workspace role permissions. Confirm the new workspace appears before adding colleagues.

Bring a colleague into the workspace

1. As an Organization Admin, open Organization settings, then Members. Select Invite people and enter the colleague’s Email.
2. Optionally, under Workspace access, select Add workspace, choose the Workspace and a role, and select Add. Repeat for each workspace. The default role is Explorer. Then select Send invitation.
3. Have the colleague follow the invitation and sign in with the Google account matching that email. If they’re signed in with a different account, the invitation page offers Choose another Google account. The invitation shows the organization, who invited them, any workspace access, and when it expires. An invitation is not complete until they select Accept invitation; accepting adds the workspace access at the same time.
4. If you didn’t attach workspace access, select the colleague’s row in Members. In the member sheet’s Workspace access section, select Add to Workspace, choose the Workspace and a role, and select Add to Workspace to save.
5. Confirm the person appears in the workspace roster and can open the workspace.

A Workspace Owner can also open the Workspace’s Members screen, select Add member, choose the Organization member and a role, and select Add member to save.

If an invitation expired, select Resend and have the recipient use the new email; the workspace access you attached stays with it. If a workspace you attached is no longer in the organization when they accept, or the person who sent the invitation is no longer an Organization Admin, that access is skipped and the invitation page tells them; they still join the organization. If the person is missing from the workspace candidate list, confirm they accepted the invitation and belong to the correct organization.

Assign Workspace roles

As an Organization Admin, open Organization settings, then Members, and select the member’s row. Under Workspace access, select Change beside the Workspace, choose a direct role, and select Save role:

Role	Allows the member to
Viewer	Read Pages, including the results of dashboards added to Pages, and change a dashboard’s input controls there
Explorer	Run queries as the Workspace’s connection account, read internal resources, create Dashboards and Pages, and refresh Catalog metadata
Editor	Also edit Semantic definitions, Time Spine settings, and Catalog selections
Owner	Also manage Connectors, credentials, members, roles, and settings

Roles are cumulative. Your effective Workspace role is your direct role. A Workspace must retain at least one person with the direct Owner role.

Before assigning Explorer or higher, confirm that each Connector uses a dedicated read-only warehouse account. Explorers and their Agents can modify data if that account has write permissions. Monomer does not guarantee read-only access. Ask your warehouse administrator to deny procedure, pass-through, and remote/external function privileges using the warehouse-specific guidance.

Remove access

To remove someone from a single Workspace, an Organization Admin can select them in Organization settings → Members and choose Remove next to that Workspace under Workspace access; Workspace Owners can do the same in the Workspace’s Settings → Members. Before removing a departing Owner, give another workspace member Owner responsibility. As an Organization Admin, select the departing person in Organization settings → Members, then select Remove from Organization. The confirmation names the Workspaces they will lose and explains that apps they connected can no longer reach the Organization. To bring them back, send a new invitation. Check affected Workspaces after the change. Do not share an existing user’s agent login or connector credentials to transfer responsibilities.

Manage team access with an agent

Start with monomer_list using {"path":"organizations"} and choose the intended organizationId from its organizations results. Then call monomer_read using {"organizationId":"<organization-id>","path":"organization"}. Every Organization request includes this explicit organizationId and omits workspaceId; the connection does not select an Organization. An Organization Admin can list organization/members and list and create organization/invitations. Organization resource lists require limit from 1 to 100; the organizations discovery call accepts only path. Use the returned nextCursor with the same path to continue.

Follow the Organization root’s availableOperations to list invitations, and send the advertised ORGANIZATION_INVITATION_CREATE entry to monomer_describe before constructing the input. After confirming the recipient with the user, call monomer_create:

monomer_create input

{"organizationId":"01942b04-6e00-7000-8000-000000000003","path":"organization/invitations","input":{"kind":"ORGANIZATION_INVITATION_CREATE","email":"teammate@example.com","workspaceAccess":[{"workspaceId":"01942b04-6e00-7000-8000-000000000004","role":"EXPLORER"}]}}

workspaceAccess is optional. Each entry names a Workspace in the same Organization once, with VIEWER, EXPLORER, EDITOR, or OWNER, up to 20 entries; anything else is rejected with INVALID_WORKSPACE_ACCESS. The access is granted when the recipient accepts.

Replace the example Organization ID with the discovered ID. Read the returned invitation path with the same organizationId to check its current state. The recipient must accept in the browser with the matching Google account. Agents cannot accept or decline on their behalf. To resend or cancel, call monomer_invoke on that exact invitation path with the same organizationId, with action set to resend or cancel and omit input. Resending replaces the previous invitation link.

Next, call monomer_list with {"path":"workspaces"}, select a returned Workspace, and read workspace with its workspaceId. Follow availableOperations to read workspace/access and list members; each listed member includes their direct role. A Workspace Owner can list workspace/member-candidates, add an Organization member, and read workspace/authorization to inspect current assignments. Describe the advertised add-member entry before constructing its input, then call monomer_invoke. Replace example IDs with IDs returned by discovery:

monomer_invoke input

{"workspaceId":"01942b04-6e00-7000-8000-000000000001","path":"workspace/members","action":"add-member","input":{"kind":"WORKSPACE_MEMBER_ADD","userId":"01942b04-6e00-7000-8000-000000000002","role":"EXPLORER"}}

Adding an existing member with the same role is a no-op. A different role returns 409 WORKSPACE_MEMBER_ROLE_CONFLICT; follow the set-role action in nextActions.

Read the returned member path to confirm the role and discover its set-role entry. Pass that entry to monomer_describe before constructing the input, then call monomer_invoke after confirming the person and role:

monomer_invoke input

{"workspaceId":"01942b04-6e00-7000-8000-000000000001","path":"workspace/members/01942b04-6e00-7000-8000-000000000002","action":"set-role","input":{"kind":"WORKSPACE_MEMBER_ROLE","role":"EDITOR"}}

An Organization Admin can manage roles without joining the Workspace. List organization/workspaces with organizationId and limit, then list the returned organization/workspaces/{workspaceId}/members collection to see each member’s direct role. Read the member and describe its advertised set-role entry; the same input kind also exists on Workspace paths, so copy the exact entry for this path. Invoke set-role on organization/workspaces/{workspaceId}/members/{userId} with the same organizationId and WORKSPACE_MEMBER_ROLE input. Omit workspaceId from this Organization request. Read the returned member path to confirm the change.

An Organization Admin can also remove a direct member from any Workspace in the Organization: follow the member’s advertised remove-member entry and invoke it on organization/workspaces/{workspaceId}/members/{userId} with the same organizationId and no input. The result references the organization/workspaces/{workspaceId}/members collection; confirm it with monomer_list and the required limit.

Organization Admins can change any existing member’s direct role. Assigning any role (VIEWER, EXPLORER, EDITOR, or OWNER) also adds a same-Organization user who is not yet a Workspace member, with that role. Users outside the Organization are rejected with 409. The last personal Owner cannot be demoted. The Workspace-scoped workspace/members/{userId} action still requires Workspace Owner access.

Organization roles remain a separate Organization administration responsibility.

To remove membership, invoke remove-member on workspace/members/{userId} without input. Removing yourself immediately ends your Workspace access; a subsequent roster 404 is expected and is not a failed removal. The last personal Owner cannot be removed or demoted, including by an Organization Admin.

These actions apply immediately and use the latest accepted value; they do not take expectedRevision. Before changing invitations, membership, or permissions, confirm the target and intended effect with the user. After a lost response, read the current resource before repeating a mutation. A delivery 503 with retryable:false can mean the invitation was saved but email delivery failed: inspect the invitation and explicitly resend. Respect Retry-After on 429 responses.

For REST, send the same JSON without organizationId to POST /v2/agent/organizations/{organizationId}/{list|read|create|invoke} for Organization paths, or POST /v2/workspaces/{workspaceId}/agent/{list|read|invoke} for these Workspace paths, omitting workspaceId from the body. Discover either target through POST /v2/agent/list with only {"path":"organizations"} or {"path":"workspaces"}. Use a REST-audience OAuth token and Content-Type: application/json; MCP tokens have a different audience.