A fully labelled illustrative map for receiving a website enquiry, checking required details and assigning a follow-up without disguising exceptions.
INPUT ─── DECISION ─── OWNER ─── RECORD
Illustrative scope and actors
Specification detail
This generalised example is not taken from a client. It maps one administrative outcome: a website enquiry enters a shared queue, receives a reference and is assigned for follow-up. The process starts when the form service creates a new submission and ends when an owner and due date are recorded and the enquirer receives the appropriate approved acknowledgement. It does not map sales qualification, pricing, service delivery or later correspondence. Actors are the form system, admin coordinator and service owner.
The normal route
Specification detail
The form captures name, contact method, enquiry text and consent or notice fields configured for the service. A workflow creates a case reference and checks required fields. If they are present, the coordinator checks whether the reference or contact-and-subject combination indicates an existing open case. A genuinely new case is categorised using an agreed list, assigned to the relevant service owner and given a due date under the business’s actual internal rule. Only then is the approved acknowledgement sent.
Duplicates and sensitive content need controls
Specification detail
A possible duplicate should be suggested, not automatically merged on a loose name match. The coordinator compares references and context, then links or keeps the cases separate. If the enquiry contains payment-card data, credentials or unexpectedly sensitive information, ordinary routing stops. The coordinator follows the organisation’s incident and restricted-handling procedure; the map does not prescribe one without knowing policy. Access to queues and records should be limited to the roles that need them, with actions logged.
Practical sample
Labelled example map: website enquiry to assigned follow-up
Illustrative process only; system names, required fields, response rules and retention must be replaced with the organisation’s approved details.
S1 — Start eventForm service records a new submission and issues an event identifier.
P1 — Create referenceSystem creates a case reference and stores the permitted submitted fields in the shared case queue.
D1 — Required details present?Yes: proceed to duplicate check. No: set status Needs information and continue to E1.
E1 — Missing-information exceptionCoordinator records a reason code; uses an approved request if a valid contact route exists; otherwise sends the case to manual exception review.
D2 — Possible open duplicate?No: proceed to classification. Yes: coordinator compares reference and context; link only when confirmed, never on name alone.
C1 — Sensitive-content controlAt any review point, unexpected credentials, payment data or sensitive material stops normal routing and invokes the organisation’s restricted-handling procedure.
P2 — ClassifyCoordinator selects one approved service category or marks Unclear; free-form guessing does not silently choose an owner.
D3 — Category clear?Yes: route to the mapped service owner. No: send to the named triage owner for manual assignment.
P3 — Assign and dateRecord accountable owner and due date using the organisation’s approved response rule; log assignment time.
P4 — AcknowledgeSend the approved acknowledgement only after assignment; record sent, suppressed or failed status without making unapproved promises.
S2 — End stateCase has reference, status, owner, due date and acknowledgement outcome; it is visible in the owner’s queue.
F1 — Integration fallbackOn failed event, alert the operational queue, use manual capture, preserve the event identifier and check for duplicates before replay.