Core concepts

These concepts appear throughout the product, API, and agent documentation.

Tenant

A tenant is one customer's isolated Whagons environment. It owns its branding, users, teams, settings, workspaces, tasks, and enabled powerups.

A person may belong to more than one tenant. Permissions, API keys, and agent approvals always apply within a selected tenant.

User, role, and team

• A user is a person with access to the tenant.
• A role grants product permissions, such as viewing tasks or managing integrations.
• A team groups users around an operating responsibility, such as Housekeeping, Maintenance, Front Desk, or Store Operations.

Teams matter for task ownership, assignment, visibility, and status changes. A broad role does not automatically make every operational task visible.

Spot

A spot is a physical or logical location. Spots can be nested.

Examples include a property, building, floor, room, store, production line, vehicle, or equipment area. Tasks can point to a spot so work is tied to the place where it occurs.

Workspace

A workspace is an operating view where a team sees and manages related tasks. It can represent a department queue, project, shift, review lane, or cross-team control room.

A workspace can combine a task grid with filters, saved views, calendar or board views, chat, resources, whiteboards, and KPI cards.

Task

A task is the canonical record of operational work. It owns the title, description, location, status, priority, dates, comments, attachments, assignments, tags, forms, approvals, acknowledgments, and history associated with that work.

Whagons keeps one source task even when that task needs to appear in another workspace for approval or acknowledgment.

Task type

A task type—also called a category in the API—defines the policy around a class of work. It can determine the owning team, allowed templates, forms, approval behavior, statuses, priorities, and where tasks may be created.

Do not assume task type names are identical between tenants.

Template

A template is a reusable starting point for a task. It can provide instructions, default priority, expected duration, a form, default assignees, signature requirements, and other repeatable values.

Task types define the broad policy; templates define specific repeatable jobs within that policy.

Status and priority

• A status describes the task's lifecycle position, such as New, In Progress, Waiting, or Completed.
• A priority communicates operational urgency.

Both are tenant-configurable and can be limited by task type. Integrations should resolve their IDs instead of relying on a hard-coded English name.

Form and custom field

• A form collects structured responses and may be versioned, reviewed, scored, or shared publicly.
• A custom field adds tenant-defined data directly to tasks, task types, templates, or spots.

Use a form for a guided collection experience. Use custom fields when the value should behave like durable metadata on the task.

Approval and acknowledgment

• An approval asks an authorized person or group to accept or reject work.
• An acknowledgment asks a recipient to confirm they have read or received it.

Both can place the original task into an action-specific workspace context without creating a copied task.

SLA and workflow

• An SLA measures and escalates time commitments.
• A workflow reacts to events and conditions with automated actions.

Together they turn an ordinary task list into a controlled operating process.

Powerup

A powerup is an optional Whagons module layered on the shared tenant, user, workspace, and task foundation. Enabled powerups vary by tenant.

Continue with Workspaces and tasks, or use the Glossary as a quick reference.