Object Locking in Application Composer

The automatic object locking ability in Application Composer avoids the risk of conflicts between multiple users working on objects in parallel and prevents any sandbox merge conflicts that may arise when different users change a specific object using different sandboxes.

Application Composer automatically places a lock on a business object when you create or modify it in a sandbox. The locked object displays a lock icon next to its object name in Application Composer's object navigation tree. A gold lock indicates that the object is locked in the current sandbox. A gray lock indicates that the object is locked in a different sandbox. Hover over a locked object's name in the navigation tree to display the name of the sandbox that holds the lock.

Application Composer displays and enforces object locks across all sandboxes. You can only edit a locked object in the sandbox that holds the lock. For example if the Service Request object is modified in Sandbox A, only Sandbox A holds the lock and anyone using Sandbox A can modify Service Request. Any other sandbox displays a gray lock on Service Request in Application Composer, and prevents users from modifying it.

The lock status of objects changes in the following cases:

When a sandbox that had a lock is published or deleted.
When a new object lock is established.
When a sandbox becomes not publishable, which happens after a patch, release update, or a migration.

Collapse and then expand Application Composer's object tree to update the lock status of all objects. Any action that causes the object tree to be refreshed will update the lock status, including when you exit and reenter a sandbox, or refresh a sandbox. If an object is locked and that lock isn't yet visible in the current sandbox, a new lock isn't allowed to be placed on that object and an error message appears while saving the changes.

Note: If the sandbox you're working in was created for testing purposes only and was set as not publishable or becomes not publishable, then the business object you create or modify won't be automatically locked. This way, multiple teams can work on the same business object in different test sandboxes.

For more information on how object locking works in sandboxes, see the FAQs on Object Locking.

Best Practices for Preventing Object Locking

Here are some tips on how you can prevent or work around object locking:

Plan your object model and user interface configurations, and divide the work to prevent two users requiring the same object or objects locked.
Name sandboxes clearly with appropriate names or initials, so when a lock is in place, it's easy to identify who to contact to release the lock from the sandbox holding the lock.
Perform configurations in smaller increments. Test and publish more frequently to prevent holding locks.
Delete test sandboxes created to try out new configurations after they're no longer needed to prevent unnecessary locking.
If you're using a sandbox just to test changes and don't intend to publish them, then set the Publishable field to No to prevent locking.