Workflows and controls

Whagons separates the task itself from the policies that shape it. This lets teams change an operating rule without rebuilding every task screen.

Recommended setup order

For a new operating process, configure in this order:

1. Teams and spots — decide who owns the work and where it happens.
2. Task type — define the broad class of work and its owning team.
3. Workspace — decide where that work is visible and managed.
4. Statuses and priorities — define lifecycle and urgency.
5. Templates — create the repeatable jobs users should choose.
6. Forms and custom fields — collect the required evidence and metadata.
7. SLAs and transitions — add timing commitments and legal status moves.
8. Approvals and acknowledgments — add human decisions or receipt confirmation.
9. Workflows — automate reactions once the underlying model is stable.

Templates

Templates reduce variation at task creation. A template can carry instructions, expected duration, form association, default priority, default users, signature requirements, and location behavior.

Use clear, action-oriented template names. “Inspect guest room” is more useful than “Inspection.”

Forms

Forms support guided, structured collection. Current form designs can include short and long text, numbers, selection controls, lists, dates and times, images, signatures, barcodes, sections, fixed content, tables, timers, and GPS capture.

Forms are versioned so existing submissions keep the structure they were completed against.

Custom fields

Custom fields are useful for values that should be filterable or visible directly on task records, such as cost center, asset number, guest impact, inspection score, or external reference.

Fields can be assigned through task types or templates and may have formulas or validation rules.

Status transitions

Status-transition groups define which lifecycle moves are valid. A user or integration may have permission to change status and still be blocked from making an invalid transition.

Status changes can also be constrained by owning-team membership, pending approvals, and field-level policy.

SLAs

SLAs add service timing and escalation. They can measure response or resolution commitments and notify or escalate when thresholds are approached or missed.

Approvals

Approval policies can support sequential or parallel review, minimum approval counts, required comments or signatures, deadlines, conditional triggers, and outcome actions.

An approval is a decision about the source task. It is not a separate copy of the work.

Acknowledgments

Acknowledgments are suited to broadcasts, handoffs, safety notices, and tasks that require confirmed receipt rather than an accept/reject decision. Audiences may target users, teams, roles, or location-based groups.

Workflows

Workflows listen for events such as task creation, updates, status changes, assignment, completion, approval, rejection, or acknowledgment. Conditions can narrow the trigger by workspace, task type, template, team, status, priority, assignee, creator, form, SLA, or tag.

Actions can update work, create follow-up tasks, assign users, send messages or email, share to teams, request acknowledgment, or call an integration webhook when configured.

Start with the smallest rule that solves the operational need. Add branches only after the basic path is observable and reliable.