Members and roles
Inspect workspace membership and manage explicit read and write permissions
Membership associates a person with a workspace. The current roles are Owner, Administrator and Member. Role, custom read grants and write-policy permissions are separate fields with different effects.
What you need
You need a Semogram account as a workspace owner or administrator to inspect/manage member grants. This page covers existing members. The Member permissions screen does not invite people, change roles or provide a project-specific member-role matrix.
| Role | Administrative behavior |
|---|---|
| Owner | Workspace management plus owner-only Company SSO, workspace renaming and deletion |
| Administrator | General management, including member grants, API access and pipeline recovery/schedules |
| Member | Workspace/project access with operation-specific permissions; explicit write grants may be required |
Company SSO can allow an employee to join as Member after sign-in. Company email alone does not grant membership. Removing an email from the SSO join list does not remove an existing member.
Example: grant equipment reads
Assume Maya already belongs to Factory operations as Member and a Maintenance ontology read binding requires maintenance:read.
Open Settings → Member permissions, find Maya, select Manage and inspect her existing Custom read grants. Add maintenance:read on its own line while preserving other grants she still needs. Select Save permissions. Test the equipment read as Maya.
The Write policy permissions area is separate. Grant only the write/policy actions needed for her task and use Save write permissions. These changes leave her role unchanged.
List current workspace members and find Maya's exact user ID, role and existing read/write permissions. Explain the Maintenance binding's required grant and prepare a proposed change preserving unrelated permissions. Do not claim that organization_member_list can update membership or roles.The exposed membership MCP operation is read-only. Apply the reviewed change in the UI or authorized API.
An org:manage key can inspect the existing record, then replace its grant list:
curl "https://platform.semogram.com/api/v1/members/<USER_UUID>/read-permissions" \
--header "Authorization: Bearer ${SEMOGRAM_ADMIN_KEY}"curl --request PUT "https://platform.semogram.com/api/v1/members/<USER_UUID>/read-permissions" \
--header "Authorization: Bearer ${SEMOGRAM_ADMIN_KEY}" \
--header "Content-Type: application/json" \
--data '{"readPermissions":["maintenance:read"]}'This replaces the full list. Include other retained grants when applicable; an empty list revokes all custom read grants. It does not change the role.
Call organization_member_list on the workspace MCP connection. Pass its next cursor as after until the desired member is found. Inspect the role/read/write fields. The operation requires org:manage and does not update them.
Write grants
The implemented explicit permissions are policy:read, policy:propose, policy:approve, policy:manage, data:write, data:delete and data:maintain. Owners/admins obtain those write-policy permissions through role; clearing their explicit list does not demote them.
For an existing Member, GET/PUT /api/v1/members/<USER_UUID>/write-permissions reads/replaces the explicit list using { "permissions": ["policy:read", "policy:propose"] }. It is separate from readPermissions. An authorized author can approve their own proposal when they also hold policy:approve; do not assume mandatory separation of duties.
Verify and review
Read back the full member record, test an allowed bounded read and test a binding the member should not access. Recheck affected integrations after grant changes. Use Company SSO for joining through the supported company flow; do not mistake join-list removal for membership revocation.