Work Items
A work item is a piece of work: a task, a job, a case, a request. Items nest, so a job can hold sub-jobs and those can hold tasks. They move through stages (see Pipelines), can be assigned to a person or a group, and can be created from a form somebody outside your organisation filled in.
Where to find it
| Screen | Where it lives | What it is for |
|---|---|---|
Work — /work | the sidebar | the board, the list and My Work |
Work item types — /admin/work-item-types | Settings → Work & scheduling → Work item types | what a kind of work is called, its status lanes, what guests may see |
Work item intake — /admin/work-item-intake | Settings → Work & scheduling → Work item intake | turning form answers into work items |
/work needs permission to read work items; the two admin pages need their own view permissions, and changing intake rules needs the intake manage permission in an elevated session.
The three ways to look at work
My Work
Your own plate, in four groups: Overdue, Due soon, Assigned to me, and Waiting for a group member to claim. The last one is the useful one: items assigned to a group rather than a person sit there until somebody takes them. Press Claim and the item is yours — the page confirms claimed — it is on your plate now.
Show done reveals the finished ones. If your login has no contact identity in this space, the page says so plainly — nothing can be assigned to you here, but items you can claim still show.
Work board
A column per pipeline stage, with cards you drag between them. Filter by Type, Pipeline, Assigned to me, or search titles. Add an item straight into a column with the inline Add box. Show done again reveals terminal items.
Two empty states are worth knowing because they are not errors:
- stage columns appear once an item rides this pipeline — nothing matches your filters yet;
- these items carry no pipeline stages yet — attach a pipeline from an item to see columns — the items exist but none of them is on a pipeline.
A column shows its work-in-progress limit where its pipeline sets one, and a move the pipeline refuses is refused on the board too, in the pipeline's own words.
Work items list
The ordinary list surface — sortable, filterable, with saved views (see Working with Lists). It rides the view engine, so it needs a work-items view to exist. If the space has none, the page says so and offers to create the work-items view for you. If you lack the permission the view engine needs, it says that instead, and points you at the board and My Work, which do not need it.
Work item types
A type is what a kind of work is called at each level, which pipeline it rides by default, what its status lanes are, and what an outside person may see. Global types are shared by every space; Copy to this space makes an editable version of one.
Levels
Level names, top to bottom — comma separated. A type called "Project, Phase, Task" names the root a Project, its children Phases, and theirs Tasks. The last name repeats for anything deeper.
Status lanes
A type can carry several independent status lanes beside its pipeline stage. Each lane takes its values from a value list:
- a single-value lane holds one flag at a time — an approval state, for example;
- a multi-value lane stacks — exceptions, flags, warnings.
A lane can name a permission key, and then only people holding it may set flags in that lane.
Other settings on a type
| Setting | What it does |
|---|---|
| Default pipeline | the pipeline new items of this type ride |
| Time entries billable by default | the default for time logged on these items |
| Auto-shift dependent dates | moving one date moves the dates that depend on it |
| Guest mode default / Guest visibility default | what an outside person sees by default — see Guest Access |
| Icon and Color | how items of this type read on the board |
Guest-visible fields
Deny by default: a field or section an outside person may see needs a row here. Leave Level blank for every level, or give a number to scope it to one depth (0 is the root).
Blueprints: stamping out a whole structure
A blueprint is a tree of items you create in one go — a standard job with its standard phases and tasks. Each node carries a Title, a Type, its Level (indentation), Start +days and Due +days offsets from a start date you pick, an Assignee (a contact or a data group) and a Checklist.
Stamp out… asks for a start date and, optionally, a parent item, then shows you a review before creating screen. Nothing is written until you confirm: adjust titles, dates and assignees, or skip a node — skipping a node skips its sub-nodes too. Each item is then created through the ordinary create door, so every rule that applies to a hand-made item applies to these.
Save as blueprint does the reverse: give it an existing work item's id and its whole subtree is captured as a blueprint you can rename.
Industry bundles
A bundle is a seeded starting point — a set of types, pipelines and blueprints for a kind of business. Apply turns them into ordinary, editable rows of your space; pieces already present are kept, so re-applying adds what is missing and disturbs nothing else. Each bundle's row says whether it is applied, partly applied or not applied, and names what is still pending.
Work item intake: forms into work items
Intake turns form answers into work items with ordered routing rules and a shared approvals inbox.
The rules
Rules are evaluated top to bottom, and the condition grammar is the same AND/OR grammar views and filters use. The rule that matters is the one about precedence: a later rule cannot replace an attribute an earlier match already set. First match per attribute wins. Each rule can set the target type, the pipeline, the stage, the priority and the approval gate.
The title
A title template uses {{answer.field_key}} placeholders — for example Request from {{answer.name}}. Inserted answer text is escaped, so a submitted answer can never inject markup into a title.
Answer mapping
Each answer maps to one writable work item column, or one standard non-sensitive custom field. Encrypted and computed fields are not offered — a public form must not be a way to write into either.
Approvals, and whether the approvers can actually see them
An approval gate can route to a named user, a permission, or a group. The page then does something unusual and useful: it checks whether those people can actually open the approvals inbox, and tells you in plain words when they cannot — ask a space admin to add them to the Approvers group, or ask a space admin to add the Approvers group to this space first. Add to Approvers fixes it from here. An approval gate whose approvers cannot open the inbox is a queue nobody drains, so it is worth the extra check.
Public links
A form can have one reusable public link:
- Mint new link creates it — and revokes any older link for that form, so there is never a second live URL you have forgotten about.
- Submissions per hour caps it (empty uses the space default,
0means unlimited). - A security question (CAPTCHA) can be required.
- Revoke links kills every active link for the form.
There is also a space-wide master switch. If it is off, the page says so — the space-wide public intake switch is off; turn it on in System settings before links work — rather than letting you mint a link that cannot work.
Held submissions
Submissions from addresses that are not yet allowed are held rather than dropped. The Held tab lists them, and bringing one in creates its work item (or sends it to approval). Saving a wider list of allowed addresses releases the held submissions from those addresses automatically.
Testing it
Submit sample answers runs the whole path. The page is explicit that this is a real submission: it creates a work item immediately or sends it to approval. There is no pretend mode — so test it where a real item is harmless.