Overview #
Workflo uses a structured role-based permission system that gives your organization precise control over who can see, create, and manage content at every level of the platform. Roles are assigned at multiple levels — Organization, Workspace, Project, Portfolio, and Dashboard — allowing you to tailor access to match your organization’s structure and confidentiality requirements.
How the Role System Works #
Workflo’s permission system is hierarchical. Roles assigned at a higher level (such as a Workspace) inform the access a user receives at lower levels (such as a Project). This means you do not need to individually configure every permission — the system provides a consistent and manageable starting point that administrators can adjust as needed.
Organization Role
└── Workspace Role
└── Project RoleOrganization Roles #
Organization roles govern access at the company level.
| Role | What They Can Do |
|---|---|
| Super Admin | Full organizational control: manage workspaces, users, billing, and licenses |
| Admin | Create and manage workspaces; manage users |
| Member | Standard organizational participant |
| Guest | Restricted external user |
Only Super Admins and Admins can create new workspaces.
Workspace Roles #
Workspace roles determine what a user can do within a specific workspace. Every workspace member is assigned one of the following:
| Role | What They Can Do |
|---|---|
| Owner | Complete control: manage all settings, invite members, remove members, delete the workspace |
| Admin | Manage workspace settings and members; send invitations; cannot delete the workspace |
| Member | Create projects and tasks; cannot modify workspace settings |
| Guest | View content in projects they have been added to; cannot create projects |
| Limited Access Guest | Highly restricted; can view and comment only — see details below |
Project Roles #
Project roles determine what a user can do within a specific project.
| Role | What They Can Do |
|---|---|
| Owner | Full control over the project; can delete it and manage all members |
| Admin | Update project settings; manage and remove members; delete the project |
| Collaborator | Create and manage tasks; add sections; contribute fully |
| Commentator | View tasks and leave comments; cannot create or edit tasks |
How Workspace Roles Inform Project Roles #
When a workspace member is added to a project, their suggested starting role is based on their workspace role. Project admins can adjust this at any time.
| Workspace Role | Suggested Project Role |
|---|---|
| Owner | Admin |
| Admin | Admin |
| Member | Collaborator |
| Guest | Commentator |
Public vs. Private Projects #
- Public projects — Any workspace member can access and join without requesting permission
- Private projects — Members must request access; the highest role they can self-request is Collaborator (Admin and Owner must be granted directly)
Portfolio Roles #
| Role | What They Can Do |
|---|---|
| Admin | Full control: manage members, update portfolio, add/remove projects |
| Editor | Update portfolio content and add projects |
| Viewer | Read-only access; can view but not modify |
Dashboard Roles #
| Role | What They Can Do |
|---|---|
| Admin | Full control: edit, delete, manage members |
| Editor | Update dashboard content and configuration |
| Viewer | Read-only access; cannot make any changes |
Limited Access Guests #
A Limited Access Guest is a special access designation that can be applied to any workspace user. It represents the most restricted tier of access available and is designed for external contributors, contractors, or clients who need minimal interaction with your workspace.
What Limited Access Guests Can Do #
| Action | Allowed? |
|---|---|
| View tasks they are assigned to | Yes |
| Leave comments on tasks | Yes |
| Participate in a chat if a full member initiates it | Yes |
| View chat history | Yes — last 30 days only |
| Create tasks | No |
| Create projects | No |
| Create chat rooms | No |
| Create portfolios | No |
| Create dashboards | No |
| Add sections to projects | No |
| Send project invitations | No |
| Move tasks between projects | No |
| Duplicate tasks | No |
Quick Permissions Reference #
| Action | Minimum Role Required |
|---|---|
| Delete a workspace | Workspace Owner |
| Update workspace settings | Workspace Admin |
| Create a project | Workspace Member |
| Delete a project | Project Admin or Owner |
| Update project settings | Project Admin or Owner |
| Create a task | Project Collaborator (not Limited Access Guest) |
| Edit a task | Project Collaborator (not Limited Access Guest) |
| Comment on a task | Project Commentator or above |
| Create an organization workspace | Organization Admin or Super Admin |
Invitations and Access Requests #
Invitations #
- Workspace invitations can only be sent by Workspace Owners and Admins
- Project invitations can be sent by any Project Member (not Limited Access Guests)
Access Requests #
If a project is set to public, workspace members can join without an invitation. For private projects, users submit an access request that must be approved by a project admin.
Best Practices #
- Apply the principle of least privilege. Give each user the minimum role they need to do their work. This limits the risk of accidental changes and protects sensitive information.
- Use Limited Access Guest for external parties. When sharing workspace access with clients, contractors, or vendors who only need to see or comment on work, use the Limited Access Guest designation.
- Use private projects for confidential work. Set sensitive projects to private for an additional layer of access control.
- Review membership regularly. As projects close and members change, keep roles and memberships current to maintain a clean and secure workspace.
- Assign at least two Admins at the workspace and project level. Having more than one admin ensures continuity if a primary admin is unavailable.
