Users, Roles, and Permissions
User access in FactVerse is layered. A user first needs an authenticated account, then tenant or project membership, then the product and data permissions required for the job. This model keeps onboarding practical while giving administrators a clear way to separate view, edit, approval, integration, and administration responsibilities.
Use this page when creating access request packages, reviewing role assignments, or diagnosing why a signed-in user cannot see a product area.
Prerequisites
The user should already have an active account and a confirmed sign-in method. Resolve login or SSO issues before changing product permissions. Confirm tenant or project membership before adjusting product roles.
Access layers
Access request package
When requesting access for a user, include the business context rather than only asking for "admin" or "full access".
Inputs
| Field | Example |
|---|---|
| User identity | Name, email, department, and enterprise identity if different. |
| Tenant or project | Customer tenant, site, project, or deployment environment. |
| Business role | Inspector, maintenance planner, data steward, document owner, field technician, IT administrator, or integration owner. |
| Required products | Inspector, DFS, ECM, Designer, AI Agent, MCP, product client, or reporting area. |
| Required tasks | View assets, upload documents, approve workflows, configure connectors, manage users, create API keys. |
| Duration | Permanent operating role, project period, temporary support window, or break-glass access. |
| Approver | Tenant administrator, project owner, business process owner, or customer IT owner. |
Typical role patterns
| Role | Access pattern |
|---|---|
| Viewer | Read-only access to approved product areas and data scopes. |
| Operator | Daily task access such as inspection execution, document upload, connector monitoring, or workflow review. |
| Editor | Create or modify assets, documents, mappings, workflows, or reports within an assigned scope. |
| Approver | Review and approve content, data changes, maintenance decisions, or compliance packages. |
| Administrator | Manage users, packages, product configuration, and tenant-level settings. Keep this role limited. |
| Integration owner | Manage API keys, service identities, connector credentials, and integration handoff records. |
Product-specific permissions
Authentication and tenant membership are shared, but fine-grained permissions are product-specific.
| Product area | Permission examples |
|---|---|
| Inspector | Asset visibility, inspection route access, work-order access, maintenance record visibility, and field action permissions. |
| DFS | Connector setup, mapping changes, dataset lifecycle, review queues, BI report design, and audit metrics. |
| ECM | Folder access, document classification, upload, versioning, workflow approval, download, and retention actions. |
| AI Agent | Workflow run access, approved action scope, data retrieval scope, validation handoff, and service identity scope. |
| MCP | Endpoint slice, API key scope, read/compute/action boundaries, and tool discovery result. |
Review checklist
- The user can sign in through the configured method.
- Tenant or project membership is correct.
- Product navigation shows only the areas needed for the role.
- Product task permissions match the access request package.
- Sensitive actions such as deletion, approval, export, and API key creation are granted only with explicit approval.
- Temporary access has an expiry owner and review date.
- Access changes are traceable through administrative or audit records.
When access should be changed
Review access when a user changes project, role, employer, or support responsibility. Review also when a product package is added, a new integration goes live, a tenant moves from pilot to production, or a compliance owner asks for evidence of least-privilege operation.
Troubleshooting access gaps
| Symptom | Check |
|---|---|
| User can sign in but sees no tenant | Tenant membership, project membership, and environment URL. |
| Product navigation is hidden | Role package, product entitlement, navigation permission, and project scope. |
| Product opens but a task is blocked | Product-specific permission, object scope, folder rule, dataset scope, or workflow role. |
| User has too much access | Remove broad administrative roles, split temporary support access, and record the new approval. |
| Access change does not take effect | Session refresh, client cache, role propagation, and whether the change was made in the correct environment. |
Related pages
- Use Sign in to FactVerse before diagnosing permissions.
- Use Service Accounts and API Keys for non-human access.
- Use product pages such as DFS Permissions and ECM Permissions and Governance for product-specific details.