Work Management

Tasks

Manage task workbench, calendars, categories, task form schemas, subtasks, and completion.

Tasks

Tasks covers The operational work layer: workbench, list, calendar, schedules, categories, form schema, subtasks, comments, and completion. Use this page when you are configuring the live product surface, planning a rollout, or checking why users see different data from what an administrator sees.

What this surface is

  • Primary purpose: The operational work layer: workbench, list, calendar, schedules, categories, form schema, subtasks, comments, and completion.
  • Where staff start: Staff work from /tasks/tasks, /tasks/list, /tasks/calendar, and /tasks/schedule.
  • Where admins configure it: Admins configure categories at /tasks/categories, category fields at /tasks/categories/:categoryId/form-schema, and task settings at /tasks/settings.
  • Runtime/detail surface: Task detail pages include assignment, due dates, status, subtasks, comments, related records, and activity.
  • Platform connections: Tasks are created manually, from records and tickets, by schedules, and by workflow nodes.

Common workflows

WorkflowWhat happensWhere to check
Decide whetherDecide whether the work is a one-off task, a recurring schedule, a workflow-created task, or a subtaskConfirm in the product route above before publishing.
Create categoriesCreate categories for distinct work types such as onboarding, follow-up, compliance review, or maintenanceConfirm in the product route above before publishing.
Configure eachConfigure each category schema so task forms capture only the fields needed for that work typeConfirm in the product route above before publishing.
Set assignee,Set assignee, team, deadline, priority, recurrence, and related object rules before inviting usersConfirm in the product route above before publishing.

Configure it

  1. Decide whether the work is a one-off task, a recurring schedule, a workflow-created task, or a subtask.
  2. Create categories for distinct work types such as onboarding, follow-up, compliance review, or maintenance.
  3. Configure each category schema so task forms capture only the fields needed for that work type.
  4. Set assignee, team, deadline, priority, recurrence, and related object rules before inviting users.
  5. Check calendar and list views to ensure due dates and filters make sense for operators.
  6. Use subtasks for checklists that belong inside one accountable task, not as separate process owners.
  7. Test reminders, comments, related records, and completion rules with a non-admin user.
  8. Review dashboards after test completion to confirm counts, overdue status, and team metrics.

Configuration options

OptionUse whenNotes
WorkbenchOperators need a daily queueRoute: /tasks/tasks.
ListManagers need filtering and export-like reviewRoute: /tasks/list.
CalendarDue dates and appointments are the main controlRoute: /tasks/calendar.
ScheduleWork repeats on a cadenceRoute: /tasks/schedule.
Category schemaDifferent task types need different fieldsRoute: /tasks/categories/:categoryId/form-schema.
ApprovalsA task is part of a decision flowSee /tasks/approvals and /approvals/list.

Operating notes

  • Keep task categories small enough that dashboards and reports remain meaningful.
  • Use teams when ownership can rotate; use named users when one person is accountable.
  • Recurring schedules should have clear pause and ownership rules for holidays or absences.
  • Overdue counts depend on deadline and completion state, so avoid using completion as a general status note.
  • Tasks linked to records or tickets should keep the parent context visible to reduce duplicate data entry.
  • If users cannot see tasks, check role permissions, team membership, assigned user, and filters.
  • Use comments for collaboration and schema fields for values that need filtering or reporting.
  • Avoid creating workflow tasks without a clear escalation or completion owner.
  • Archive or close stale task categories before creating replacements with similar names.
  • Review task metrics regularly; they are a useful early warning for overloaded teams.

For developers

Use the developer and reference pages when this configuration is read or changed by code, scripts, widgets, embeds, API clients, or webhooks.