Treat a locked AFAS record as a temporary business obstacle, not a reason to keep writing indefinitely. Pause the specific provider step, show which record is in use, and decide based on duration and impact whether to try later, have a user release it or resolve it manually. Other independent orders may continue.
Why rapid retries make the problem worse
A record may be in use by an employee, batch or another process. Ten retries within one minute do not shorten the lock, but do fill queues and notifications. Even riskier is a fallback that tries to create a new record after an update error: this turns a temporary lock into a duplicate debtor or order problem.
Classify the response separately from validation errors and permanent configuration errors. Retain the destination identity, last response and time of the first block. A worker may reschedule the task with a bounded delay, but must involve an owner after an agreed limit. This lets Connect continue working without bombarding a locked record.
Waiting, recovery and escalation ladder
| Stage | Indication | Action |
|---|---|---|
| Wait briefly | First lock, no urgency | Delayed retry with an increasing interval |
| Check | Lock keeps recurring | Verify the destination record, permissions and active AFAS session |
| Ownership | Order is blocking fulfilment | Task assigned to a specific administrator with context |
| Resolve manually | Lock or conflict is structural | Correct source or destination and record the decision |
| Run again | Block demonstrably removed | Repeat only the stalled step |
Do not use a universal time limit. An address update for tomorrow's delivery may deserve earlier escalation than non-critical profile enrichment. Record the business deadline and dependent steps alongside technical age.
Fictional example: debtor record open in accounting
Fictional example: the accounting team at coffee shop Branderij Noord has a debtor record open in AFAS while order 7721 attempts an address correction. AFAS reports that the record is locked. The integration retains the debtor number, pauses only the address step and lets other orders process normally.
After two delayed attempts, the lock is still active and the delivery cutoff is approaching. Desk shows the situation with “financial administration” as owner, the order deadline and instructions to release the record after checking. The administrator closes the edit, after which only the address step runs again. No new debtor is created and the original order flow remains traceable. The example is fictional and makes no claim about the exact lock duration in any particular AFAS setup.
What an employee needs to see
- Which order, workspace and provider step are blocked?
- Which existing destination record is involved, without exposing sensitive details widely?
- How long has the lock existed and how many bounded attempts have been made?
- Which next steps depend on this and what is the business deadline?
- Who may investigate the record and who may start reprocessing?
- Has recovery confirmed that no duplicate record was created?
In Desk the block should appear as a concrete work task, not an isolated technical error code. The principles behind source identity and recovery are developed further in reliably integrating an online store and ERP.
Measure locks as process information. An occasional brief lock is normal; recurring locks on the same object type or in the same time window may indicate competing batches, overly broad transactions or employees leaving records open for long periods. Report lock duration, destination type, time, dependent workflow and eventual solution, without unnecessary customer content. Review monthly which locks disappeared on their own and which required human intervention. Only then adjust retry intervals or escalation. A shorter interval rarely improves a structural conflict. Also agree who may start reprocessing once the lock is gone: the person who releases the AFAS record need not automatically have permission to rerun a financial or logistics integration step.
Add one regression test in which two processes deliberately touch the same destination record. The test passes if one step waits, no duplicate is created and the queue resumes exactly once after release. This demonstrates behaviour under concurrency, not just during a quiet demonstration in an empty test environment.
Want to distinguish record locks from real integration errors? Design an appropriate recovery and escalation ladder with Yindle.