Tasks

Overview

Tasks are the core of Ziptask. Work is organized into task lists (projects or checklists) that contain tasks (individual to-dos). Lists can be personal (owned by one member) or shared (assigned to multiple members).

Templates are reusable blueprints for lists — you build one once and spawn new lists from it on demand. Recurring lists are an optional layer on top of templates: a template can be given a schedule so new lists are spawned automatically. A template does not have to recur; it can be spawned manually whenever needed.

Task Lists

Who can create a list

Any member can create a personal list. Admin and Root can create a list and assign it to any member in the account. Team Admin can create and assign lists but only to members within their own teams — they cannot assign to members outside their team scope.

Who can see a list

Role	Visibility
User	Lists associated with any of their teams, plus lists they created or are assigned to (teams on). With teams off, only the lists they created or are assigned to. Lists the User created or is assigned to are editable; any others they can see are view only.
Team Admin	Lists associated with any of their teams, plus lists they created or are assigned to (teams on). Default visibility is team-scoped — same as Admin but limited to their team(s).
Admin	All lists in the account at all times (account scope — not restricted by team).
Root	All lists in the account at all times.

View-only lists: A User who can see a list but is not the creator or an assignee can view its tasks and progress but cannot add tasks, pick up tasks, or upload attachments. These lists are labelled “View only” in the list view.

Teams disabled. When teams_enabled is off, team associations are ignored and visibility falls back to each member’s role scope: Admin and Root (account scope) still see every list, while team-scoped members (the default User role) see only the lists they created or are assigned to. When teams_enabled is on, team-scoped members additionally see lists belonging to any of their teams; a member on multiple teams sees lists from all of those teams combined. Visibility always follows the member’s permission scope — never more than their role grants.

Lists with no team: If a list was created without a team (either before teams were enabled or by a member not on any team), it has no team association and is only visible to the creator and Root. An Admin or Root can open the list’s edit modal and assign it to a team to restore broader visibility.

List actions by role

Action	User	Team Admin	Admin / Root
Create a personal list	✓ (free tier: max 10 active lists)	✓	✓
Create and assign a list to members	✗	✓ (own team members only)	✓
Edit title / description / due date	Creator only	Creator only (team-scoped)	✓
Delete a list	Creator only	Creator only (team-scoped)	✓
Archive / unarchive a list	Creator only	Creator only (team-scoped)	✓
Add / remove member assignments	✗	✓ (own team members only)	✓

Managing assignees

Admin, Root, and Team Admin (within their team scope) can change who is assigned to a list. There are two ways to do it:

Manage members (quick): On the list detail page, tap the assignee avatars or the Manage members action in the assignees area to open a focused dialog for adding/removing people only. Changes save immediately and update everyone viewing the list in real time.
Edit list (full form): The list edit form also includes the assignee picker, alongside title, description, start date, due date, team, and tags. A list can carry an optional start date as well as a due date — the two mark the working window (e.g. starts Monday, due Friday). Start and due are picked with a combined date & time control and include a time of day — new starts default to 9 AM and dues to 5 PM in the account timezone. New lists default the start to today at 9 AM; clear it if a list has no distinct start. The start must be on or before the due. A list is overdue once its due date and time have passed (a list due at 5 PM becomes overdue at 5:01 PM, not at the start of the next day).

Both paths require assign permission. Team Admins can only add or remove members within their own teams; a regular User cannot change assignments and won’t see the Manage members action.

Recurring lists — who’s on every occurrence. A recurring list spawns a new copy on each schedule, and each new copy takes its assignees from the recurring series (the master), not from any single day’s list. So when you open Manage members on a recurring occurrence, a “This list repeats” banner at the top gives two toggles that control how far your changes reach:

Add new members to every occurrence — on by default. Anyone you add joins the series, so every future occurrence includes them. Turn it off to add someone to this occurrence only (e.g. a one-day substitute).
Remove members from every occurrence — off by default. Removing someone affects only this occurrence (e.g. a sick day). Turn it on to drop them from every future occurrence too.

