PandaDoc Roles and Permissions: The Governance Setup Guide

PandaDoc has five built-in roles: account owner, admin, manager, member, and collaborator, each with a fixed set of permissions over documents, templates, content, and settings. Enterprise accounts can also build custom roles with granular permissions across roughly twenty categories, from templates and catalog items to approval workflows and quote rules.

That is the mechanical answer. The useful answer is that roles are the enforcement layer for every other piece of proposal governance: a locked template, a governed catalog, and an approval workflow all depend on reps holding a role that cannot quietly edit around them. Most teams never design this: whoever did the setup is an admin, everyone hired since is whatever the inviter clicked first, and the permission structure is an accident. It matters because off-brand proposals were the second most common pain in the 129 sales calls we analysed, cited in 44 of them, and the usual direct cause was people editing things no role should have let them edit.

Key takeaways

• The five built-in roles split cleanly: collaborators comment, members send their own documents from shared templates, managers see every document and run reporting, admins control workspace settings and content sharing, and the single account owner holds billing, workspace creation, and the extension store.
• The boundary that matters most for sales teams: members can use and duplicate other people’s templates but cannot edit them. That one rule keeps a canonical template canonical, so most reps should be members, not managers.
• Members can still create their own templates and content library items. The role stops them overwriting the master, not building a rival copy, so template governance needs an owner and a convention on top of the role.
• Custom roles are Enterprise-gated, created only by the account owner under Settings > Roles, and must be enabled per workspace before they appear in team management. The per-workspace switch is the most commonly missed step.
• Only the single account owner can reach billing, create workspaces, and manage add-ons. If the owner leaves without transferring ownership in Settings > Billing, recovering control goes through PandaDoc support instead of a dropdown.

The five built-in roles, and what each one is for

PandaDoc’s role model is per workspace: one person can belong to several workspaces with a different role in each. From least to most access:

Collaborator. Can view and comment on documents shared with them and use the inbox. Collaborators are not invited from team settings at all; they are invited from inside a document. This is the role for a subject-matter expert reviewing a scope section, or an external stakeholder who needs to see a draft without ever sending anything.

Member. The working role for most salespeople. A member creates and sends their own documents, from blank, from uploads, or from any template in the workspace. They can view and duplicate other people’s templates but not edit them, and they see colleagues’ documents only when added as a collaborator. They can create their own templates and content library items, and they can view and use catalog items but not edit anyone else’s.

Manager. Everything a member can do, plus visibility: managers send and view every document in the workspace, access reporting, edit and delete other people’s templates and content, manage catalog items, and add new users. What they cannot reach is workspace settings, and the only role change they can make is moving a collaborator up to member.

Admin. Full control of the workspace: everything a manager has, plus workspace settings, branding, removing users and changing roles, sharing templates and content across workspaces, and the developer dashboard for API keys.

Account owner. One per account, with full access to everything. Three things belong to this role alone: billing, creating workspaces, and managing features from the extension store. The owner role is account-level plumbing, not a day-to-day working role.

The shape to notice: the big jump is manager to admin, not member to manager. Managers get visibility and content control; admins get the settings that change how the system behaves. Hold that line and most governance follows.

The permission boundaries that matter for proposals

The full permission matrix is long, but four boundaries do most of the governance work for a proposal system.

Templates: use versus edit. Members use, duplicate, and send from any template; only managers and admins edit or delete templates they do not own. This is the enforcement behind every branded proposal template: the locked pricing table, approved terms, and brand blocks stay fixed because the people sending hold a role that cannot change them. Without this boundary, a template is a suggestion.

Catalog: use versus maintain. Members can view and use catalog items in pricing tables, but creating and deleting them sits with managers and admins, so list prices change in one governed place instead of being hand-edited per deal. Manual document creation was the top pain in 82 of the 129 calls we analysed, and hand-maintained pricing is a large part of why: the catalog boundary is what makes pricing a system instead of a memory.

Documents: own versus all. Members see their own pipeline; managers see the workspace. This is less about secrecy than reporting: deal visibility, stuck-document triage, and the dashboard belong to the people running the team, and a departing rep’s in-flight documents stay reachable by their manager.

