Unclear customer mappings need a defined resolution path

When an integration cannot reliably map the customer for an operation, that case should remain actionable. It needs a responsible role, the necessary information and a controlled route back into processing. An error log and an instruction to resend later do not resolve an uncertain business identity.

Microsoft also describes manual intervention with a traceable failure reason in multi-step workflows. Our example waits before writing to the target.

An open case needs a visible outcome

In this entirely fictional example, project request R-28 should create a project draft in the ERP. CRM customer C-508 has no confirmed mapping. The responsible person establishes that the existing ERP customer account K-410 should be used. The table describes the intended flow.

A name in a list must not determine the customer selection on its own. Processing must retain the reason for the case, the checked source version, the previous and chosen mappings and the decision rationale together. Only the authorised role may access these cases.

Corrections must consider the current state

Data or permissions may change between display and confirmation. Before continuing, check current permissions and whether the selected customer account may still be used. OWASP requires permission checks on every request. An already open editing screen does not replace that check.

Two people working simultaneously must not save unnoticed conflicting decisions either. Changed prerequisites or a case already resolved must be detected at confirmation. If the conditions no longer hold, the operation remains open for further clarification.

Repetition must not create a second project draft

All attempts stay linked to the same project request. This also requires protection in the target: for example, idempotent creation that produces no additional draft on an identical repeat, or a unique external reference enforced by the target with reliable outcome lookup. The operation identifier alone does not prevent duplicates.

If the response is missing after writing, establish the outcome of the existing operation first. AWS explains that a timeout does not rule out side effects that have already happened. Until clarified, an unknown outcome must not be treated as a definite failure and replaced with an arbitrary new request.

Limit manual handling to the cases that need it

An unambiguous, verified mapping can be processed automatically. Not every record needs human approval. For other cases, ownership, the agreed response time and escalation must be visible; a growing list without an owner does not solve the problem.

Our example stops before project creation. If something has already been created for the wrong customer, a separate business correction must account for the links that have been created.

Sources

• Microsoft — Compensating Transaction pattern

• OWASP — Authorization Cheat Sheet

• AWS — Timeouts, retries, and backoff with jitter