The banner only appears on a recurring occurrence; on a normal list there’s nothing to keep in sync. The toggles apply to the people you actually add or remove in this session — an existing occurrence-only member you leave checked isn’t changed. To move someone who’s on a single occurrence onto the whole series, add them on the recurring list (the master) itself.

Archiving lists

Lists can be archived instead of deleted. Archived lists are hidden from the default view and do not count against the free tier active list cap. To see archived lists, tap Archived in the list page header — the view switches to show archived lists only. Archived lists remain fully navigable: tapping a card in the archived view opens the list detail where tasks and history can be reviewed.

Free tier active list cap: Free tier accounts can have up to 10 active (non-archived) lists at a time. Archiving a list frees up a slot. If a free tier account is at the cap, creating a new list or unarchiving a list is blocked until another list is archived.

Who can archive: The list creator, or Admin or Root can archive any list. Archiving preserves all list data, tasks, and history — nothing is deleted.

Project-linked lists: If a list is linked to a project, archiving it does not remove it from the project’s point or cost totals. All lists always count toward project rollups regardless of their archive status. A note to this effect is shown in the archive confirmation when the list belongs to a project.

Unarchiving: Both the Unarchive button on the archived list card and the Unarchive action in the list detail sidebar show a confirmation before restoring the list to active. On the detail page the sidebar action toggles between Archive and Unarchive based on the list’s current status.

Team field on task lists

Requires: teams_enabled feature flag

Every task list can optionally be associated with a team. When a list has a team, the team name appears as a badge on the list card and in the list detail sidebar.

When creating a list:

Situation	Behavior
Creating member is on exactly one team	List is automatically associated with that team
Creating member is on multiple teams	A Team picker appears in the create form; member chooses which team (or “No team”)
Creating member is on no team	List has no team association

When editing a list:

Admin and Root can change the team on any list they can manage. A regular User can change the team only on lists they own, and only to a team they currently belong to. Selecting “No team” is allowed and clears the team association.

When teams_enabled is off, the team picker, team badge on cards, and team section in the detail sidebar are all hidden. Existing team associations are preserved and restored if the flag is re-enabled.

Mine / All scope toggle

The task list page has a Mine | All toggle that filters which lists are shown.

Scope	Shows
Mine	Lists the member created or is assigned to
All	All lists the member has visibility to (full account or team, per the rules above)

Default scope by role (first time only):

User → defaults to Mine
Admin / Root → defaults to All

The chosen scope is remembered per person, on that device — once a member switches to All, the page opens on All next time, until they change it again. The role default above applies only before a member has made a choice. Switching scope reloads the list from page 1; pull-to-refresh and infinite scroll both respect the current scope.

Empty “Mine” view. In accounts that assign work by team rather than to individuals, a crew member’s Mine view can be empty — they didn’t create the lists and aren’t individually assigned, so the lists belong to their team, not to them directly. When Mine is empty, the page shows a short explanation and a View all lists button that switches to All, where their team’s lists appear. (With teams turned off, the same button simply switches to All to show every list the member can see.)

Filters are remembered too. The sort order, due-date filter, tag filters, and the archived toggle are also remembered per person on that device, so the list reopens the way the member last left it. Only the free-text search is not remembered — it clears each session.

List status

A list’s overall status is derived from its tasks:

Not Started — no tasks, or all tasks are TODO
In Progress — at least one task is DOING or COMPLETED but not all completed
Completed — all tasks are COMPLETED

Status color indicators

Each list card shows a colored left border stripe and a progress badge that reflect the list’s current status:

Status	Left border stripe	Progress badge
Not Started	Gray (faded)	Gray
In Progress	Amber	Amber
Completed	Teal	Teal

Tasks

Tasks live inside a list. The list creator, a Team Admin on the list’s team, and Admin / Root can add and edit tasks. Assignees work on existing tasks (pick up, complete, submit for approval) but do not add or edit them. Members viewing a list in read-only mode (team visibility, not assigned) can see tasks but cannot interact with them — that’s by design: an admin assigns the list to the people doing it (see “Working tasks vs. managing them” below).

