Workspace management
Manage people, integrations, write controls and usage across a workspace
A workspace is the shared boundary for people, projects, plugin installations, data endpoints and administrative settings. Projects organize pipelines, ontology, queries and predictions within that boundary. An endpoint used by two projects is still one workspace resource; granting a project does not create a private copy of it.
You need a Semogram account with access to the workspace. Owners and administrators manage most workspace settings; Company SSO, workspace renaming and workspace deletion require an owner. API-key administration uses the workspace-wide org:manage scope.
What you manage
| Area | Controls | Guide |
|---|---|---|
| Workspace identity | Name, slug, projects and shared resources | Workspace and projects |
| People | Existing membership, roles and explicit grants | Members and roles |
| Company sign-in | Verified domain, SAML connection and allowed employees | Company SSO |
| Service access | API scopes, project allowlist, workspace resources, expiry and revocation | API keys |
| Data reads | Named grants required by ontology read bindings | Read permissions |
| Data changes | Policy revisions, approval, binding and actor permissions | Write policies |
| Consumer interfaces | SPARQL mode and governed source-write mode | Consumer access |
| Traffic and spending | Request windows, usage charges and budget alerts | Limits, Usage |
| Investigation | Query history, operation charges and decision history | Activity |
Access has several layers
A person authenticates with an account; a service authenticates with an API key. Authentication identifies the caller. Authorization then checks the applicable workspace role or operation scope, project/resource boundary and data-specific grants. Writes also need usable policies and supported connector semantics.
For example, a service can have queries:execute for the Maintenance project but still be unable to read an equipment binding that requires maintenance:read. Adding that named grant does not give it permission to edit queries. Selecting Maintenance alone also does not allow it to administer shared plugin installations.
Do not use Full access as a substitute for diagnosing the missing layer. Start with the exact failed operation and resource, then inspect the corresponding controls.
First administration task
Create a dedicated read integration for Maintenance. Select only that project, choose the scopes for its published query, add the actual binding grant and leave unrelated write/manage scopes off. Verify an allowed read and a denied out-of-scope read using a bounded fixture. Retain the key ID and service name; store the one-time secret in your service's secret manager.
The API key guide walks through this complete example. The access model explains each decision layer before you change permissions.