Oracle APEX 26.2: Locking and Unlocking Applications -A Practical Guide

When multiple developers work on the same Oracle APEX application, managing changes becomes an important part of the development process.

Imagine working on a major application update while another developer is modifying the same application through App Builder. Without proper coordination, it can become difficult to control who is allowed to make changes and when.

Oracle APEX provides an application locking mechanism to help manage this situation. With Oracle APEX 26.2, application locking also becomes more interesting for developers working on automation, source control, and CI/CD workflows.

In this article, we will explore:

• What application locking means in Oracle APEX
• How to identify a locked application
• How to lock and unlock an application through App Builder
• What happens when another developer attempts to access a locked application
• How the new APEX 26.2 PL/SQL APIs extend application locking
• Practical considerations for development teams

1. What Is Application Locking in Oracle APEX?

Application locking is a mechanism that restricts changes to an application through App Builder.

When a developer locks an application, that developer retains exclusive editing access to the locked application. Other developers cannot make changes to it through App Builder until the lock is released.

This can be useful when performing significant application modifications, coordinating development activities, or preparing an application for a controlled update.

Application locking is particularly relevant when several developers share the same development workspace.

Important: An application lock controls editing through App Builder. It should not be confused with disabling runtime access to the application or with database-level locking.

Application lock/unlock status displayed in Oracle APEX App Builder

2. How to Identify a Locked Application

Oracle APEX makes application lock status visible through the App Builder interface.

To check the status:

1. Sign in to your Oracle APEX workspace.
2. Open App Builder.
3. Locate the application you want to inspect.
4. Check the lock indicator in the application listing.

The lock indicator helps distinguish between different situations:

• Unlocked: The application is not currently locked.
• Locked by you: You are the developer who holds the application lock.
• Locked by another developer: Another developer currently holds the lock.

These indicators provide a quick way to understand the application’s editing status before beginning any development work.

Locked by another developer

Locked by you

3. How to Lock an Application

Oracle APEX provides two convenient ways to lock an application through App Builder.

Method 1: Lock from the App Builder home page

Follow these steps:

1. Open your workspace and navigate to App Builder.
2. Switch to Report View using the navigation bar.
3. Locate your application.
4. Under the Actions column, click the unlocked icon.
5. Enter a meaningful comment in the Application Lock dialog.
6. Click Lock Application.

The application is now locked by you.

Method 2: Lock from the Application home page

You can also lock the application directly from its home page.

1. Open App Builder.
2. Select the application you want to lock.
3. In the Tasks section of the sidebar, select Lock Application.
4. Enter a comment describing why you are locking the application.
5. Click Lock Application.

Both methods achieve the same result.

Why should you add a lock comment?

A useful comment provides context to other developers. Instead of simply seeing that an application is locked, they can understand why the lock exists.

For example:

• Preparing the application for a major release
• Updating shared components
• Performing a controlled application migration
• Coordinating a critical bug fix

A meaningful comment makes collaboration easier, especially in a shared development environment.

Locking an application with a descriptive comment

4. What Happens When Another Developer Opens a Locked Application?

This is where application locking becomes particularly useful for team development.

When an application is locked by another developer, other developers and workspace administrators cannot edit or unlock that application through App Builder.

Instead, they are redirected to the Application Locked page.

If the application has working copies, the lock page can also provide links to those copies.

This behavior helps prevent conflicting edits to the locked application through App Builder.

However, application locking is not a replacement for a complete development lifecycle strategy. Teams should still coordinate changes, maintain appropriate backups or source control, and follow their deployment procedures.

App Builder displays the lock status when another developer attempts to access a locked application

5. How to Unlock an Application

Once the required work is complete, the developer holding the lock can release it.

Get Niwin Nicho N’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

There are two ways to do this.

Method 1: Unlock from the App Builder home page

1. Open App Builder.
2. Switch to Report View.
3. Locate the locked application.
4. Under Actions, click the locked icon.
5. On the Application Lock page, click Unlock Application.

Method 2: Unlock from the Application home page

1. Open App Builder.
2. Select the application.
3. In the Tasks section, select Unlock Application.
4. On the Application Lock page, click Unlock Application.

After unlocking, the application is no longer protected by that application lock, and normal editing access through App Builder can resume subject to the workspace’s permissions and other restrictions.

Important: Only the developer who locked the application can unlock it through this interface. Other developers and workspace administrators are redirected to the lock status page.

Releasing an application lock after completing development work

6. Application Locking and Working Copies

Application locking becomes even more useful when considered alongside Oracle APEX Working Copies.

A Working Copy allows a developer to create a separate copy of an application, make changes independently, and later compare or merge those changes with the main application.

