# Workflow mismatch checklist: is your data model fighting your process?

Run this against one workflow at a time, with the people who operate it daily. Tick every sign you recognise and read the cause beneath it. The count and its reading update as you go, and tell you whether you are looking at a habit or a modelling defect.

## Before you start

Pick one workflow: room booking, purchase approval, leave, shift allocation, multi item orders. Write down two things first.

- The decision unit: the smallest thing a reviewer actually says yes or no to (a room on a day, a line on an order, a single shift).
- The record unit: the thing the system stores and attaches the approval to (the whole booking, the whole order, the whole week).

If the two differ, expect several ticks below. If they match, the signs may point at process rather than model.

### Signs in daily work

- [ ] Reject and resubmit. Staff routinely reject a request and ask for it to be submitted again in a different shape, because the system cannot accept the part that was fine. (1 point)
  Cause: the decision unit is smaller than the record unit, so a partial answer has nowhere to go.
- [ ] Decided in email, typed back in. The real outcome is agreed in a message thread or a call, then entered as whatever status fits best. (1 point)
  Cause: the status list has no value for the outcome that actually happens, so the system records an approximation.
- [ ] The requester phones to ask what happened. A decision arrives without the detail the requester needs to act, so they ask a person. (1 point)
  Cause: notifications are generated from the record, and the record does not hold the detail that was decided.

### Signs in the data

- [ ] One field carries several meanings. A comment or reason field is the only place the true decision lives, and staff have private conventions for writing it. (1 point)
  Cause: structured information is being stored as prose because the model has no field for it.
- [ ] Statuses mean different things to different teams. The same status is read as "done" by one team and "waiting" by another, and both are right. (1 point)
  Cause: one status is standing in for two or more distinct outcomes, usually because partial results were never given their own value.
- [ ] Duplicate records by design. Staff create extra records for something the requester experiences as one request, so the pieces can be handled separately. (1 point)
  Cause: the record granularity is wrong in the opposite direction, and the link between the pieces (the requester intent) is not stored anywhere.

### Signs in reporting

- [ ] The report never matches what happened. Utilisation, approval rates or turnaround times from the system disagree with what staff know, and someone corrects the numbers by hand. (1 point)
  Cause: the decisions that matter were made outside the record, so the record cannot report them.

### Your result

**0 to 1 ticks.** The model and the process broadly agree. Look at the one tick on its own; it may be a process issue rather than a modelling one.

**2 to 3 ticks.** You have at least one workaround that has become invisible. Find the person who does it daily and ask them to estimate how often. That number is the case for fixing it.

**4 or more ticks.** The decision unit and the record unit are different, and staff are absorbing the gap. Treat this as a data model decision, not a feature request: define the right granularity, give partial outcomes their own status and notification, and plan how existing records migrate. A comment field will not close the gap.

Our reviewers decide at the level of [decision unit], but the system stores and approves at the level of [record unit]. If you can fill in both brackets, you have named the defect and can brief a supplier or an internal team in one sentence.