Sharing and settings: admin only. Cross-workspace sharing, branding, user removal, and integration credentials all sit at admin level. These are the switches that change behaviour for everyone, which is exactly why they should be reachable by almost no one.

One honest caveat on the first boundary: a member cannot edit the master template, but nothing stops them duplicating it, editing the copy, and sending from that instead. The role protects the canonical template; it does not prevent a rival version existing. Closing that loop is a governance job, not a permissions job: a named template owner, a folder convention separating masters from drafts, and a periodic cleanup, the routine covered in our PandaDoc admin guide.

Custom roles: Enterprise-grade precision

The built-in roles cover most teams of 2 to 20. When they pinch, it is usually a member who needs slightly more (edit the catalog but not templates) or a manager who needs slightly less (see all documents, touch nobody’s content). Custom roles solve both, with conditions.

The mechanics, verified against PandaDoc’s documentation in October 2026: custom roles are an Enterprise-plan feature, and only the account owner can create one, under Settings > Roles. Permissions can be set manually or copied from a system role or another custom role and adjusted, which is the sensible route: start from member, add what the role needs. The categories are granular, roughly twenty of them, covering documents and templates (own versus all), forms, content library, catalog, contacts, payments, integrations, workspace settings, content sharing, reporting, approval workflows, smart content and CPQ, and quote rules, among others.

Two things to know before building any. First, the trap: a custom role must be enabled per workspace, from the role’s Workspaces tab, before it appears in team management at all. A custom role that “does not show up” is almost always one nobody enabled for that workspace; an enable-for-all-future-workspaces option exists and is worth setting on standard roles. Second, packaging around custom roles has been moving with PandaDoc’s licence changes, so verify current plan gating on PandaDoc’s pricing page before designing a structure that depends on it.

The design rule is the same as everywhere else in security: minimal, named for the job. A “Catalog owner” role that is member plus catalog rights is self-documenting; a “Senior rep” role with eleven unexplained toggles is a future mystery.

The least-privilege pattern for a sales team

For a typical team sending proposals from a CRM, the role map writes itself:

• Reps: member. They send their own proposals from templates they cannot edit, with pricing from a catalog they cannot change. Everything a rep should do daily is inside the member role; everything a tired rep might do at 5pm on quarter-end (edit the master, tweak a list price) is outside it.
• Sales manager or team lead: manager. Document visibility, reporting, user adds. One or two per workspace.
• System owner: admin. The person who owns templates, catalog, integration health, and settings. One, plus a deliberate backup: needing a system the team can run without the founder in the loop was a recurring theme in the calls we analysed, and an admin role held by exactly one busy person is that problem in miniature.
• Account owner: whoever owns the vendor relationship. Billing, workspaces, add-ons. Often the same person as the admin in a small company, which is fine as long as it is a decision rather than an accident.
• Reviewers, legal, external stakeholders: collaborator, invited per document, never holding a seat-level role they do not need.

Notice what this pattern does to the failure modes clients describe. Proposals cannot drift off-brand, because the 44-of-129 off-brand pain is mostly people with edit rights helpfully improving templates. Pricing cannot be hand-typed around the catalog by anyone below manager. Offboarding becomes one role removal instead of a scramble. The inverse is the human-Zapier pattern in unmanaged accounts: in one company we analysed, a team member manually re-added product data between systems every few days because nobody formally owned the integration. Roles do not fix that alone, but a named admin with the right access is the first step to the job being owned at all.

Rolling the structure out is an onboarding task, not an afterthought: assigning roles before the first training session means reps learn the system with the guardrails already on. It is one of the steps a structured PandaDoc onboarding locks in before go-live, and our team training and rollout guide covers the session-by-session sequence.

How roles interact with workspaces

On accounts with more than one workspace, roles and workspaces are two different axes. Workspaces decide what exists in the environment (templates, catalog, contacts, branding, integrations); roles decide what a person can do inside it, and a person can hold a different role in each workspace they belong to. A manager in the workspace they run can be a plain member in a sister brand’s, which is exactly how multi-brand membership should be assigned: minimum role per workspace, not a mirrored admin everywhere.

