Security & Permissions

Workivo uses a role-based permission system. Every user belongs to one or more groups, and each group has roles with specific permissions.

How it works

Groups contain users (e.g. "Managers", "Employees")
Group Roles assign a role name to a group (e.g. "manager", "employee")
Permissions are defined per role — which tables they can read, create, update, or delete

Permission format

Each GroupRole has a Permissions field. It is a JSON object mapping table names to their allowed actions and scope:

{
  "pages":    { "actions": ["read", "create", "update"], "scope": "all" },
  "messages": { "actions": ["read", "create"], "scope": "own" }
}

Actions

read — view records and lists
create — create new records
update — edit existing records
delete — destroy records

Scope

all — user sees all records in the table
own — user only sees records where created_by matches their username

Admin role

The admin role grants unrestricted access to everything. It does not need explicit permissions — it is a hardcoded bypass. The first user created in the system also gets full admin access automatically.

Merging permissions

If a user belongs to multiple groups with multiple roles, all permissions are merged together. For example:

Group A gives read on pages
Group B gives create on pages
Result: the user gets both read and create on pages

Sidebar visibility

Sidebar items can have a required_role field. If set, only users with that role (or admin) see the item. If a sidebar item links to a table list, the system also checks if the user has read permission on that table before showing it.

Existing seed roles

The seed data includes three groups with example permissions:

Administrators — role: admin (full access)
Managers — role: manager (read, create, update on pages; read, create on messages)
Employees — role: employee (read on pages; read-only own messages)

These are examples. You can create any roles and permissions you need from the Group Roles form.

Back:

Workivo Docs: Security & Permissions