Teams and Worklists

A team is a group of people who handle a kind of work. A worklist is what one person or team currently has to do.

Where to find it

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

Why teams rather than groups

Security groups answer what somebody may do. Teams answer who does the work. They overlap but are not the same: a manager may have rights over a team's cases without being the person who handles them, and a worklist built from permissions would put every case in that manager's list.

Allocation

Work is allocated to a team and 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, which is where work goes to be forgotten.

Worklists

A worklist should be short enough to act on. If a caseworker's list is 300 items, it is a database query rather than a plan for the day. Filter by what is actionable now — due, overdue, awaiting them specifically — and let the full caseload be a separate view.

Housekeeping

The Worklist Housekeeping task expires stale delegations and tidies the queues. It ships disabled; enable it hourly. The background work is enabled under Architect Panel → Automation → Tasks. Everything ships disabled.