Manage Configuration Versions (Draft Mode)
Focus
Focus
Prisma Browser

Manage Configuration Versions (Draft Mode)

Table of Contents

Manage Configuration Versions (Draft Mode)

Discussion of the draft mode.
Where Can I Use This?What Do I Need?
  • Strata Cloud Manager
  • Prisma Browser standalone
  • Prisma Access with Prisma Browser bundle license or Prisma Browser standalone license
  • Superuser or Prisma Browser role
Draft Mode fundamentally changes how you manage and deploy your Prisma Browser configuration, instituting a robust, staged workflow that minimizes risk and enhances control. Instead of the traditional method where every alteration immediately affects the live system—the active configuration—we now safely capture and store all modifications within a temporary, isolated draft environment.
This Draft Configuration serves as a staging area and provides a crucial buffer between development and deployment. In this environment, you gain the necessary time and tools to thoroughly review every detail of your proposed changes, iteratively modify settings, and execute comprehensive validation tests. This critical staging process ensures you optimize the configuration and verify it is error-free before you commit it to the live environment.
Once satisfied with the drafted changes, you can initiate the publishing process. This action is the gateway to production; it takes the validated draft and promotes it to become the new active configuration, and the system immediately enforces this new configuration across your production environment. A key feature of this system is that it automatically creates a numbered configuration version upon every successful publish. This systematic versioning establishes a complete, chronological audit trail of changes. By maintaining a full history of configuration versions, Prisma Browser offers unprecedented transparency and traceability, which allows administrators to understand exactly what changed, when it changed, and who made the change. This version history is indispensable for troubleshooting, compliance auditing, and, most importantly, it allows you to quickly and reliably revert to a prior, stable configuration should any unforeseen issues arise with the latest deployment.

Supported Entities

The Draft mode applies to the following entity types:
  • Policy Rules: Sign-in rules, Access and Data Control rules, Browser Security Rules, Browser Customization Rules.
  • Applications: Custom and Private Applications
  • Application Groups: Groups of Applications
  • Device Groups: Device Posture Groups
Entities not mentioned above (for example, System Settings) continue to apply changes immediately. When you make a change outside the draft workflow, an alert notifies you that your changes take place immediately.

How Draft Mode Works?

Draft mode in the system utilizes a carefully managed, three-step lifecycle designed to allow you to safely introduce changes without immediately impacting the live production environment. This process ensures thorough review, collaboration, and version control before any modification becomes active.
  1. Make the changes (Draft Configuration):
    This is the initial phase where all modifications are prepared. When an administrator initiates a change—whether creating a new policy, editing an existing setting, or deleting an outdated entity—that action is immediately recorded and saved to the draft configuration.
    • Isolation and Safety: The fundamental principle of this step is isolation. All pending modifications reside exclusively within the draft configuration. This means the active configuration, which is currently controlling the live system or services, remains completely untouched and stable. Live operations continue to function based on the last published configuration.
    • Iterative Work: You can make any number of changes, save your work, log out, and return later. The draft persists until it is explicitly published or discarded. This allows for complex, multi-day, or multi-administrator projects to be managed effectively.
    • Supported Entities: The draft configuration accommodates changes to all supported entities within the platform, ensuring a comprehensive approach to configuration management.
  2. Review Changes (Audit and Verification):
    Before any draft changes can be made permanent, a thorough review process is necessary to ensure accuracy, compliance, and prevent errors.
    • Visibility: Prisma Browser provides a comprehensive interface for reviewing all pending modifications. This step is critical for quality control and team collaboration.
    • Detailed Audit: Administrators can view the exact differences between the draft and the active configuration. The review tool clearly highlights:
      • Creations: New entities that have been added to the configuration.
      • Updates: Existing entities that have been modified, with a side-by-side comparison of the old and new values.
      • Deletions: Entities that have been marked for removal.
    • Accountability: A key feature of this step is the ability to track who made what change. The review log provides an audit trail, showing the identity of the administrator responsible for each modification, which is essential for troubleshooting and security compliance.
  3. Publish (Activate):
    The final step formalizes the draft changes and makes them operational in the live environment.
    • Commitment: When the review process is complete, and all pending changes are verified and approved, the administrator executes the Publish action.
    • Activation: This action applies all pending changes from the Draft Configuration to the active configuration, making them immediately effective for the system.
    • Version Control: The publishing process is intrinsically linked to the platform's version control system. Prisma Browser automatically:
      • Creates a New Configuration Version: A permanent, immutable record (a snapshot) of the newly activated configuration is saved, complete with a version identifier and a timestamp. This allows for historical tracking and rollback capabilities if needed.
      • Resets the Draft: Once the draft has been successfully published and a new version created, the temporary draft configuration is automatically cleared and reset. It is synchronized to be an exact match of the newly published active configuration, ready for the next cycle of changes.
    You can also discard all pending changes at any time to reset the draft back to the current active configuration.

View Draft and Published Configurations

Pages that support Draft Mode (e.g., Policy Rules, Applications, or Device Groups) allow you to switch between viewing the draft and published configurations.
Near the page title, you will find the following controls for managing configurations:
  • Published: Shows the currently enforced, active configuration. This view is read-only.
  • Draft: Displays the current working configuration where you make and view all pending changes.
  • Pending changes indicator: Indicates the number of uncommitted changes in the draft. If there are none, it shows No pending changes.
  • Version number Displays the version number and publication date of the current active configuration.
To modify, add, or remove entities, switch from the published configuration view to the draft view. Changes cannot be made while viewing the published configuration.

