AuralisDocs
OperationsQueue operations

Delete a team and unroute its tickets, on the record

Remove a team and record what that did to its tickets.

/v1/teams/{team_id}Admin
Operation id
delete_team
Access
An editor or a viewer is refused.
DELETE/v1/teams/{team_id}

Remove a team and record what that did to its tickets.

tickets.team_id is ON DELETE SET NULL, so the delete unroutes every ticket the team held. Before FR-80 that happened with nothing written anywhere: a week later an unrouted ticket is indistinguishable from one that was never routed, and the routing rule an operator is looking for is a row that no longer exists. Each affected non-terminal ticket therefore gets an assignment event naming the team that went away and the admin who removed it, with the same event kind and team_from/team_to shape a routing change already writes, so the timeline has one vocabulary for "this ticket moved" rather than two.

The ticket ids are read before the delete, because after it there is nothing left to join to.

Non-terminal tickets only. FR-80 says "every ticket the deletion unroutes", and this deliberately does less than that sentence. Read it before changing it back. ON DELETE SET NULL unroutes solved and closed tickets too, so the literal reading writes an event on every one of them: an unbounded write inside a single transaction, worst on precisely the workspaces that have been running longest, to say something about tickets nobody will route again. AC-91 asserts the non-terminal set and FR-80's own confirmation clause counts the non-terminal set, so that is the section's own notion of which tickets this deletion affects. It is the set written here and the set deletion-impact reports, and the two are one query so they cannot disagree.

Tenancy: the request is scoped to one workspace, and the credential presented is what selects it. A caller with no membership in that workspace is refused with 404, which is indistinguishable from a workspace that does not exist.

Authorisation: admin or owner. An editor or viewer receives 403 insufficient_role.

Access: Authorization: Bearer carrying either a realm access token or an API key. A key must hold the helpdesk-ops:write scope, and the workspace role of the person who owns it must meet the floor above.

Authorization

AuthorizationBearer <token>

A realm-issued access token, presented as Authorization: Bearer <token>. It acts as the person who signed in, and every operation resolves their workspace role live from the membership record.

In: header

Path Parameters

team_id*Team Id
Formatuuid

Response Body

application/json

application/json

application/json

application/json

curl -X DELETE "https://example.com/v1/teams/497f6eca-6276-4993-bfeb-53cbbbba6f08"
Empty