Organization permissions
Choose organization roles and understand how dashboard, API key and MCP access follow current membership.
Organization permissions apply to the dashboard, REST API and MCP server. New member assignments and invitations use one role. Historical composite roles remain displayed as stored. Permissions are organization-wide; there are no per-user overrides, role groups or organization-owned keys.
Predefined roles
Owner, Admin, Member, Account Connector and Viewer are available on PayG and Business. Member preserves existing operational access, including posting, account management, sensitive token reads, configuration management, API keys and billing read. Choose a restricted role explicitly when that access is too broad.
Account Connector can view, connect and reconnect social accounts without access to billing, configurations or the team page. Viewer can view accounts and posts. Owner has organization deletion and protected ownership authority. Admin manages access, subject to Owner protection. Ordinary Team selectors exclude Owner and cannot modify an Owner or your own membership. Native ownership operations protect the last Owner and prevent Admin from changing an Owner.
Full permission matrix
A dash means denied. Custom roles can select the capabilities marked Yes in the final column. Names below are exact resource/action identifiers. Omitted capabilities deny access.
| Capability | Owner | Admin | Member | Account Connector | Viewer | Custom selectable |
|---|---|---|---|---|---|---|
accounts:read | Yes | Yes | Yes | Yes | Yes | Yes |
accounts:connect | Yes | Yes | Yes | Yes | - | Yes |
accounts:reconnect | Yes | Yes | Yes | Yes | - | Yes |
accounts:disconnect | Yes | Yes | Yes | - | - | Yes |
accounts:assign_tenant | Yes | Yes | Yes | - | - | Yes |
accounts:read_tokens | Yes | Yes | Yes | - | - | Yes |
posts:read | Yes | Yes | Yes | - | Yes | Yes |
posts:create | Yes | Yes | Yes | - | - | Yes |
posts:update | Yes | Yes | Yes | - | - | Yes |
posts:publish | Yes | Yes | Yes | - | - | Yes |
posts:delete | Yes | Yes | Yes | - | - | Yes |
media:read | Yes | Yes | Yes | - | - | Yes |
media:upload | Yes | Yes | Yes | - | - | Yes |
media:delete | Yes | Yes | Yes | - | - | Yes |
media:process | Yes | Yes | Yes | - | - | Yes |
analytics:read | Yes | Yes | Yes | - | - | Yes |
interactions:read | Yes | Yes | Yes | - | - | Yes |
interactions:reply | Yes | Yes | Yes | - | - | Yes |
interactions:delete | Yes | Yes | Yes | - | - | Yes |
conversations:read | Yes | Yes | Yes | - | - | Yes |
conversations:send | Yes | Yes | Yes | - | - | Yes |
conversations:manage | Yes | Yes | Yes | - | - | Yes |
configurations:read | Yes | Yes | Yes | - | - | Yes |
configurations:read_secrets | Yes | Yes | Yes | - | - | Yes |
configurations:manage | Yes | Yes | Yes | - | - | Yes |
webhooks:read | Yes | Yes | Yes | - | - | Yes |
webhooks:read_secrets | Yes | Yes | Yes | - | - | Yes |
webhooks:manage | Yes | Yes | Yes | - | - | Yes |
api_keys:read | Yes | Yes | Yes | - | - | Yes |
api_keys:create | Yes | Yes | Yes | - | - | Yes |
api_keys:revoke | Yes | Yes | Yes | - | - | Yes |
billing:read | Yes | Yes | Yes | - | - | Yes |
billing:manage | Yes | Yes | - | - | - | Yes |
organization:read | Yes | Yes | Yes | - | - | Yes |
organization:update | Yes | Yes | - | - | - | Yes |
organization:delete | Yes | - | - | - | - | - |
member:create | Yes | Yes | - | - | - | - |
member:update | Yes | Yes | - | - | - | - |
member:delete | Yes | Yes | - | - | - | - |
invitation:create | Yes | Yes | - | - | - | - |
invitation:cancel | Yes | Yes | - | - | - | - |
team:create | Yes | Yes | - | - | - | - |
team:update | Yes | Yes | - | - | - | - |
team:delete | Yes | Yes | - | - | - | - |
ac:create | Yes | Yes | - | - | - | - |
ac:read | Yes | Yes | - | - | - | - |
ac:update | Yes | Yes | - | - | - | - |
ac:delete | Yes | Yes | - | - | - | - |
Team capabilities are reserved internal vocabulary; role groups are not offered in the product.
Business custom roles
Owner and Admin can create, edit and delete custom definitions in Team settings with an active Business subscription. Names and definition IDs are immutable. Membership selectors resolve a definition ID to its canonical name and assign exactly one role. Custom roles cannot grant member, invitation, team or role administration, or organization deletion.
Review the displayed member and pending invitation counts before editing. An edit changes permissions for everyone using that definition. Deletion requires reassignment of every member and cancellation or replacement of every pending invitation, including expired pending invitations. Frozen legacy roles stay visible and continue to define current access; PayG does not allow new custom assignments or definition changes. Reassign to predefined roles or upgrade to recover.
Select each needed capability explicitly. Dashboard draft creation requires posts:create; publishing or scheduling also requires
posts:publish. REST POST /v1/posts and MCP create_post always require both create and publish, even for drafts. Updating
scheduled/published content, cancelling a live schedule and remote deletion additionally require posts:publish with the relevant
update/delete action. Media processing additionally needs media:process. Dashboard workflows require the corresponding page read
capability and accounts:read for account selection; read is not universally required for every REST write.
Replacing an existing account connection needs accounts:reconnect; changing its tenant needs accounts:assign_tenant.
accounts:read_tokens is sensitive: the explicit includeTokens=true account-list request can expose provider access tokens and also needs
accounts:read. That request returns access_token only; refresh tokens and session JWTs stay hidden. Normal account responses omit
credentials. Configuration/webhook secret reads require the matching read and read_secrets capabilities; normal summaries omit secrets.
Selecting a capability never silently selects its companions.
API keys and current membership
API keys belong to their creator and are bound to one organization. On every use, the creator must still be a member of that organization. Effective access is the intersection of current role permissions and the stored key ceiling, limited to operational capabilities. New ceilings are captured at creation and cannot be expanded by a later promotion; an empty ceiling grants nothing. Legacy keys with a null ceiling follow the creator's current operational role. Unknown or malformed ceilings deny access.
Demotion immediately narrows future requests. Removal denies access. External integrations can stop after creator demotion or removal, even if the key is still enabled. Create a new key when a broader ceiling is needed, and update the integration. Keys do not grant billing or access administration. REST accepts API keys only; see Authentication.
MCP consent and reconnect
OAuth consent binds one organization and an immutable operational permission ceiling to the grant. Each token use intersects that grant with the user's current membership and role. Refresh descendants retain the same ceiling; promotion and refresh do not expand it. Demotion narrows access and removal or parent-grant revocation denies all descendants.
Reconnect and approve a new consent grant for newly needed access. Legacy OAuth credentials without a verified immutable grant must reconnect; they are not repaired from a mutable organization mapping. MCP API-key authentication follows key semantics above and does not use OAuth reconnect. All tool calls are checked independently, even if the tool remains discoverable. See MCP setup and Tool Reference.
Downgrades and recovery
Before a Business-to-PayG change, Owner or Admin must approve a mapping from every custom role used by any member or pending invitation to a predefined role. The preview shows usage, gained/lost capabilities and affected key/grant counts. It includes the approving actor when they have a custom role and includes expired pending invitations. Stored legacy composite roles are mapped token by token and deduplicated, preserving builtin Owner.
Finance with billing management can handle ordinary billing and exact-schedule cancellation/recovery, but needs Owner/Admin approval to convert its own custom membership, even when submitting an empty mapping. Self-service scheduling is blocked when one subscription funds multiple organizations.
Every nonterminal transition freezes custom definitions. During a confirmed scheduled change with active Business, only custom roles already in the approved mapping remain assignable. Scheduling, cancellation, inactive/non-Business state and unmapped custom roles block custom assignment. Predefined-role moves and removal remain available. The Team page displays the effective date and targets. On confirmed application, member/invitation mapping and plan state commit together.
An uncertain billing outcome stays frozen until recovery or cancellation confirms it; an elapsed date or detached schedule is insufficient proof. Unconfirmed creation outcomes older than 23 hours require recovery rather than blindly creating another schedule. Known configured schedules can recover beyond that window. A Standard plan set outside this flow requires separate Owner/Admin mapping remediation. Cancellation may leave already-converted custom assignments needing remediation. Existing key and MCP ceilings remain ceilings after remapping; legacy null-ceiling keys follow changed current permissions.
Hosted OAuth and background jobs
Hosted account-connection links are an accepted delegated connection exception. Their organization-bound callback can finish the connection without an independent logged-in member permission check. Treat the link as sensitive delegated authority. This exception does not grant billing, configurations or access administration, and normal dashboard/REST account workflows enforce their current caller permissions.
Existing background jobs and already accepted scheduled posts continue after the initiating member's role changes. A later role change does not automatically cancel that already accepted work. New requests and manual retry/edit/cancel operations check current access. Use the existing post cancellation controls to stop queued publishing while you still have the required capabilities.