Working tasks vs. managing them. Doing a task and editing a task are separate permissions. A role can grant pick up & complete (the everyday crew action — claim, complete, release, comment, upload proof) without granting the ability to add, edit, or delete tasks or rename the list — and vice versa. For crew roles (User, Team User) this “do the work” ability is own-scoped: it applies to lists they created or were assigned to, so work is earned by assignment. The intended flow is that an Admin or Team Admin divides up and assigns each list to the crew, and those assignees then check the items off (the list stays management-read-only to them — no Add Task or rename — but the Pick up and Mark done buttons appear). Admins can build custom roles the same way — grant Task List Items act on its own, or pair it with update to also allow editing item text. An account that instead wants any team member to grab any of their team’s lists without an assignment step can clone a role and grant Task List Items act at team scope (trade-off: an off-shift team member could then sign work off too). Approving and reassigning tasks are never part of item work; they stay with Team Admin / Admin / Root.

Adding several tasks quickly: In the Add Task dialog, use Add & Create Another — or simply press Enter in the title field — to save the current task and immediately start a new one with the form cleared (the dialog stays open and the cursor returns to the title). This is the fastest way to build out a checklist. Add saves the task and closes the dialog as usual. Both honor the same task options (points, approval, photo requirement).

Task actions by role

Action	User — list creator	User — assignee only	Team Admin (own team)	User (view-only)	Admin / Root
Add a task	✓	✗	✓	✗	✓
Edit a task’s title / description	✓	✗	✓	✗	✓
Set task points, approval, or photo options	✗	✗	✓	✗	✓
Reassign a task to a different member	✗	✗	✓	✗	✓
Delete a task (TODO only)	✓	✗	✓	✗	✓
Pick up / change status of your own task	✓	✓	✓	✗	✓
Complete or reset a task someone else has	✓ (their list)	✗	✓	✗	✓
Submit for approval	✓	✓	✓	✗	✓
Approve / reject	✗	✗	✓	✗	✓

Team Admin authority applies to lists in their own team(s). Setting point values and the approval / photo toggles requires team or account scope — a plain User cannot set them even on a list they created. This keeps members from putting reward points on their own work to inflate their own balance.

Delete restriction: Tasks can only be deleted when they are in the TODO state. Tasks that have been picked up (DOING, PENDING_APPROVAL, COMPLETED) cannot be deleted; the list creator, a Team Admin on the list’s team, or an Admin or Root can reset them to TODO first if removal is needed.

Task status transitions

Without the approval flow (default):

Transition	Who can trigger	What happens
TODO → DOING	Any member assigned to the list (or an admin / team admin, or a custom role with `task_item:act` at the list’s scope)	Sets the task’s assignee to the current member; records start time
DOING → COMPLETED	The member who picked it up, the list creator, a Team Admin on the list’s team, or Admin / Root	Records who completed it and when; awards points if enabled
DOING → TODO	The member who picked it up, the list creator, a Team Admin on the list’s team, or Admin / Root	Clears the assignee and start time
COMPLETED → TODO	The list creator, a Team Admin on the list’s team, or Admin / Root	Clears all tracking fields; reverses points if enabled

Resetting a completed task asks for confirmation. Because a reset (COMPLETED → TODO) clears the completion record — who finished it and when — and reverses any points that were awarded, the app now shows a confirmation before reopening a completed task, so an accidental tap can’t silently roll back earned points. (If the reversal would take the member’s balance negative, a stronger “Points Warning” is shown instead.) Release (DOING → TODO) and approval actions are unaffected — they don’t remove a completion or points.

With approval required on a task (see Requires Approval below):

Transition	Who can trigger	What happens
DOING → PENDING_APPROVAL	The member who picked it up, or anyone who can manage the list	Submits the task for review; records submission time
PENDING_APPROVAL → COMPLETED	A Team Admin on the list’s team, or Admin / Root	Approves the task; awards points to the assignee
PENDING_APPROVAL → DOING	A Team Admin on the list’s team or Admin / Root (reject), or the assignee (withdraw)	Moves back to DOING so the worker can fix and resubmit
DOING → COMPLETED (bypass)	A Team Admin on the list’s team, or Admin / Root	Skips the approval gate and marks the task done directly

