Permissions

Overview

Ziptask uses a flexible permission model. Each role owns a set of resource + action + scope permissions that determine exactly what its members can see and do. System roles cover the most common configurations out of the box; custom roles let Root users build tailored access for their specific workflows.

Permission Scopes

Each permission has a scope that controls what the role can act on:

Scope	Meaning
`account`	Anything within the account — no ownership restriction
`team`	Anything belonging to the member’s teams, plus any they created or are directly assigned to
`own`	Only what the member created or is directly assigned to

System Roles

All accounts include five built-in system roles. They cannot be edited or deleted.

Root

One per account. Full access to every resource including billing, feature flags, and role management.

What Root can do: Everything Admin can do, plus toggle feature flags, manage billing and subscription, create and delete custom roles, and change any member’s role.

Admin

What Admin can do: See all task lists across the account. Create, edit, delete, assign members to, and approve items on any list. Manage all teams, members, projects, tags, and templates. View reports and account-wide activity. View the store.

Resource	Actions	Scope
Task Lists	read, create, update, delete, assign, approve	account
Task List Items	read, create, update, delete, act	account
Teams	read, create, update, delete	account
Members	read, create, update, delete	account
Projects	read, create, update	account
Templates	read, create, update, delete	account
Tags	read, create, update, delete	account
Reports, Activity Log, Store	read	account

Team Admin

Requires: teams_enabled feature flag on.

What Team Admin can do: Fully manage task lists, items, and team membership within their own team(s). See all members and account-level resources (templates, tags, store) but cannot create or modify them. Cannot create or manage projects — that is an Admin/Root responsibility.

Resource	Read scope	Write scope (create / update / delete / assign / approve)
Task Lists	team	team
Task List Items	team	team (create / update / delete / act)
Teams	account	team (own teams only)
Members	account	— (read-only)
Templates	account	— (read-only)
Tags	account	— (read-only)
Attachments	team	team
Reports, Activity Log	team	—
Store	account	—

Team User

Requires: teams_enabled feature flag on.

What Team User can do: See all task lists belonging to their teams. Create and manage their own lists. Pick up, complete, comment on, and upload attachments to lists they created or are assigned to by an admin. Apply and create tags to organize their lists. Browse and redeem from the store. Cannot approve items, manage templates, rename or delete account tags, or see lists outside their teams. Seeing a team’s list does not by itself let them work it — an admin assigns the work (see “Item work follows assignment” below).

Resource	Actions	Scope
Task Lists	read	team
Task Lists	create, update, delete	own
Task List Items	read	team
Task List Items	create, update, delete, act	own
Teams	read	team
Members	read	account
Templates	read	account
Tags	read, create	account
Store	read	account

User

What User can do: See and manage task lists they created or are directly assigned to. Pick up, complete, comment on, and upload attachments to those lists. View the full member directory, available templates, and the store. Cannot see other members’ private lists, cannot approve items, cannot manage any account-level resources.

Resource	Actions	Scope
Task Lists	read, create, update, delete	own
Task List Items	read, create, update, delete, act	own
Members	read	account
Templates	read	account
Tags	read, create	account
Billing	read	account
Store	read	account

What permissions control

Task list access and item interactions

There are two related resources. Task List permissions govern the list as a container — creating it, renaming it, adding or removing items, scheduling recurrence. Task List Items permissions govern the work inside a list — picking up, completing, commenting, and uploading proof. Splitting them lets a role do the work without being able to restructure the list.

For backward compatibility, anyone who can update a task list can still do everything to its items, so roles that predate this split keep working unchanged. The item resource simply lets you grant item work on its own.

Task List permission	What it unlocks
`read`	See the list and its items, comments, and attachments
`create`	Create new task lists
`update`	Rename/edit the list, add and edit items, and (via back-compat) all item work below
`delete`	Delete a task list
`assign`	Add or remove member assignments on a list
`approve`	Approve or reject items submitted for approval; reset completed items

Task List Items permission	What it unlocks
`read`	See the list’s items, comments, and attachments (falls back to Task List `read`)
`act`	Pick up & complete — claim an item, complete it, release it, comment, upload proof
`create`	Add new items to a list
`update`	Edit item text/settings and reopen (reset) a completed item
`delete`	Delete items

The key pairing is act vs update: act lets a member do an item (the everyday crew action), while update lets them change the item’s text or settings. A role with act but not update can complete a checklist without being able to edit or rewrite it. Item approval/rejection stays on task_list:approve, and reassigning an item to someone else stays on task_list:assign — neither is part of the item resource.

Item work follows assignment

