The built-in roles
Owner
Full access. The person who installed Customei is the account Owner. An account always has exactly one Owner — if you need to transfer ownership, contact Support.
Staff
Can view, create, and edit most resources — but cannot delete, manage billing, or manage members. Use Staff for designers, merchandisers, and day-to-day operators.
What Staff can do by default
Staff members start with the following permissions. Each of these can be explicitly granted or revoked for any individual member without changing the role.View everything
Staff can open and read every area of Customei: Templates · Libraries · Option Sets · Products · Files · Billing · Members · Credits · Theme · Settings · Translations · Integrations.Create and edit
Staff can create and edit the things designers work with:- Templates — create and edit (but not delete).
- Layers — edit layer content inside templates.
- Libraries — create and edit (but not delete).
- Option sets — create and edit (but not delete).
- Files — upload.
- Orders — edit personalization payloads if the order needs fixing before fulfillment.
- Credits — use (spend credits on actions like print-file generation and AI lab).
What Staff cannot do by default
- Delete anything — templates, libraries, option sets.
- Manage billing (upgrade plan, purchase credits).
- Manage members (invite, remove, change roles).
- Publish or assign products to templates.
- Edit theme / settings / translations — view only.
- Manage integrations (webhooks, API keys) — view only.
The permission matrix
Customei uses granular permissions grouped into 14 categories. Role defaults set which permissions are on; per-member overrides turn individual permissions on or off.| Category | Permissions |
|---|---|
| Templates | template:view, template:create, template:edit, template:delete, layer:edit |
| Libraries | library:view, library:create, library:edit, library:delete |
| Option Sets | optionset:view, optionset:create, optionset:edit, optionset:delete |
| Products | product:view, product:assign, product:publish |
| Orders | order:edit |
| Files | file:view, file:upload, file:delete |
| Billing | billing:view, billing:manage |
| Members | member:view, member:manage |
| Credits | credit:view, credit:purchase, credit:use |
| Theme | theme:view, theme:edit |
| Settings | settings:view, settings:edit |
| Translations | translation:view, translation:edit |
| Integrations | integration:view, integration:manage |
| Shop | shop:cleanup |
Typical override patterns
A few real setups to copy:Senior designer — full template control
Grant on top of Staff defaults:template:delete, library:delete, optionset:delete.
Now they can prune stale templates and option sets without you doing it for them.
Operations — orders and files only
Start from Staff, then revoke:template:create, template:edit, library:create, library:edit, optionset:create, optionset:edit.
Keep: all view permissions, order:edit, file:upload.
Ops sees everything but can only touch orders and uploads.
Billing admin — can pay, can’t design
Start from Staff, then grant:billing:manage, credit:purchase.
Revoke: all create and edit permissions.
They can buy credits and manage the subscription without touching any design work.
How overrides are stored
Each member has an override map:{ 'template:delete': true, 'library:delete': false, ... }. Keys set to true grant a permission on top of the role; false explicitly revokes one; missing keys fall back to the role default. See Members → Per-member overrides to edit them.