Task status colors

Each task row displays a status badge and a colored left border stripe:

Status	Badge color	Left border stripe
TODO	Gray	Gray (faded)
DOING	Amber	Amber
PENDING_APPROVAL	Sky blue	Sky blue
COMPLETED	Teal	Teal (row title is struck through and faded to indicate it is done)

Key rule: A plain User cannot act on a task they did not pick up — with one exception: the list creator can complete or reset any task on a list they created, even if someone else picked it up. A Team Admin can act on any task on their own team’s lists, and Admin or Root can act on any task in the account, to close out or reassign work on behalf of team members. Approving a task is not granted by ownership alone — it requires approval authority (Team Admin, Admin, or Root); a plain-User creator can complete their list’s tasks but cannot approve them.

Conflict handling: If two members try to act on the same task simultaneously, the second change is blocked and that member sees a notice, then the list refreshes automatically to show the current state.

Points on completion

When points_system is on, completing a task awards points to the member who completed it. Points are awarded to the assignee at the moment of completion (either direct completion or approval). Reversing a completion (COMPLETED → TODO) deducts those points automatically.

Approval & Photo Proof

Admin, Root, and Team Admin (on their own team’s lists) can set two independent options per task (in the Add/Edit Task form). Either can be used on its own — Require Photo/Document no longer depends on Requires Approval.

Toggle	Requires flag	What it does
Requires Approval	`approval_enabled`	Worker must submit the task for review; an approver — a Team Admin on the list’s team, or an Admin or Root — must approve before it becomes COMPLETED and points are awarded.
Require Photo / Document	`attachments_enabled`	At least one attachment must be on the task before it can be completed. If approval is also on, the attachment is required at the submit-for-approval step. Shown whenever attachments are enabled, independently of Requires Approval.

Both toggles default to off and are independent — you can require a photo with no approval (e.g. “snap a proof photo to finish the task”), require approval with no photo, both, or neither. They can be set when creating or editing a task, or on template tasks so the values carry over to every list spawned from that template.

Photo requirement applies to everyone, including admins — there is no admin bypass for it. To complete a task that requires a photo when none is available, an admin must first edit the task to turn the requirement off (or attach a file). This differs from the approval gate, which admins can bypass (see Admin bypass below).

Who receives notifications

When a worker submits for approval, everyone with approval authority (Team Admins on the list’s team, plus Admins and Root) receives a notification.
When an approver approves a task, the assignee receives a notification.
When an approver rejects a submission, the assignee receives a notification.
When a worker withdraws their own submission, no notification is sent.

Approver bypass

Approvers can skip the approval gate: while a task is DOING (even if approval is required), a Team Admin on the list’s team, or an Admin or Root, can tap Mark as done to go directly to COMPLETED. This is intentional — they can always act on behalf of the team. A plain-User list creator can complete tasks on their own list but, lacking approval authority, cannot bypass a task that requires approval.

Task Attachments

Requires: attachments_enabled feature flag

Members can attach files directly to individual tasks. This is separate from list-level attachments. Task attachments are useful for upload-before-submit workflows when both approval and attachment requirements are enabled.

Action	User	Admin / Root
View task attachments	✓ (on lists they can see)	✓
Upload task attachments	✓ (on lists they can see)	✓
Delete task attachments	Uploader only	✓

Tap the Attachments action on any task to view, upload, or remove files. On the phone apps you can Take a Photo with the camera or Choose File to attach an existing photo or document; on the web the file picker opens directly. The task row shows an attachment count badge when one or more files are present.

Inline thumbnails: tasks with attachments show a small, read-only thumbnail strip directly on the task in the task-list detail page — so proof-of-work photos are visible at a glance without opening each task. Tap a thumbnail to open the full file. Uploading and deleting still happen through the Attachments action. The strip updates live as others add or remove photos.

