Files
govoplan-helpdesk/docs/HELPDESK_DOMAIN_BOUNDARY.md
T

65 lines
2.1 KiB
Markdown

# Helpdesk Domain Boundary
## Purpose
Internal service desk workflows for IT, facilities, HR, finance, procurement, access requests, assignment, escalation, and resolution tracking.
## Owns
- helpdesk queue and service-category profiles
- SLA and escalation policy profiles
- IT/facilities service-desk defaults and reporting vocabulary
## Does Not Own
- canonical ticket identity, messages, assignment, and resolution state
- public ticket intake forms
- domain case adjudication
- asset inventory
## Integration Candidates
- tickets
- assets
- facilities
- mail
- notifications
- workflow
- files
- tasks
## Implemented Policy Overlay
The module persists only tenant configuration:
- ordered, active/inactive service profiles
- ticket-type and priority match criteria
- canonical queue references
- per-priority and default service-target minutes
- immutable, replay-safe configuration history and platform events
The administrative API and `/helpdesk` workspace require
`helpdesk:workspace:admin`. Each save carries an expected revision,
idempotency key, and explicit change reason. The shared action bar provides
Reload and New-profile actions, while create/edit dialogs keep dirty state
local until Save or Cancel.
## Ticket Routing Contract
Helpdesk provides Core's optional `tickets.routing` capability. Tickets sends a
bounded tenant, ticket, type, priority, title, receive time, optional queue
hint, and non-secret attributes. Helpdesk evaluates active profiles in sort
order and returns the first match's queue and calculated service target.
An explicit queue hint narrows matching to that queue. No match is a successful
result with an explanation; it does not reject or delay Ticket intake. Tickets
owns the resulting queue and target snapshot, lifecycle, assignment, and
history. Helpdesk never imports Tickets or persists a second ticket model.
## Data-subject Requests
`privacy.dsar.helpdesk` covers only Helpdesk-owned configuration actor
attribution. Profiles and their immutable history contain institutional policy,
not customer ticket data; evidence is retained and any correction is made by a
new authorized profile revision.