A service desk should receive work that someone can resolve, not a ticket for every failing report row. Define an incident episode around a customer, service, failure condition and time boundary. Keep raw observations in the evidence store and let the ticket describe the business consequence, owner and next decision.
Decide when a finding becomes work
A newly observed source is not automatically malicious, and a DMARC failure is not automatically a service outage. Compare the observation with the approved sender inventory, expected schedule and recent changes. Escalate a known billing flow that has lost alignment differently from an unowned low-volume source awaiting investigation.
RFC 9989 defines authentication alignment, while RFC 9990 describes report evidence. Neither supplies your business severity or service-desk policy. Write those decisions explicitly: what opens an episode, what adds evidence to an existing episode, what raises priority, and what closes it. Missing evidence should create a coverage question, not a fabricated recovery.
Use a destination-specific map
For an Autotask planning example, map the authenticated customer boundary to companyID, a concise service consequence to title, approved urgency to priority, the lifecycle state to status and the owning desk to queueID. The Tickets documentation describes create, query and update operations plus conditional field requirements. Retrieve active field choices and the customer's configuration before sending anything.
No numeric customer, queue, priority or status values are supplied here; retrieve the approved active values from the actual tenant. Queue requirements depend on ticket category, and dueDateTime or billingCodeID can be required by configuration. Keep a separate approved map of tenant to company and allowed queue. Never infer customer identity from an arbitrary incoming domain string.
Make retry and deduplication visible
Build a correlation key from tenant, domain, service, rule and episode. Persist it with the destination record identifier. A second observation should update evidence and occurrence counts unless the episode policy says it is new work. Use an outbox and a durable unique-key constraint in a real implementation so concurrent workers cannot both create the same incident.
Suppose the service desk may have created a ticket, but the client times out before receiving its ID. Keep the outcome uncertain and inspect the destination using the approved correlation method before another create. A local unique key prevents competing local work; it does not by itself prove that the remote service will reject duplicate creates. Use a supported remote idempotency facility where available or reconcile the actual destination state.
This is a hypothetical failure path, not an executed outbox, HTTP exchange or Autotask transaction. Test it alongside concurrent workers and a repeated observation, verifying the actual ticket count and preserved human notes rather than only the number of local queue records.
Close the loop without hiding recurrence
A technician marking a task complete is not proof that the sending flow recovered. Define closure evidence appropriate to the incident: an approved configuration, a real message test where authorized, and report observations interpreted with their delay and coverage limits. Keep an exception open if recovery cannot yet be demonstrated.
Record who accepted the result and what should reopen it. A subsequent recurrence may reopen the old ticket or start a linked new episode, according to the agreed workflow. Do not let an automatic refresh overwrite human notes, reset ownership or send customer notifications unintentionally. Test those side effects during the pilot, along with rate limiting, permission failures and uncertain writes.
Verify the closure prerequisite
Suppose the technician supplies a nonempty evidence link, but it points to an unrelated sender’s test. The link exists, yet it cannot justify closing this incident. Verify the evidence source, authorized collection, affected service, timing and result before requesting the desk transition. Missing, blank or unrelated evidence should leave the incident awaiting verification under this proposed workflow. No closure function or evidence validator was executed here.