BAPI_EMPLOYEE_DEQUEUE — BAPI_EMPLOYEE_DEQUEUE - releasing the employee master data lock
BAPI_EMPLOYEE_DEQUEUE releases the enqueue lock previously set on a personnel number by BAPI_EMPLOYEE_ENQUEUE, the same lock PA30 or PA40 places on a record while a user is editing it. It touches no infotype data itself. Custom integration code that acquires the lock before writing infotype BAPIs must call this afterward, in every code path including error handling, or the employee stays locked until the session or lock entry expires.
This page covers BAPI_EMPLOYEE_DEQUEUE, the release counterpart to BAPI_EMPLOYEE_ENQUEUE, used to free the SAP enqueue lock held against a personnel number during custom or middleware-driven infotype updates. It focuses on why the lock gets stuck in practice, why RETURN gives no reliable signal of a real failure, and who is responsible when a PERNR appears locked in PA30 with no visible session behind it.
Published 16 Sept 2026· 963 words
What it does
The business object is the personnel number, PERNR, and the mechanism it acts on is the SAP enqueue table, not a database table. When a user opens an employee's infotype record for editing in PA30 or PA40, the system sets a lock on that personnel number so no other session can edit it concurrently. BAPI_EMPLOYEE_ENQUEUE reproduces that lock programmatically, typically called by custom RFC-enabled integration code or middleware before invoking an infotype-update BAPI such as BAPI_PERSDATA_CHANGE. BAPI_EMPLOYEE_DEQUEUE is the release step: it removes that lock once processing is finished. It does not validate, change, or read any infotype content. Its only job is administering the lock entry, mirroring what happens automatically when a user exits PA30 without saving or after a successful save.
Important parameters
The interface is deliberately narrow because it manages a lock entry, not master data.
- NUMBER - the personnel number (PERNR) whose enqueue lock is to be released
- RETURN - standard return table carrying messages about whether the dequeue call was processed
Commit behaviour
No commit is required or relevant. Enqueue and dequeue operate against the lock table, which is memory-resident on the enqueue server, not the database, so BAPI_TRANSACTION_COMMIT has no effect on it either way. The real risk is not a missing commit but a missing call: if BAPI_EMPLOYEE_DEQUEUE is never invoked after BAPI_EMPLOYEE_ENQUEUE, the lock persists for the lifetime of the enqueue entry, which in an RFC-driven batch or interface scenario can mean until the calling session, work process, or logical unit of work ends, or until it is removed manually. There is no automatic timeout comparable to a database lock.
Return handling
RETURN follows the standard BAPIRET2 structure, and the discipline is the same as for every BAPI: check the TYPE field for E or A, do not rely on SY-SUBRC, and do not assume an empty RETURN table means the lock was actually held and successfully released. The dequeue function underneath enqueue/dequeue BAPIs is generally forgiving: calling it against a PERNR that was never locked, or was locked by a different context, typically does not raise an error. This makes it easy to write cleanup code that always calls dequeue in a finally block, sees a clean RETURN, and concludes the interface is safe, when in fact the original enqueue silently failed earlier in the same run and was never actually holding the record. Interfaces that log only a non-empty RETURN as a failure will miss this class of problem entirely; the fix is to log and reconcile enqueue and dequeue calls as a pair per PERNR, not to trust either call's RETURN in isolation.
ECC vs S/4HANA
BAPI_EMPLOYEE_DEQUEUE remains valid on S/4HANA and S/4HANA-based HCM scenarios, including Employee Central Payroll, because the underlying enqueue mechanism for personnel numbers has not changed. There is no released successor API for this specific lock-management function; it is a technical utility rather than a business object BAPI, so it has not been part of the API simplification or replacement lists that affect infotype and master-data BAPIs. Integration code written against ECC HR can generally continue calling it unchanged.
Common pitfalls
Most problems trace back to the enqueue/dequeue pair not being symmetric in the calling code.
- Dequeue is skipped on the error branch of custom code: the update fails, the exception handler exits without releasing the lock, and the employee appears locked in PA30 by a user or RFC user with no active session
- Enqueue and dequeue are called through stateless RFC pooling on different work processes, so the dequeue does not clear the same lock context the enqueue created, leaving an orphaned entry
- Dequeue is called defensively for every PERNR in a batch regardless of whether enqueue succeeded, masking enqueue failures that should have stopped processing for that record
- SuccessFactors Employee Central to ECP replication jobs that wrap enqueue and dequeue around infotype writes but do not survive a dropped RFC connection mid-transaction, leaving the lock in place until the enqueue entry is cleared manually
- Support teams treat a locked employee as a data issue and try to fix infotypes, when the actual cause is a stuck enqueue entry that has nothing to do with the infotype content
Whose problem this is
This is a developer problem. A functional HR consultant can confirm the symptom, PA30 reporting the record is locked by a specific user or RFC user with no matching active session, and should supply the PERNR and the user or program name shown in the lock message. Resolving it requires reviewing the integration code's enqueue and dequeue pairing, which is a development task, not a configuration one.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-employee-dequeueERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.