Design Matching Around Real Work

The best matching rule is not the one that looks cleanest in a database. It is the one that can be fed reliably by the real workflow. If a design depends on people capturing an identifier they rarely see, do not trust, or must hunt down elsewhere, the technical precision is mostly theatre. The system may have an elegant key, but the process will produce missing values, guessed values and workarounds. Start with what users naturally know at the moment they need the match, then design the confidence model and exception path around that reality.

This is an easy trap because identifiers are comforting. A unique value promises certainty: equal means equal, different means different. It simplifies joins, test cases and diagrams. From inside the system, requiring that value can feel like the responsible choice. From inside the job, however, capturing it may mean opening another application, waiting for an upstream step, asking someone else, or changing a well-understood sequence of work. The data model has quietly exported its inconvenience to every user.

That inconvenience does not stay at the edge. People adapt. They leave the field empty until later, enter a placeholder, reuse the nearest available value, keep a side list, or stop trusting the feature altogether. Each workaround weakens the supposedly exact match. A rigid rule built on unreliable capture can be less trustworthy than a probabilistic rule built on information that is consistently available.

The useful design question is therefore not, "What field would make matching easiest?" It is, "What evidence exists naturally at this point in the workflow?" That evidence might include a combination of time, location, category, sequence or another ordinary business attribute. None may be unique alone. Together they may narrow the candidates enough for a confident automatic match, while still admitting that some cases are ambiguous.

Admitting ambiguity is a strength. A mature matching design distinguishes between high-confidence matches, uncertain matches and genuine exceptions. High-confidence cases can move automatically. Uncertain cases can present a small, meaningful choice using information the user recognises. Exceptions can follow a deliberate resolution path with enough context for someone to decide. This turns uncertainty into an observable part of the product instead of burying it inside silent guesses.

The trade-off is that workflow-centred matching needs more thought than a compulsory key. Teams must define acceptable confidence, understand the cost of a false match versus a missed match, and monitor how often the exception path is used. They must also resist the temptation to keep adding fields until every edge case disappears on paper. Every required input has a collection cost, a training cost and a failure mode. The right question is whether the extra certainty is worth imposing that cost on every transaction.

Sometimes the unique identifier really is essential. Financial posting, safety-critical records and irreversible actions may demand hard identity guarantees. Even then, the workflow needs to make the identifier available at the right moment, ideally through automatic propagation or scanning rather than manual transcription. If the business process cannot provide the required evidence reliably, the answer is not a red asterisk beside a form field. The process and integration design have to change together.

This way of thinking also improves product conversations. A request that sounds like "capture one more field" is often an unresolved decision about ownership, timing and risk. Who creates the value? When does it exist? Who can see it? What happens when it is absent? What harm follows from the wrong match? Answering those questions exposes whether the proposed field supports the work or merely makes one component easier to build.

Good data design does not begin with the perfect key. It begins with a truthful account of how work happens. Build the happy path from evidence people already have, make confidence visible, and give exceptions somewhere sensible to go. The result may look less absolute on a whiteboard, but it will be far more reliable in use.