Updating and Committing Policy Changes

Overview

Provisioning applies Designer policy changes to devices. In the SecureChange UI, this is done through Update. Provisioning can include new rules, modified objects, or reordered policies.

The device can be a firewall, a security group, or a management device:

  • When you update a firewall or security group, the changes are enforced immediately.
  • When you update a management device, the changes are saved locally on the manager but are not enforced until you commit them to the child firewalls.

Commit pushes saved changes from a management device to its connected firewalls. This applies only to management devices that support Commit.

You can also configure provisioning to occur automatically using the scheduled change window in SecureTrack. This allows policy changes to be implemented during predefined maintenance windows.

To learn how to start with Designer and review its results, see Using Designer.

See SecureChange Features by vendor for full compatibility.

Updating Device Policies

Click Update to provision Designer’s changes to a device. The button label and location vary depending on the device type.

Update Behavior by Device Type

Device Type Where the Update Button Appears Button Label Behavior
Standard Devices On the ticket page Update devices (devices)
Update Policy (firewalls) 		Updates one device at a time
OPM Devices Inside the Designer results page Update Update arrow Updates all devices under the OPM root (if supported)

Update on OPM Devices

  • For OPM devices, the Update button appears only after you click Designer results. This opens the DESIGNER DETAILED RESULTS page, where you can update all devices under the OPM root.

  • You can run updates on multiple OPM devices in parallel. You can also run one standard device update at the same time. However, you cannot update more than one standard device at once.

  • Not all OPM devices support provisioning. If provisioning is supported, the Update button will appear. For device-specific support, see SecureChange Features by Vendor.

Tracking Update Status

When the update runs, each device shows one of the following statuses:

  • Green check: update completed successfully
  • Red X: update failed
  • Orange spinner: update in progress
  • Yellow exclamation: update is not supported

Managing Revisions and Conflicting Tickets

Designer’s suggestions are always based on the current revision of the device policy. Suggestions may become outdated when a new revision is received on the device, or when another ticket with Designer results is updated automatically using Update Device in SecureChange.

To reduce cases where suggestions are marked as outdated, SecureChange compares Designer results across tickets on the same device. If a ticket is updated automatically and no conflicts are found with other tickets, those other tickets are not marked as outdated when the new revision arrives on the device.

SecureChange checks Designer results every time you open an existing suggestion or run Update. If the revision is outdated or a conflict is detected, a warning message appears. You can then choose:

  • Update devices: Apply the original suggestions even if they are based on an older revision.

  • Redesign: Rerun Designer to calculate new suggestions for devices with detected dependencies, while keeping existing Designer results for unaffected devices.

Update Queue Behavior

When provisioning runs in an automated step (auto-step), tasks are queued per device.

  • Each device queue supports up to 100 updates
  • Updates run sequentially per device
  • New revisions are skipped unless explicitly allowed
  • Auto-step fails if conflicting tickets are detected

Committing Policy Changes

Click Commit to push saved policies from a management device to its connected child firewalls.

The Commit button appears only after a successful update. All saved changes on the management device, including changes from other tickets, are included in the commit.

Commit Result Icons

  • : All changes were committed successfully
  • : One or more changes failed. Click to view details
  • : Commit did not start. Contact Tufin Support
Keep your browser open during commit. If you close the tab, the process continues in the background but results won’t be shown.

Commit Timeout

The commit process times out after 6 hours by default. To change this setting, contact Tufin Support.

Commit Availability

  • If no update has been performed, the Commit button does not appear.

  • Commit is not available on OPM devices.

  • Commit is supported on standard management devices, depending on vendor. See SecureChange Features by vendor for details.

  • If Commit is supported but the button does not appear, the workflow may need to be configured to allow Commit. For details, see Configuring Workflow Fields.

How Do I Get Here?

SecureChange > Tickets > Search for or open a ticket > Designer