Teams, Allocation & Delegation

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.

Delegation and Cover

Delegation hands one person's work to another for a period. It is how leave, sickness and secondment are covered without reassigning every case individually and then reassigning them all back.

Where to find it

Architect Panel → Automation:

• Delegations — who is covering for whom, and until when
• Worklist — the console where cover is visible in the in-tray

Delegate for a period, always

A delegation carries a start and an end. That matters far more than it appears: a delegation without an end is a permanent grant somebody set up for a fortnight two years ago and never removed. Nobody notices, because nothing about it looks wrong — right up until an audit asks why a former colleague's deputy still sees their caseload.

Set the end date when you set the start date, every time.

Delegation is not transfer

The original owner remains the owner. The delegation is visible as a delegation, so the record shows who acted and on whose behalf. That distinction survives into the audit trail, which is what you need when somebody asks who made a decision during a period of cover.

Where the intention is genuinely to hand a case over permanently, reallocate it instead. Using an open-ended delegation as a transfer produces a caseload nobody can report on accurately.

What gets delegated

Delegation covers the worklist — what appears in the deputy's in-tray. It does not silently grant access to records the deputy could not otherwise open: where a case is classified or restricted by record access, those controls still apply. That is deliberate, and it means cover for a colleague who handles sensitive work needs the access granting as well as the delegation setting up.

Expiry

The Worklist Housekeeping task expires delegations whose period has ended. Without it running, cover set up for a fortnight quietly persists indefinitely — the end date is recorded but nothing acts on it. Enable it hourly under Automation → Tasks.

Practical timing

Set the delegation up before the leave starts rather than on the final afternoon, and let it run a day past the return so anything arriving on the last morning is still covered. Both are small habits that remove a whole category of "it was in their in-tray while they were away" problems.

Worked example — a legal team over Christmas

Three fee earners are away across the holiday. Each delegates to the duty solicitor from 20 December to 5 January. The duty solicitor's in-tray shows their own matters plus the three delegated caseloads, marked as delegated. On 5 January the delegations expire by themselves. The two matters that were classified needed an explicit record-access grant as well, which was done at the same time and removed on return.

Recommendations

• Review active delegations monthly. The list should be short. Anything on it that surprises you is worth asking about.
• Delegate to a named person, not a team, where accountability matters — "the team was covering" is not an answer to a complaint.
• Check the deputy can actually open the work. A delegated in-tray full of records they cannot read is worse than no cover, because it looks handled.
• Do not delegate indefinitely to cover a vacancy. Reallocate; a vacancy is a resourcing fact and should be visible as one.