Templates and Recurring Lists

Requires: templates_enabled flag for templates; recurring_lists flag for recurring. Both are enabled automatically from Starter plan and above. On Free, neither feature is available.

Templates

A task list can be saved as a template. Templates are reusable blueprints — they don’t appear in the regular task list and cannot be worked on directly. Only Admin and Root can create or manage templates.

There are two ways to create one: start a blank template from the Templates page, or turn an existing list into one with Save as template, found in the actions on the list’s detail page. Save as template opens a short form pre-filled with the list’s title and description (both editable) and copies the list’s tasks into the new template — including each task’s points and its “requires a photo” / “requires approval” settings. Progress, assignees, due dates, comments, and attachments are working state and are not copied. Once created, a link on the confirmation takes you straight to the new template.

When a template is spawned, a new regular task list is created from it with all tasks, assignments, and tags copied in. Tasks are reset to TODO. Spawning can be done manually or automatically via a recurrence schedule.

The template’s detail page lists its tasks in order (drag to reorder). Each task shows its reward and effort points (when the points system is on) and a small icon marking any task that requires a photo or requires approval — so you can see at a glance what will carry over to every list spawned from the template. A summary of the template’s total reward and effort points appears alongside the task count.

Recurring lists

A template can be given a recurrence schedule so that new list instances are created automatically on a repeating cadence. The template itself is called the master list; the created copies are called instances. All instances are immediately workable when they appear — there is no “Upcoming” state.

Frequencies

Frequency	Cadence
Daily	Every day
Weekly	Every 7 days
Biweekly	Every 14 days
Monthly	Same day each month; if the due date falls on the last day of a month, subsequent instances land on the last day of each following month (e.g. Jan 31 → Feb 28/29 → Mar 31)

How instances are created

Instances are created on demand — the system never pre-creates future instances. When a period becomes due, one Active instance is created for that period. All instances are immediately Active and workable.

The system checks every hour and creates any instances whose period is now due.

Early unlock: When all tasks on an Active instance are completed, the system automatically creates the next period’s instance — members don’t have to wait for the next check.

Scheduled events on the calendar: The calendar shows future recurrence dates as scheduled events (displayed with a dashed border). These are not real lists yet — they are computed from the master’s schedule. Any member with list-create permission can tap a scheduled event and choose Activate Now to create the next instance immediately — this includes Admin, Root, Team Admin, and regular Users for lists they own or are assigned to.

Setting a recurrence schedule

The Set Schedule button appears on the master list’s detail page. Admin and Root can set a schedule at any time — the list does not need to be a template first.

Available schedules: Daily, Every other day, Every 3 days, Weekdays (Mon–Fri), Weekly, Every 2 weeks, and Monthly. Choosing Custom… (the last option in the schedule dropdown) offers two builders:

Interval — “Every N days / weekdays / weeks / months” for any interval up to 30 (e.g. every 5 days, every 2 weekdays, every 2 months).
Days — repeat on a chosen set of weekdays each week (e.g. every Tuesday and Thursday, or Mon/Wed/Fri). Pick one or more days from the S–M–T–W–T–F–S chips.
Weekdays repeats every business day and skips weekends — a weekday instance due on a Friday spawns the next one on Monday, never Saturday or Sunday. In Custom mode, weekdays counts business days only, so “every 2 weekdays” from a Friday lands on the following Tuesday (Saturday and Sunday don’t count). The start→due span of a weekday recurrence is also counted in working days: a two-working-day list that starts on a Friday is due the following Monday, not Saturday.
Days (specific weekdays) generates one list on each selected day, every week — e.g. Tue + Thu produces a list every Tuesday and every Thursday. The start date is the anchor; the first list starts on the next selected weekday on or after it.
Monthly preserves end-of-month behavior (a list starting the 31st lands on the last day of each month).
Start date (the anchor). Recurrence runs on the start date: each instance is created when its start day arrives. A list can also carry a due date — the deadline within the period — and the two together mark the working window (for example, starts Monday, due Friday); every generated instance keeps that same start→due span. The due date is optional: a list with only a start date simply recurs on that date with no deadline. Because scheduling anchors on the start date, a list with no start date is asked for one when you set its schedule (it defaults to today) — that becomes the list’s start date.
Days are the account’s days. Recurrence uses the account timezone (Account Settings) to decide when a day begins, so a “daily” list fires on the account’s local calendar day and a same-day start/due stays a single day all year — including across daylight-saving changes. If the account timezone is blank it falls back to UTC.
Setting a schedule updates the recurrence rule. If the next instance’s start date is on or before today, an Active instance is created immediately.
No future instances are pre-created — the calendar shows scheduled placeholders instead.
Because instances are created at the moment they become due, any tasks added to the master list after the schedule is set will automatically appear in all future instances. There is no need to re-sync or update existing instances manually.

