Understand roles and permissions

Onplana resolves every permission along two independent axes: the role you hold in the organization, and the role you hold inside each project. A person can be a plain Member at the organization level and still be the Project Owner of the projects they create.

Organization roles

• Owner: full control, always. Manages billing, edits the permission matrix, and can promote or demote anyone. The Owner’s access can never be restricted.
• Admin: governs the platform itself, security settings, integrations, governance configuration, and audit. Cannot change the plan or edit the permission matrix.
• Portfolio Manager: runs portfolios, teams, gate reviews, and the project pipeline. Can create projects and see every project in the organization by default.
• Member: regular contributor. Sees projects they own or are added to. By default, Members can create their own projects and become the Project Owner of those.
• Guest: external collaborator with access only to the projects they are explicitly added to. No organization-wide reads.

Project roles

Inside each project, membership carries its own role: Project Owner (automatically the creator), Project Manager, Project Member, Project Contributor, and Project Viewer. These control task creation and editing, member management, sprints, budgets, and so on, regardless of the person’s organization role.

The permission matrix

Open Organization Settings and go to the Permissions tab. The matrix shows two tables: organization-level actions (resolved against organization roles) and project-level permissions (resolved against project roles). Every cell is a toggle, so you can tighten or loosen the defaults to match how your organization operates.

Only the Owner can save changes to the matrix. Admins and Portfolio Managers can view it read-only. This is deliberate: it prevents an Admin from granting themselves broader rights through the matrix.

Posture presets

Instead of toggling rows one by one, pick a posture above the matrix:

• Open: any member can do almost anything. Flat teams and startups.
• Standard (recommended): Members run their own work, Portfolio Managers oversee teams, Admins govern. This matches the defaults.
• Strict: Members consume the platform; Portfolio Managers and Admins build it.
• Formal PMO: projects originate only from the proposal pipeline, and every configuration change is centralized.

A preset stamps a coherent set of organization-level toggles; project-level rows are left untouched. You can still hand-tune individual rows after applying one, then select Save.

Tip

The preset that matches your current matrix is highlighted, so you can tell at a glance which posture your organization is on, and whether someone has hand-tuned it since.

The last-Owner safeguard

An organization must always have at least one Owner. Onplana blocks demoting or removing the last Owner. To transfer ownership, promote another member to Owner first, then demote yourself or leave.

Best practices

1. Pick a posture preset, then hand-tune sparingly. Standard works for most. Don’t accept defaults blindly; verify the preset matches your org’s culture before going live.
2. Treat Owner role as scarce. Two Owners is the minimum for redundancy. More than 3 is over-privileged. Last- Owner safeguard prevents accidental self-lockout.
3. Document the matrix decisions. Why was org.scenario.manage tightened to ADMIN+? Write it down. Future admins will ask.
4. Audit the matrix annually. Permissions drift as org evolves. A quarterly read of the matrix + posture-preset comparison surfaces policy drift.
5. Use custom roles for genuinely-new patterns. Don’t recreate Member with one extra permission as a custom role. See Create custom roles.

Troubleshooting / common pitfalls

• Admin can’t edit the matrix. By design. Only Owner edits. This prevents privilege escalation.
• Posture preset highlight gone. Matrix hand-tuned beyond preset. Either save as custom or re-apply preset.
• Last-Owner can’t leave/demote. Promote another to Owner first. Required guardrail.
• Member can’t create project. org.project.create restricted via matrix. Check Formal PMO posture preset or individual toggle.
• Permission cell looks toggled but request denied. Plan-gating may override. Permission says yes; plan says no. See plan compare for the feature.

How this combines with other features

• Roles + Custom roles. Defaults + custom roles cover most teams. See Create custom roles.
• Roles + Audit log. Every matrix change writes to audit log. See Read audit logs.
• Roles + SSO/SCIM. Roles can sync from IdP via SCIM. See Provision users with SCIM.
• Roles + 2FA. Org can enforce 2FA per role tier. See Enforce two-factor authentication.

Coming from another tool

Tool	Mapping
SharePoint group permissions	Direct concept
ServiceNow ACLs	Direct
Jira project roles	Direct (project-level axis)
Asana workspace permissions	Direct (org-level axis)
Custom RBAC	Onplana uses standard role-based model

FAQs

Why can my Admin not edit the matrix? Matrix editing is restricted to the Owner so that nobody can widen their own permissions. Admins can review the matrix and ask the Owner to apply changes.

Can Members really create projects? Yes, by default, and the creator becomes the Project Owner of that project. Organizations that want projects to flow through a pipeline turn this off with the Formal PMO preset or the individual toggle.

What is the difference between Portfolio Manager and Project Manager? Portfolio Manager is an organization role with oversight across projects. Project Manager is a per-project role inside a single project. The same person can hold either, both, or neither.

Can I add roles beyond the defaults? Yes, on the Business plan and above you can define custom project roles. See Create custom roles.

Why does an Admin lose access to a feature after a plan downgrade? Plan-gating sits independently of permissions. The matrix says yes; the plan says no. Verify the feature is included on the current plan.

Can I see what a specific user can do? Not natively today. The matrix shows by-role; calculating per- user requires looking up role + custom-role grants.

Does the matrix support deny rules? No, Onplana uses default-deny + explicit-allow. Permissions are positive grants.

Related

• Create custom roles, beyond defaults
• Read audit logs, matrix change history
• Provision users with SCIM, IdP role sync