Teams, Allocation and Worklists
A team is a group of people who handle a kind of work. Allocation puts a case with one of them. A worklist is what one person or team currently has to do.
Where to find it
Architect Panel → Automation:
- Worklist — the console — caseloads, in-trays and what is unallocated
- Teams — the teams themselves
- Team Members — who belongs to each
- Allocation Rules — how work is routed automatically
The platform does not own an "assignee" column
This is the single most important thing to understand before configuring allocation, and it is unusual.
Every datastore here is user-defined, and a casework application already has a field for this — called Owner, Handler, Allocated To, Caseworker or Responsible Officer depending on who built it. Rather than adding a competing field, the platform is told which of your columns already means this. Everything reads and writes that column.
The practical consequence: allocation does nothing at all on a datastore you have not bound, and that is deliberate — it means the feature can be present without altering any existing application until you opt a datastore in.
The assignee is treated as a string
Your owner field might hold a user ID, an email address, a display name, or a link to a People datastore. The platform cannot know which, so it treats the value as an opaque string and compares it for equality.
That is enough for allocation, caseload counts and the in-tray, and it works with every one of those shapes. What it cannot do by itself is resolve an assignee back to a login — so the in-tray needs to know both who the caller is and what string their records are stamped with. If your owner field holds something other than the signed-in user's identifier, that relationship is configured once.
The practical advice: be consistent. A field holding "j.smith" on some rows and "Jane Smith" on others will produce a caseload that is quietly wrong, and nothing will warn you.
Why teams rather than security groups
Security groups answer what somebody may do. Teams answer who does the work. They overlap but are not the same: a service manager may have rights over every case in a service without being the person who handles any of them, and a worklist built from permissions would put all of it in their list.
Teams also feed record access — a team grant on a case resolves through team membership at the time of the check, so team changes propagate without touching records.
Allocation
Work is allocated to a team first, then to a person within it. Allocating to a team first is what makes the model resilient: an unallocated item sits visibly in a team queue rather than in nobody's list, and a team queue is something a manager looks at. Work allocated straight to individuals disappears when somebody is off.
Allocation Rules automate the routing — by case type, area, source or any field on the record. Use rules for the routine majority and leave the exceptions to a person; a rule set that tries to cover every case becomes impossible to reason about.
Worklists
A worklist should be short enough to act on. If a caseworker's list is three hundred items, it is a database query rather than a plan for the day.
Filter to what is actionable now — due, overdue, awaiting them specifically, newly allocated — and make the full caseload a separate view they can open when they want it. The in-tray answers "what should I do next"; the caseload answers "what am I carrying".
Worked example — a council licensing team
Applications land unallocated in the Licensing team queue. An allocation rule routes premises licences to the Premises team and personal licences to the general pool. Each officer's in-tray shows what is allocated to them and due this week; the team leader watches the unallocated queue, which should be near-empty by mid-morning. The owner field was already called "Case Officer" and holds the officer's username — it was bound, not replaced.
Housekeeping
The Worklist Housekeeping task expires stale delegations and tidies queues. It ships disabled; enable it hourly under Automation → Tasks.
Recommendations
- Bind the field you already have. Do not add a second owner column — you will end up maintaining both.
- Normalise the values before you go live. Mixed formats in the owner field are the commonest cause of a caseload that does not add up.
- Always route through a team. Direct-to-person allocation has no fallback.
- Watch the unallocated queue, not the individual lists. That is where work goes missing.