concept · explanation

Roles, personas, and permissions

Understand how roles, personas, and permissions works in Slash Social.

Teammates see different cards, buttons, and queues in Slack depending on how you assign access. Roles, personas, and permissions explain who can change what, and how Slash Social decides what each person sees in App Home.

Overview

Slash Social separates three ideas that often get mixed up:

  • Roles: Assignments you give a teammate at the organization or on a specific brand, pillar, or campaign.
  • Permissions: Fine-grained checks that gate sensitive actions, such as managing roles or editing routing.
  • App Home views: The product view Slash Social builds from roles on the active brand. These views filter work items, approval rows, and quick actions on App Home and in modals.

Roles answer whether someone may act on a brand. Plan access answers whether the organization has paid for a feature. Both must pass before an action succeeds.

How it works

Roles and scope

Slash Social assigns roles at the organization and at specific entities such as brands, pillars, and campaigns. Common roles include admin, owner, manager, reviewer, publisher, creator, and viewer.

  • Admin: Manage billing and broad organization settings.
  • Owner: Manage brand configuration for entities they own.
  • Manager: Coordinate review work across creators and approvers.
  • Reviewer: Sign off on content in review.
  • Publisher: Publish approved content.
  • Creator: Draft and edit content.
  • Viewer: Read work without changing state.

A user can hold different roles on different brands when your organization has multi-brand enabled. Role assignments persist until an admin updates them.

App Home views

Slash Social shapes App Home from your roles on the active brand. Admin, approver, and creator views filter which work items, approval rows, and quick actions appear on App Home and in modals.

A creator may see drafts and create shortcuts but not billing controls. An approver sees pending review work but may not open every settings path. These views are not separate logins. They are the product view of the roles you already assigned.

Permissions vs. plan gates

Permissions gate specific governance actions. For example, opening the roles editor or submitting role changes requires the roles-manage permission. Routing edits validate scope and channel combinations before they save.

Plan gates control feature availability at the organization level. Audit history is included on Team and Scale plans, not on Free or Starter. Daily briefing is included on all public plans. A user can hold the right role and still see an upgrade prompt when the organization is on a plan that does not include a feature.

Governance changes write audit records when your plan includes audit history.

Where admins manage access

Admins open team and governance surfaces from the Settings work center. From there you can manage roles, edit routing for approval handoffs, and view or export audit history when your plan includes it. The permissions reference lists each capability and which roles typically hold it.

Examples

Agency with split duties. An admin assigns creator on Brand A and approver on Brand B to the same freelancer. When they switch active brands in App Home, their view changes: create shortcuts on A, pending approvals on B.

Brand owner without billing access. An owner manages pillars and cadence for one brand but cannot change organization billing. Their App Home shows brand settings while hiding admin-only billing cards.

Reviewer blocked by plan. A reviewer opens an approval workflow list but sees an upgrade prompt for multi-step workflows because the organization is below Team. Their role is correct; the plan gate still applies.

Why it matters

Consistent roles keep creators from approving their own posts and keep billing changes limited to admins. Personas reduce clutter so each teammate sees work relevant to their job. Permissions and plan gates together prevent accidental governance changes and make upgrade paths explicit.

Pair role design with Approvals and review governance so approvers, routing, and workflows match how your team reviews content in Slack.