Choose against the task constraints
The example system stores identifiers SUP-007 and SUP-07 as two distinct accounts. Its business rule treats the characters exactly as stored. Trading names can change and may be shared. A friendly name search can return candidates, but it is not an identity merge.
| Condition | Exact ID lookup | Name matching |
|---|---|---|
| User has an account reference | Match the declared identifier rule | Name result cannot replace the reference |
| User remembers only part of a name | May produce no result without the ID | Return labelled candidates for inspection |
| Similar identifiers | Preserve meaningful leading zeros | Do not normalize IDs through name-search heuristics |
Offer exact lookup when a reference is available and candidate name search when it is not. Display IDs and other discriminators in results. Never infer that near-matching names authorize a merge or that two textual IDs are the same number.
Preserve identifier characters
| ID | Name | Requested action |
|---|---|---|
| SUP-007 | Sample Trading | Reference supplied: SUP-007 |
| SUP-07 | Sample Trading | Different account; not the match |
| SUP-077 | Sample Trade | Similar name only |
What should the exact SUP-007 lookup return under the stated rule?
Show the worked answer
Only SUP-007. SUP-07 and SUP-077 are separate identifiers; name similarity supplies no permission to include or merge them.
Check the chosen interaction
- Leading zeros survive input, result rendering and saved selection.
- An ambiguous name search requires an explicit record choice.
- Exact no-match remains distinct from a failed lookup request.