What this error message means
When you see "Locked For Adding/Changing Delivery Objects Like BSP Applications" in SAP, the system is telling you that someone else is currently editing the object you are trying to modify, or the object itself is set to read-only mode. This is a lock mechanism — SAP's way of preventing two people from making conflicting changes to the same thing at the same time.
The message appears most often when you are working with Business Server Pages (BSP) applications, which are web-based programs built inside SAP. But the same lock can apply to other delivery objects like Web Dynpro applications, portal components, or configuration settings. The lock does not mean the object is broken or permanently unavailable — it means you cannot edit it right now.
Key Takeaways
- A lock message means another user has the object open for editing, or the object is in a protected state that prevents changes.
- You can see who holds the lock and when they locked it by checking the object's lock status in the system.
- Waiting for the other user to close the object, or asking a system administrator to release the lock, are the two main ways forward.
- Some locks are intentional — set by administrators to protect production objects from accidental changes.
- Restarting SAP or logging out the user holding the lock will not always clear it; the lock may persist until the edit session formally closes.
Why SAP locks delivery objects
SAP uses locks to prevent a common problem: if two people edit the same object at the same time, one person's changes will overwrite the other's. By locking an object while someone is editing it, SAP ensures that only one person can make changes at a time. When that person saves and closes the object, the lock releases and the next person can edit it.
This is especially important for BSP applications and similar objects because they often contain code, configuration, and business logic that other parts of the system depend on. A careless change — or two conflicting changes saved at once — can break functionality across multiple areas.
How to check who holds the lock
To see which user has locked the object, open the object in SAP and look for a lock indicator or message. In most SAP modules, you can navigate to the object's properties or status screen. The lock information usually shows the username of the person who locked it and the timestamp when they locked it.
For BSP applications specifically, you can check the lock status through the BSP application editor or through transaction SE80 (Object Navigator). Right-click the application name and select "Display Lock Information" or a similar option, depending on your SAP version. The system will tell you the user ID and the time the lock was set.
If you cannot find lock information in the user interface, ask your SAP system administrator to check the lock table directly. Administrators can query the system's lock registry to see all active locks and who holds them.
What to do if an object is locked
Your first step is to wait. If the lock was set moments ago, the person editing the object may still be working. Give them a few minutes to finish and close the object. Once they save and exit, the lock releases automatically and you can edit it.
If you know who locked the object, contact them directly and ask them to close it. They do not need to save their changes — closing the object without saving will also release the lock. This is often faster than waiting.
If the lock has been in place for hours or days, or if you cannot reach the person who set it, contact your SAP system administrator. Administrators have the authority to force-release locks. They can remove the lock without affecting the object itself, allowing you to edit it. Be aware that if the other user had unsaved changes, those changes will be lost when the lock is released.
Locks set by administrators or the system
Not all locks are held by individual users. Some locks are set by system administrators to protect objects from accidental changes. For example, an administrator might lock a production BSP application to prevent developers from editing it directly in the live system. These locks are intentional and usually documented in your change management process.
If you encounter a lock on a production object, check with your team lead or administrator before asking for it to be released. There may be a reason it is locked — perhaps the object is scheduled for maintenance, or changes must go through a formal approval process first.
In some cases, the system itself sets a lock if an object is in a particular state. For example, if a BSP application is currently being transported to another system, it may be locked until the transport completes. These system-set locks usually clear on their own once the operation finishes.
How to prevent lock conflicts in your workflow
If you work on BSP applications or other delivery objects regularly, coordinate with your team about who is editing what and when. A simple shared calendar or Slack message can prevent situations where two people try to edit the same object at the same time.
Close objects as soon as you finish editing them, even if you are just stepping away for a few minutes. The sooner you close an object, the sooner the next person can work on it. If you are taking a long break, log out of SAP entirely — this ensures your locks are released even if you forget to close the object.
For teams that work on the same objects frequently, consider using a version control system or a formal change request process. This gives everyone visibility into who is working on what and prevents accidental overwrites.
When a lock will not clear
Occasionally a lock persists even after the user who set it has logged out or closed SAP. This can happen if the system crashed, the network connection dropped, or the user's session ended unexpectedly. The lock remains in the system's lock table until an administrator manually removes it.
If you have waited a reasonable time and confirmed that the user is no longer working on the object, ask your administrator to check the lock status and remove it if it is stale. Administrators can usually clear these locks in seconds using system tools.
Do not attempt to work around a lock by editing a copy of the object or using a different transaction code. This will create confusion and may result in lost changes or conflicting versions. Always wait for the lock to be released or ask an administrator to release it.
Frequently Asked Questions
Can I edit a locked object if I have administrator rights?
No. Administrator rights do not override object locks — the lock applies to everyone equally. However, as an administrator you can view who holds the lock and force-release it if necessary. You still cannot edit the object while it is locked; you must release the lock first.
Will restarting SAP clear a lock?
Restarting your own SAP session will not clear a lock held by another user. The lock is stored on the server, not on your computer. Only the user who set the lock, or an administrator, can release it. If the user's session crashed, an administrator may need to manually clear the lock from the server.
What happens to unsaved changes if an administrator releases my lock?
Any changes you made but did not save will be lost. This is why it is important to save your work frequently and close objects properly when you are done. If you are interrupted and your lock is released by an administrator, you will need to redo your changes.
Can I lock an object myself to prevent others from editing it?
In most SAP systems, you cannot manually lock an object. The lock is set automatically when you open an object for editing. Some administrators may set intentional locks on production objects to protect them, but this is typically done through administrative tools, not through the normal user interface.
How long does a lock usually last?
A lock lasts as long as the object remains open in edit mode. Once you save and close the object, the lock releases immediately. If you leave an object open without saving, the lock can persist for hours or days until you close it or your session times out. Session timeouts vary by system configuration but are often set to 30 minutes to several hours of inactivity.