Three interaction points are worth knowing. Custom roles are created at account level but enabled per workspace, per the trap above. Cross-workspace sharing of templates and content is an admin permission, and approvers on a shared template must be members of its home workspace. And only the account owner can create a workspace at all. When a second workspace is justified, versus roles and folders inside one, is covered in our PandaDoc workspaces guide; the one-line answer is that workspaces are for real boundaries like brands and legal entities, and roles solve everything softer.

Four misconfigurations that break governance

Everyone is an admin. The default failure. The setup person was an admin, they invited the next person as admin because it was the top of the dropdown, and two years later six people can edit every template, change branding, and delete users. Every governance feature PandaDoc offers is switched off in practice, because everyone holds the role that bypasses it. The fix takes an afternoon: reconcile the team list against the role map above and demote by default. Expect zero workflow complaints, because almost nobody was using the access they held.

Reps editing master templates. Sometimes this is the admin sprawl above; just as often it is a deliberate choice (“make everyone managers so they can fix typos”). The typo gets fixed, and so does the pricing table, the terms block, and the logo spacing, one helpful edit at a time. Reps hold member; template changes route through the template owner. If a rep-facing change is genuinely frequent, that is a template design problem, usually solved with variables and editable fields in the right places, as covered on our PandaDoc template design service page.

The orphaned account owner. Billing, workspace creation, and add-on management are reachable by the owner role alone. When that person leaves with the role still attached, those functions are locked to an email nobody checks. Transfer is simple while the owner is present: Settings > Billing, change owner, confirm from the outgoing owner’s email, with the new owner already on the account. After they have gone, it is a support conversation with PandaDoc instead. Treat ownership transfer as a leaver-checklist item, the same as domain registrars and bank tokens.

The custom role nobody enabled. Enterprise teams design a tidy custom role, assign nobody to it because it does not appear in the team list, and quietly fall back to admin. The role was never enabled for the workspace: check its Workspaces tab first, and set standard roles to enable for all future workspaces.

Where this fits in the build order

Roles are cheap to set up and expensive to retrofit, so they belong early: decide the role map while templates and catalog are being built, assign on invite, and never let the default ride. In a full PandaDoc implementation the sequence is template architecture and catalog first, roles as the enforcement layer on top, then the integration, then training on the locked-down system. Teams that bolt permissions on after a year of everyone-as-admin can still fix it, but they are also fixing a year of template drift at the same time.

Roles are one part of a security review. If IT or procurement is asking about 2FA enforcement, SSO, SCIM deprovisioning or SOC 2, our PandaDoc security and compliance guide covers the rest, including why 2FA cannot be forced account-wide from inside PandaDoc.

FAQ

What is the difference between a member and a manager in PandaDoc?

Visibility and content control. A member sends their own documents from shared templates and sees colleagues’ documents only when invited into them. A manager sees every document in the workspace, runs reporting, adds users, and can edit other people’s templates and catalog items. Most reps should be members; managers are for the one or two people running the team.

What plan do I need for custom roles?

Custom roles are an Enterprise-plan feature, created only by the account owner under Settings > Roles. PandaDoc’s licence packaging has been shifting, so check their current pricing page before planning around it. The five built-in roles are on standard paid plans, and for most teams of 2 to 20 they are enough.

Can a PandaDoc member create their own templates?

Yes. Members cannot edit or delete other people’s templates, but they can create their own and duplicate existing ones, so the member role alone does not prevent template sprawl. Pair it with a named template owner, a folder convention, and a periodic cleanup so the canonical templates stay the ones people actually send.

Who can change user roles in PandaDoc?

Admins, from Settings > Team, plus any Enterprise custom role granted the change-users permission. The one exception: managers can promote a collaborator to member, and nothing else. Removing users is admin-only, which is the correct place for it.

What happens if our account owner leaves the company?

If ownership was transferred before they left (Settings > Billing, change owner, confirmed by email), nothing. If not, billing, workspace creation, and add-on management are locked to their old login, and recovery means contacting PandaDoc support. Put ownership transfer on the leaver checklist for whoever holds it.