Item work is scoped like everything else: an own-scope member (User, Team User) can pick up and complete items only on lists they created or were assigned to — not on every list they can merely see. This is deliberate: work is earned by assignment, so an admin or team admin divides up and assigns each list to the people doing it, and only those people (plus admins) can check items off. A Team User can see all their teams’ lists but cannot complete one until an admin assigns it to them.

A list can still be management-read-only while its items are workable: a member assigned to a list they didn’t create can’t rename it or add items (management), but can pick up and complete the existing items (work). Both statuses are per-member, per-list — the item-work buttons appear whenever the member can act on that list.

For accounts that instead want any team member to grab any of their team’s lists without an assignment step, clone a role and grant task_item:act:team. (Trade-off: that also lets a team member who isn’t on shift that day sign items off, so most accounts should prefer assignment.)

Custom Roles

Requires: Starter plan or above.

Root users can create custom roles from the Roles page (accessible via the Roles nav item in the sidebar). Custom roles work identically to system roles — they own a set of resource + action + scope permissions and are assigned to members via the invite flow or the member detail page.

Cloning a role. Any role’s detail page has a Clone button that starts a new custom role pre-filled with that role’s name (prefixed “Copy ”), description, and full permission matrix — you then adjust it and save. This is the fastest way to make a small variation on an existing role, and the only way to base a role on a system role (which can’t be edited): for example, clone Admin and switch on Project Costing to get an “admin who can also see costing.” Cloning is available wherever creating a role is, on both system and custom roles. Because billing and feature flags are Root-only, cloning a role that has them (like Root) leaves those out of the copy — the new role gets everything else.

Permissions available to custom roles:

Resource	Available actions	Scope restriction
Task Lists	read, create, update, delete, assign, approve	own / team / account
Task List Items	read, create, update, delete, act	own / team / account
Projects	read, create, update, delete	own / account
Teams	read, create, update, delete	team / account
Members	read, create, update, delete	team / account
Templates	read, create, update, delete	account only
Tags	read, create, update, delete	account only
Reports	read	own / team / account
Activity Log	read	own / team / account
Project Costing	read, manage	own / account
Store	read, create, update, delete	account only
Roles	read, create, update, delete	account only

Billing and feature flag permissions are not available to custom roles — those remain exclusive to Root.

Note on attachments: Attachment access is not a separate permission. Uploading and viewing attachments on a task list is governed by the member’s Task List permissions — update scope grants the ability to upload and delete their own attachments; update:account additionally allows deleting any member’s attachments.

Account-only resources: Templates, Tags, Store, and Roles do not have a meaningful own or team scope. The permission grid restricts these to account scope only.

Team/account-only resources: Teams and Members have no individual owner, so own scope is not available. The permission grid offers team and account scope only.

Project Costing scope: own means the member can only view cost data for projects where they are the assigned project manager. account grants visibility into cost data for all projects. read shows the project’s cost figures and its expenses; manage additionally allows adding, editing, and deleting expenses. Both default to Root only.

Scope cascade rule: Setting any write action to a scope automatically raises the read scope to at least the same level (e.g. setting update = team forces read ≥ team).

Deleting custom roles: Deleting a role that has members assigned shows a warning indicating how many members will be affected. On confirmation, the role is deleted and those members’ role assignment is cleared — they will have no role until Root reassigns them.

When changes take effect: After editing a custom role, members will see the updated permissions the next time they log in — or within about 15 minutes.

Support Notes

Roles are assigned per account membership. A user can have different roles in different accounts.
teams_enabled must be on for Team Admin and Team User to appear as options in the role picker. If an admin cannot see those roles when inviting a member, check the feature flag in Account Settings.
Item approval — approving or rejecting a submitted item — requires task_list:approve. Root and Admin have it at account scope; Team Admin has it at team scope (own teams only). It is deliberately not part of the Task List Items resource. If a custom role needs approval authority, add the appropriate task_list:approve grant.
Reopening a completed item (reset to to-do) requires task_item:update or the broad task_list:update — it counts as editing, not as doing the work, so an act-only role cannot reset items.
A member assigned to a list they didn’t create can still work its items — pick up, complete, comment, upload — even though management controls (rename, add items) stay hidden. Assignment is what grants the work; simply being able to see a team’s list does not. To let a Team User complete a list, an admin assigns it to them (assigning a recurring master carries the assignment to every future instance).
After editing a custom role, members will see the updated permissions the next time they log in (or within about 15 minutes).
Custom roles are available on Starter plan and above. The Roles page is accessible to Root on all plans but shows an upgrade prompt instead of the New Role button on Free.