Review Pending Changes

Before you publish, review all pending changes to verify your configuration updates.
  1. From the draft view of any configuration page, click the pending changes indicator.
  2. The Review Changes panel displays a list of all pending changes across all supported entity types. For each change, the following information is displayed:
    • Entity type: The type of entity (rule, section, application, device group).
    • Name: The name of the entity.
    • Operation: Whether the entity was Created, Updated, or Deleted.
    • Updated by: The administrator who made the change.
    • Updated at: The date and time of the change. Hover over the field to see the full timestamp.
  3. Use the filters to narrow the list by entity type, operation, or search by name. Before committing and publishing your configuration updates, it is essential to meticulously review all pending changes to ensure accuracy, compliance, and the intended outcome. This process allows you to catch potential errors or unintended consequences before they affect the live system.
Here is a comprehensive guide to reviewing your configuration changes:
  1. Accessing the Pending Changes Review:
    • While in the draft view of any configuration page within the management interface, locate and click the pending changes indicator. This indicator is typically prominently displayed and shows the count of modifications that have been made since the last published version.
  2. Understanding the Review Changes Panel:
    • Clicking the indicator opens the Review Changes panel, which provides a detailed, centralized list of all modifications that are currently pending across all supported entity types within the configuration draft.
    • For every entry in this list, the panel displays crucial metadata, enabling a thorough review:
      • Entity type: Identifies the specific category of the configuration object that was altered. Examples include, but are not limited to, rule, section, application, device group, network interface, or security profile. This helps in immediately understanding the scope of the change.
      • Name: The specific, identifiable name of the entity that was affected. This could be the name of a security rule, a network zone, a user group, or a specific application definition.
      • Operation: Clearly states the action that was performed on the entity. The three primary operations are:
        • Created: A new entity was added to the configuration.
        • Updated: An existing entity's parameters or properties were modified.
        • Deleted: An existing entity was removed from the configuration.
      • Updated by: Indicates the administrator or system process that executed the change. This is vital for accountability and tracing the source of an update.
      • Updated at: Records the exact date and time when the change was finalized in the draft. To view the full, precise timestamp, simply hover your cursor over this field.
  3. Refining and Filtering the Change List:
    • For configurations with a large volume of pending changes, the Review Changes panel includes robust filtering and search capabilities to help administrators focus on specific modifications:
      • Filter by Entity Type: Use the filter menu to narrow the displayed list to only show changes related to a specific entity category (e.g., only show changes to "rules").
      • Filter by Operation: Limit the view to only show entities that were Created, Updated, or Deleted.
      • Search by Name: Utilize the search bar to find changes affecting a specific entity name or part of a name. This is particularly useful when reviewing changes to a known, named object.
By utilizing these steps, administrators can ensure that the configuration being published is exactly as intended, minimizing the risk of deployment errors and maintaining the integrity of the system.

Publish Draft Changes

When your changes are reviewed and ready, publish the draft to make it the active configuration.
  1. Click the pending changes indicator to open the Review Changes panel.
  2. Review the list of pending changes.
  3. Click Publish.
  4. (Optional) Add a description for this version. The description helps you identify this version in the version history.
  5. Confirm the publish operation.
To activate your changes, you need to publish the draft after reviewing and confirming it:
  1. Open the Review Changes panel by clicking the pending changes indicator.
  2. Examine the list of pending changes.
  3. Click Publish.
  4. Optionally, add a description to help identify this configuration version in the version history.
  5. Confirm the publish action.
Once published, this becomes the active configuration.
After Publishing:
  • A new configuration version is created with an auto-incrementing version number (e.g., Version 45 → Version 46).
  • All pending changes become the active configuration and are enforced immediately.
  • The draft resets to match the newly published active configuration.
  • The previous active version is archived and available in the version history.
Publishing commits all pending changes as a single, atomic operation. You cannot publish a subset of changes.

Discard Draft Changes (Reset the Draft)

If you want to discard all pending changes and start over from the current active configuration, you can reset the draft.
  1. Click the Pending Changes indicator to open the Review Changes panel.
  2. Click Discard all.
  3. Confirm the Discard operation.
    This action cannot be undone. All uncommitted draft changes are permanently lost. The active configuration is not affected.

View Configuration Version History

Every time you publish a configuration, Prisma Browser automatically creates a new, numbered version. You can review this version history to track past configurations and identify the changes introduced in each one.
To view the configuration version:
  1. Navigate to the Configuration Versions page.
  2. The Version List displays all published versions, in ascending order. Each entry contains the following details.
    • Version number: A sequential, auto-incrementing identifier.
    • Status: Indicates if the version is the Active (current) configuration or Archived (historical).
    • Published at: The date and time the publication occurred.
    • Published by: The administrator who published the Configuration.
    • Description: The optional summary added during the publishing process.
    • Changes summary: A count of the entities Created, Updated, and Deleted in that specific version.
  3. Click any version in the list to see a detailed breakdown of the changes.

Best Practices

  • Review before publishing: Always review the pending changes list before publishing to verify that all changes are intentional and complete.
  • Use version descriptions: Add meaningful descriptions when publishing to make it easier to identify versions in the history.
  • Coordinate with your team: When multiple administrators work in the same draft, communicate to avoid publishing another administrator's incomplete work. Publishing commits all pending changes from all administrators.
  • Check for unsupported entities: If you see an immediate change alert, the entity you modified is not part of the draft workflow, and the change is already live.