Ending a recurrence on a date

When setting or changing a schedule, the Ends option controls how long the recurrence runs:

Never (the default) — the list keeps generating instances until someone stops it. This is how recurring lists have always worked.
On date — pick an end date, and the recurrence stops on its own once that date passes.

The end date is inclusive: an instance whose start falls on the end date is still created, and none are generated after it. Setting an end date does not delete anything — it only stops future instances; instances already created remain as standalone lists. Once the end date passes, the list simply stops creating new copies — the schedule itself is left in place, so the list keeps showing “Repeats … · Ends {date}” as a record of what it did (it is not cleared, and existing instances are untouched). The end date uses the account timezone, like the rest of scheduling, and must be on or after the list’s start date. To end a recurrence immediately instead of on a date, use Stop Recurrence (below), which removes the schedule entirely.

Actions by role

Action	User (own/assigned)	Admin / Root
Set a recurrence schedule	✗	✓
Change the recurrence schedule	✗	✓
Stop recurrence	✗	✓
View scheduled (upcoming) events on the calendar	✓	✓
Activate the next instance immediately	✓ (own/assigned only)	✓
Delete a list (with scope choice for recurring)	Creator only	✓

Stopping recurrence

The Stop Recurrence button on the master list’s detail page disarms the schedule. No lists are deleted — the master’s recurrence schedule is cleared and no new instances will be created. Existing Active and completed instances are not affected; they remain as standalone lists and retain their history.

Changing the schedule

The Change Schedule button updates the recurrence going forward. It opens pre-filled with the current schedule (the frequency or specific days), so only the parts that are changed need adjusting. The head start is no longer set here — it comes from the list’s own start and due dates. No existing instances are deleted or modified. Future scheduled events on the calendar update to reflect the new cadence automatically.

Navigating between master and instances

An instance’s detail page shows a “Part of recurring series” link that navigates back to the master list, making it easy to manage the schedule without hunting for the original template.

Deleting a recurring master list

When the master list is deleted, the system prompts for scope:

Choice	What happens
Just this list	Deletes only the master. Existing instances become standalone lists and are not affected. No new instances will be created since the master is gone.
Entire series	Deletes the master and every instance at any status — including currently Active lists. This is irreversible.

Deleting a recurring instance

When an individual instance is deleted, the system also prompts for scope:

Choice	What happens
Just this instance	Removes only this instance. The master and the schedule are unaffected; the series continues normally.
Entire series	Deletes the master and every instance at any status — including currently Active lists. This is irreversible.

Reminders

Requires: reminders_enabled feature flag (on by default for every plan)

Add reminders to a task list that notify people before it starts or is due — a preset (day/week before start or due) or a custom date & time — each aimed at everyone on the list or specific members, with an optional note. Reminders fire by push + in-app notification, and an Upcoming reminders widget shows on the dashboard. See Reminders for the full guide.

List Attachments

Requires: attachments_enabled feature flag

When enabled, members can attach files (images and documents) to task lists. Supported types include JPEG, PNG, WebP, and common document formats. Images are automatically resized when uploaded. Each file has a size limit of 20 MB, with a maximum of 20 attachments per list. On the phone apps, tap the add tile to Take a Photo with the camera or Choose File; on the web the file picker opens directly.

