WorshipKit Permission Model

Every WorshipKit organization is made of members, and every member holds exactly one role. Roles decide what a person can see and do inside that organization. This guide explains the four roles, what each one can do, how the Editor role's fine-grained grants work, and how ownership is handed over.

This is the org-level permission model that replaced the older Owner / Admin / Leader / Sender / Receiver levels. There is one Owner per organization; everyone else is an Admin, an Editor, or a User.

The four roles

What each role can do

"Assign the Owner role" is stronger than "assign Admin / Editor / User": promoting someone to Owner is what a transfer does (see below), and only the current Owner can do it.

How Editor grants work

Owner, Admin, and User have fixed scopes. Editor is the only role whose reach is configured per person. When you set someone to Editor you also pick:

• Features — which WorshipKit apps they can work in (Slides, Billboard, and any other app the organization subscribes to). An Editor can only see and edit content inside the features they were granted.
• Ministries — which ministries they belong to. Editors act within their granted ministries.

Only features the organization is actually subscribed to can be granted. Removing a grant later immediately revokes that Editor's access to it.

Owners and Admins always have every feature and ministry, so they have no grant checklists. Users only ever touch their own content and content shared with them, so they have none either.

Where you set this

• Users → a member → "Role & access…" — change an existing member's role and, for Editors, their feature and ministry grants.
• Users → "Invite User" — pick the new member's role (and Editor grants) at invitation time. New members default to User with no grants — the tightest scope.
• Users → "Roles" — a read-only reference of this table.

Transferring ownership

There is always exactly one Owner, so you don't "assign" the Owner role the way you assign the others — you transfer it.

1. As the Owner, go to Users → "Transfer ownership" (visible only to the Owner). 2. Pick another member of the organization. 3. Confirm. In one step the chosen member becomes the Owner, and you are changed to Admin.

After the transfer you keep Admin-level access — org and user management, full content editing — but you no longer manage billing or control ownership. Only the new Owner can transfer it back. An Owner cannot be removed or demoted except through this transfer, and an organization's sole Owner cannot be deleted.

API surface

For programmatic clients, the role model is exposed under /api/v2:

• GET /api/v2/users/:id/access / PUT /api/v2/users/:id/access — read or set a member's role_slug (owner | admin | editor | user) plus app_module_short_names and ministry_ids for Editors. owner cannot be written here.
• POST /api/v2/users — invite a member with an optional role_slug and Editor grants (defaults to user).
• GET /api/v2/organizations/:id/available_apps — features that can be granted to an Editor.
• GET /api/v2/organizations/ministries — ministries that can be granted.
• POST /api/v2/organizations/:id/transfer_ownership — body { new_owner_user_id }. Owner-only.