For example, a team might use a Working Copy to test a new dashboard, introduce a new page, or experiment with changes before merging them into the main application.

Application locks and Working Copies serve different purposes:

• Application locking controls who can edit the locked application through App Builder.
• Working Copies provide an isolated application copy for development and comparison.

Locking the main application does not automatically lock its Working Copies. Developers should therefore coordinate changes across the main application and its copies.

This distinction is important when planning parallel development activities.

7. What’s New in Oracle APEX 26.2? Programmatic Application Locking

The application locking interface is useful for manual development. But what happens when application deployment is automated?

For example, imagine a CI/CD pipeline that needs to control application editing while performing a deployment.

In Oracle APEX 26.2, the APEX_APPLICATION_ADMIN package provides public PL/SQL APIs for application locking and unlocking, along with an API for creating Working Copies.

The two relevant procedures are:

• APEX_APPLICATION_ADMIN.LOCK_APPLICATION
• APEX_APPLICATION_ADMIN.UNLOCK_APPLICATION

These APIs extend application lifecycle management beyond manual App Builder interactions.

Lock an application using PL/SQL

The following example illustrates the documented API parameters:

BEGIN
    APEX_APPLICATION_ADMIN.LOCK_APPLICATION(
        p_application_id => 100,
        p_lock_as_user   => 'YOUR_WORKSPACE_DEVELOPER',
        p_lock_comment   => 'Preparing application for deployment'
    );
END;
/

Replace the example application ID and developer name with valid values from your environment.

The parameters identify the application, the workspace developer or administrator associated with the lock, and the reason for locking it.

The specified owner must be an existing developer or administrator in the relevant workspace.

Unlock an application using PL/SQL

To release a lock programmatically, you can use:

BEGIN
    APEX_APPLICATION_ADMIN.UNLOCK_APPLICATION(
        p_application_id => 100,
        p_unlock_as_user => 'YOUR_WORKSPACE_DEVELOPER'
    );
END;
/

Here, the supplied owner identifies whose lock should be released.

Important: The documented p_unlock_as_user parameter is optional. When it is NULL, the procedure removes the lock without filtering by owner. In automated workflows, explicitly specifying the expected lock owner is safer because it avoids unintentionally releasing another developer's lock.

These examples illustrate the API calls. Production automation should also handle errors, verify lock ownership, and ensure that cleanup occurs when a deployment fails.

8. Where Can Programmatic Locking Be Useful?

The new APIs are particularly relevant to teams exploring automated APEX development workflows.

Some potential use cases include:

Automated deployment pipelines

A deployment process can request an application lock before carrying out a controlled update and release its own lock when the process finishes.

Release coordination

A pipeline can associate a lock with a deployment or release identifier, making it easier for developers to understand why the application is locked.

Development automation

Trusted development integrations can incorporate application locking into a larger application lifecycle workflow.

AI-assisted development workflows

As teams experiment with AI-assisted application generation and automated code changes, programmatic locking can be one part of a process that coordinates changes to shared applications.

These are potential implementation patterns, not automatic features provided by the lock API itself. Teams must build the surrounding deployment logic, error handling, and access controls.

9. Best Practices for Application Locking

Here are some practical recommendations when working with application locks.

1. Use descriptive comments. Explain why the application is locked and, where appropriate, identify the release or development task.
2. Keep lock ownership clear. Use a valid workspace developer or administrator identity when calling the APIs.
3. Release locks deliberately. Ensure that automated workflows handle both successful and failed deployment paths.
4. Do not confuse locks with runtime access controls. Application locking is about editing through App Builder, not restricting end users from running an application.
5. Coordinate Working Copies separately. Locking a main application does not lock its Working Copies.
6. Test automation outside production first. Verify the locking, unlocking, and failure-handling behavior in a development environment before introducing it into a deployment pipeline.
7. Follow source control and deployment practices. Application locks complement change management; they do not replace version control, testing, or deployment validation.

Conclusion

Application locking is a small but useful feature in Oracle APEX development, particularly when several developers work within the same workspace.

The App Builder interface provides a straightforward way to lock and unlock applications manually. Oracle APEX 26.2 extends this capability with public PL/SQL APIs, creating additional possibilities for controlled deployments and automated development workflows.

Understanding application locks alongside Working Copies can help teams make better decisions about collaboration, change isolation, and application lifecycle management.

If you are working with Oracle APEX 26.2, consider exploring these APIs in a development environment and identifying where they fit into your existing deployment process.

Have you started using application locking or Working Copies in your APEX projects? Share your experience and use cases in the comments.