Action	User	Admin / Root
View attachments	✓ (on lists they can see)	✓
Upload attachments	✓ (on lists they can see)	✓
Delete attachments	Creator of the attachment only	✓

Comments

Members can leave comments on tasks to add context, ask questions, or record notes. Comments are visible to anyone who can see the list. There is no editing — to correct a comment, delete it and re-post.

Action	User	Admin / Root
View comments	✓ (on lists they can see)	✓
Add a comment	✓ (on lists they can see)	✓
Delete own comment	✓	✓
Delete any comment	✗	✓

Support notes

If a Team Admin says they can’t assign a member to a list, check that the target member belongs to one of the Team Admin’s teams. Team Admins can only assign within their own team scope — they cannot assign account-wide.
Assignees can be managed two ways: the quick Manage members dialog from the list detail (tap the assignee avatars), or the full edit form. Both require assign permission, so a regular User won’t see Manage members. Assignee changes made by one person update other open viewers of that list in real time.
To add many tasks at once, use Add & Create Another in the Add Task dialog — it keeps the dialog open and clears the form after each save instead of reopening it per task.
If a User can’t see a list, first check the Mine / All toggle — lists they can see but aren’t assigned to only appear in All. If the list is still missing and teams_enabled is on, check the list’s team association (visible in the list detail sidebar). A list is visible to a member only if the list’s team matches one of the teams the member belongs to. Lists with no team association are only visible to the creator and Root.
If a member was recently added to a team but still can’t see that team’s lists, they may need to refresh the app. If the issue persists, verify their team membership is saved on the Teams page.
If a User can’t complete a task they picked up, check they are on the list’s assignee list.
If a User says they can edit tasks but cannot delete them, that is correct — only the list creator (or Admin or Root) can delete tasks. Assignees who are not the list creator have edit but not delete rights on tasks.
If a User can’t edit or delete their own personal list, verify they are the list creator. Users can fully edit and delete task lists they created.
If a User gets “This task requires approval” when trying to mark done, the task has approval required. The member must use Submit for Approval instead; only an admin can approve it.
If a User can’t submit for approval or can’t complete a task because “attachment required”, the task has Require Photo/Document on — they must upload at least one file via the Attachments action first. This requirement applies to everyone, including admins (no bypass); to finish without a photo, an admin must edit the task and turn the requirement off.
If a task is stuck in DOING and the member is unavailable, an Admin or Root can reset it to TODO.
Templates and their spawned instances are separate — editing a template after spawning does not change already-spawned lists.
The Requires Approval toggle only appears on the task form when approval_enabled is on; the Require Photo/Document toggle appears whenever attachments_enabled is on, independently of approval.
If an instance is missing after a period should have started, instances are created automatically within the hour. If it still hasn’t appeared, an Admin or Root can manually trigger creation via the Activate Next Instance button on the master list’s detail page, or by tapping the scheduled event on the calendar and choosing Activate Now.
Stopping recurrence does not delete any lists — it only clears the recurrence rule on the master. All existing instances stay as standalone Active lists. If an admin wants to remove them, they must delete each one manually.
If an account downgrades to Free (or a subscription is cancelled or lapses on a failed payment), recurring lists stop generating new instances automatically, since recurring_lists is a paid feature. No lists are deleted — existing masters and instances stay as-is, and the schedule resumes on its own if the account re-subscribes to a plan that includes recurring lists.
If a member reports that a list has disappeared, check whether it was archived. Archived lists are hidden from the default view and only visible when the Archived toggle is active.
Archiving a project-linked list does not affect that project’s point or cost totals. The list’s data always counts toward the project rollup regardless of archive status.
Changing a recurrence schedule does not affect existing instances. Only future periods are recalculated.
The monthly frequency preserves end-of-month behavior: a list due Jan 31 will always land on the last day of each month, not a fixed day-31 (which would skip months that don’t have 31 days).