Permissions Reference
This reference describes the effective customer-facing permissions associated with Software Factory’s built-in project roles and custom-role module levels.
How to read this reference
- No Access grants nothing in the selected module.
- Viewer grants the actions listed in the Viewer column.
- Editor grants every Viewer action plus the actions in “Editor adds.”
- Owner is a built-in project role, not a module access level. Owner includes Editor and adds project administration.
A custom role with Viewer as its Base Project Access receives Viewer access across modules. Individual modules can be raised to Editor but cannot be lowered to No Access.
Modules available in the custom-role selector
Module | Viewer | Editor adds |
|---|---|---|
Automations | Read and execute existing automations | Create automations; update or delete automations created by that user |
Artifacts | Read, search, download, comment, suggest, resolve comments, upload and create artifacts | Update or rename, delete, create folders |
Requirements | Read, search, comment, suggest edits, resolve comments, export | Create, update, delete, manage categories |
Blueprints | Read, search, comment, suggest edits, resolve comments, export, view code links | Create, update, delete, manage categories, manage code links |
Skills | Read, search, comment, suggest edits, resolve comments, export | Create, update, delete |
Work Orders | Read, search, comment, suggest edits, resolve comments, export | Create, update, delete, assign, manage relationships |
Feedback | Read, search, comment, export, submit feedback | Create, update, delete, triage, link themes |
Codebase | Read and search code | Manage the repository connection; a custom Codebase Editor also receives reindex permission |
These eight rows are the current custom-role selector:
Automations, Artifacts, Requirements, Blueprints, Skills, Work Orders, Feedback, and Codebase.
Tests and project settings are not configurable module rows. A No Access-based custom role receives no access to them through a module override. A Viewer-based custom role receives the access included by its Viewer base, but cannot raise or lower those areas separately in the role builder.
Built-in access outside the custom-role selector
The following areas are not configurable rows in the custom-role selector. This table documents how the built-in project roles behave; it does not describe additional choices in the role builder.
Area | Built-in Viewer | Built-in Editor | Built-in Owner |
|---|---|---|---|
Tests | Read, search, comment, export | Viewer actions plus create, update, delete, run, and submit results | Same Tests actions as Editor |
Project settings | Read | Read | Read and update |
Hooks configuration | Read | Read and execute hooks | Read, execute, and update hooks |
Built-in project roles
Viewer
Project Viewer provides:
- Project shell access
- Project member-roster visibility
- Read access to project settings
- Viewer access across project modules
- Permission to list and create project API keys
- Permission to delete API keys created by that user
Viewer is primarily read-only, subject to the module exceptions in the table above.
Editor
Project Editor includes Viewer and adds:
- Normal create, update, delete, and module-management actions across project content
- Project editing and copying
- Work Order assignment and relationship management
- Blueprint code-link management
- Codebase connection management
- Hooks execution
- Automation creation
- Permission to update or delete automations created by that user
Project Editor does not include project-member management, project-settings updates, project archive/delete, or standard codebase reindex permission.
Owner
Project Owner includes Viewer and Editor. The following project-administration capabilities are available to Owner, but not to a built-in Editor or Viewer:
- Manage project details
- Add and remove project members
- Change project role assignments
- Update project settings
- Archive the project
- Delete the project
- Reindex the codebase
- Update or delete any automation in the project
- Delete any API key in the project
Organization Administrators inherit Owner-equivalent project authority.
Organization permissions
Capability | View | Member | Administrator |
|---|---|---|---|
Seat type | View | Full | Full |
Belong to the organization | Yes | Yes | Yes |
Be assigned to organization projects | Yes | Yes | Yes |
Highest eligible project permission | Viewer | Owner | Owner |
Create a project | No | Yes | Yes |
Read organization usage | Yes | Yes | Yes |
Invite and manage organization members | No | No | Yes |
Create and edit custom-role definitions | No | No | Yes |
Edit organization policies | No | No | Yes |
View and administer every organization project | No | No | Yes |
Manage billing | No | No | Yes |
Organization membership and project access are separate. View and Member users still need a project assignment to receive that project’s content access.
A View seat caps project access at Viewer level but does not redefine Viewer permissions. The Viewer actions and module exceptions in this reference therefore also apply to View members.
Project-member permissions
Any person who can enter the project can view the project member roster, including a shell-only custom-role holder.
Only a Project Owner or Organization Administrator can add members, remove members, or change their project roles.
API key permissions
Action | Viewer | Editor | Owner |
|---|---|---|---|
List project API keys | Yes | Yes | Yes |
Create an API key | Yes | Yes | Yes |
Delete a key created by that user | Yes | Yes | Yes |
Delete any project API key | No | No | Yes |
Linked content
Linking two pieces of content does not automatically grant access to both.
For example, viewing a Work Order does not by itself grant access to a linked Requirement, Blueprint, Artifact, or code reference. Software Factory checks the linked content independently and shows contextual content only when the user has the required access.
Important exceptions
Artifacts Viewer can create
Artifacts intentionally use an append-oriented model. Viewer can upload and create artifacts, while Editor is required to rename, delete, or create folders.
Feedback Viewer can submit
Feedback submission is available at Viewer level. Triage and theme management require Editor.
Automation Viewer can execute
Execution of an existing automation follows Automation read access. Creation requires Editor. Updating or deleting an automation normally requires the user to be its creator, unless the user is a Project Owner or Organization Administrator.
Codebase reindex differs by role type
A built-in Project Editor can manage the repository connection but cannot reindex. Project Owner can reindex. The current custom-role model also grants reindex to a custom role configured as Codebase Editor.