Roles & Permissions
Roles & Permissions
Zingasuite gives you precise control over what each team member can do. Permissions combine a member's role, any per-object-type access granted to them individually, and — for programmatic access — the scopes on an API key. This page explains how those layers fit together.
Roles
Every membership carries a role:
| Role | Access |
|---|---|
| Owner | Unrestricted. Can manage everything, including granting ownership. |
| Admin | Full access to data plus administrative capabilities (see below). |
| Member | Only what has been explicitly granted to them. |
Owners and admins bypass the fine-grained checks entirely — the permission matrix is shown as full access for them. Members start with no access and are granted exactly what they need.
Per-object-type access (CRUD)
For members, access is defined per object type — the kinds of records in your apps, such as products, orders, categories, customers, contacts, tests, and so on. For each object type you can grant any combination of four operations:
| Operation | Lets the member… |
|---|---|
| View (read) | See records of this type. |
| Create | Add new records. |
| Edit (update) | Change existing records. |
| Delete | Remove records. |
Object types are grouped by app (ZingaShop, Zingalify, ZingaConnect) and by section (Catalog, Pricing, Inventory, Sales, Customers, and so on), so you can grant access a section at a time rather than one row at a time.
Permission templates
To save time, the Users page offers ready-made templates that pre-fill the matrix. You can apply one and then fine-tune before saving:
| Template | Grants |
|---|---|
| Administrator | Full access to every object type plus all admin capabilities. |
| Manager | Full control of catalog, pricing, inventory, sales, customers, marketing and content; read-only elsewhere. |
| Catalog editor | Create and edit products, categories, pricing and inventory; read-only elsewhere. |
| Order fulfilment | View and update orders and inventory; read everything else. |
| Viewer | Read-only across the whole workspace. |
Administrative capabilities
Separate from object access, five capabilities govern who can run the workspace itself. Grant these carefully — they are the "manage the business" switches:
| Capability | Allows |
|---|---|
| Create & manage users | Invite, suspend and manage team members. |
| Create & manage API keys | Mint and revoke API keys. |
| Change permissions | Edit other members' permissions. |
| Enable & disable apps | Turn apps on and off for the entity. |
| Edit entity settings | Change the entity's general settings. |
Owners and admins hold all of these implicitly.
How effective access is computed
When someone acts in your workspace, Zingasuite resolves what they are allowed to do in this order:
- Owner or admin? If yes, access is granted — they bypass the remaining checks.
- Otherwise, per-object-type grants apply. The member must have the specific operation (view/create/edit/delete) granted for that object type. No grant means the action is denied.
- Row-level rules, where configured, can further narrow which specific records a member may see or change (for example, only their own records).
- If the request uses an API key, the key's scopes are applied as a final filter.
API keys never exceed the creator's access
This last point is a hard rule worth calling out. An API key is always created by a member, for an entity, and it acts as that member. At request time the key's scopes are intersected with the creating member's own permissions — so a key can only ever do a subset of what its creator can do. Widening a key's scopes can never grant more than the person who made it already has, and if that person's access is later reduced, their keys are reduced with them.
See API Keys to create and scope keys, and Users & Team Members to manage who holds which role.