• Skip to primary navigation
  • Skip to main content
  • Skip to footer
  • Skip to custom navigation
HaloPSA

HaloPSA

  • Features
  • Pricing
  • Integrations
  • Resources
    • Demo On Demand
    • Roadmap
    • ITIL Alignment
    • Guides
    • HaloPSA Academy
    • Onboarding Partners
    • Distributors
  • Compare Us
    • ConnectWise
    • Datto Autotask
  • Solutions
    • I Need To…
      • Run My Business More Effectively

        Find out which customers and services are profitable and gain the confidence to act on this data.

      • Improve My Customer Experience

        Make all interactions as smooth as possible with a fully thought out end to end experience for your customers.

      • Streamline My Sales Process

        Remove unnecessary processes from your sales and account management and let them focus on their customer relationships.

      • Gain Control Of My Projects

        Visualise your workload and forecast your required budgets to ensure you can deliver on your projects.

    • We Are A…
      • Managed Service Provider
      • Telecommunications Provider
      • Cloud Solution Provider
      • Software Company
      • Consultancy Firm
    • Case Studies
      • nGeneration
      • Centrality
      • Commercial Managed IT
  • Start trial
  • Book demo

HaloPSA Guides

Documentation to assist with the setup and configuration of the HaloPSA platform

Guides > Configuration Change Tracking & Instance Management

Configuration Change Tracking & Instance Management


Overview

Released in Version: 2.104.1

This comprehensive guide covers configuration management in Halo, including:

  • Enabling and tracking configuration changes
  • Managing changes between UAT and Production environments
  • Rolling back changes when needed
  • Synchronizing instances
  • Best practices for configuration management
  • Importing and exporting configurations

Getting Started: Enabling Configuration Tracking

Before using configuration tracking features:

  1. Navigate to Configuration > Advanced Settings
  2. Locate the "Config Change Tracking" setting
  3. Enable the setting

Identification: When configuration tracking is active, you'll see the tracking icon in the top right of supported screens:

Important: Once enabled, the system will:

  • Capture snapshots of each configuration change
  • Generate rollback scripts where possible
  • Track changes across supported entities
  • Enable synchronization between environments

Change Tracking Details

The system provides comprehensive tracking capabilities:

Tracking Features

  • Complete audit trail of all configuration changes
  • Automatic encryption of sensitive data
  • Detailed change history with timestamps and user information
  • API request details for each change

Security Note: Configuration changes involving passwords and sensitive information are automatically encrypted and details will not be visible in the change list.

Viewing and Managing Configuration Changes

Configuration Change List

Access the configuration change list through Configuration > Advanced Settings > "View config changes". Changes are listed from newest to oldest, providing a complete audit trail.

Fig 1: Configuration change list showing tracked changes

Security Note: Configuration changes involving passwords and sensitive information are automatically encrypted and details will not be visible in the change list.

Disable Configuration Changes in your production instance (v2.192+)

From v2.192+ you can disable agents' ability to make configuration changes in your production instance. This should be used when you would like changes to only be made in a UAT/Dev instance and then have these changes pushed to your production, rather than allowing configuration changes to be made in your live environment. Agents will still be able to see the configuration but not make any changes to it. 


This functionality is enabled under configuration > advanced settings using the setting 'Disable editing of config tracked entities in production'. 

Fig 2: Disable editing of config tracked entities in your production instance


When enabled, agents will not be able to make changes to any entities that are config tracked, this includes all settings/modules under the 'configuration' module but also any other entities that are config tracked (such as assets). A banner will appear at the top of the screen for all administrator agents informing them that editing has been disabled, if a change needs to be made in an emergency, the banner can be selected to disable the setting, allowing changes to be made. If the banner is selected, the setting will need to be re-enabled under configuration > advanced settings. 


Rolling Back Changes

Halo provides robust rollback capabilities for configuration changes:

Important: When you select a change to roll back, the system will revert all changes made after and including the selected change. This is not a single-change rollback feature.

To roll back changes:

  1. Navigate to the configuration change list
  2. Locate the change you want to roll back to
  3. Click "Roll back before this change"
  4. Confirm the rollback operation

Fig 2: Example of configuration change details and rollback option

Best Practice: Before performing a rollback:

  • Review all changes that will be reverted
  • Document the current state in case you need to recreate any changes
  • Consider creating a backup or export of your current configuration
  • Communicate with team members about the planned rollback

Managing Multiple Instances

For organizations with both UAT and Production environments, Halo provides tools to manage configurations across instances:


Instance Synchronization

You can sync instances in several ways:

  • Automatic Sync: Use "Sync to UAT" or "Pull from UAT" buttons for complete synchronization
  • Manual Export/Import: Select specific changes to transfer between instances


⚠️ Important Considerations

Dependencies: The system uses direct JSON posts for changes. This means:

  • All dependencies must be included when moving changes
  • Base configurations must exist in both instances
  • Changes should ideally be made within concentrated time periods

Supported Configuration Entities

Configuration tracking and synchronization supports a wide range of entities, including:


  • Actions
  • Active Directory
  • Approval Groups/CABS
  • Approval Process Rules
  • Approval Processes
  • Asset Fields
  • Asset Groups
  • Asset Types
  • Azure Active Directory (Entra)
  • Canned Text
  • Categories
  • Charge Types
  • Chat Profiles
  • Column Profiles
  • Custom Buttons
  • Custom Fields (all entities)
  • Custom Tabs
  • Custom Tables
  • Departments
  • DevOps
  • Email Templates
  • Enabled modules
  • Event Rules
  • FAQ Lists
  • Field Groups
  • Filter Profiles
  • Google Workspace
  • Global Settings
  • Jira
  • Lookup
  • Mailbox
  • N-Able N-Central
  • Notifications
  • Organisation
  • Qualifications
  • Roles (Agent)
  • Runbooks/Custom Integrations
  • Service Categories
  • Services
  • Site Fields
  • SLA
  • SQL Imports (SCCM/Lansweeper)
  • Statuses
  • Styling for KBs
  • Teams
  • Templates
  • Ticket Areas
  • Ticket Rules
  • Ticket Types
  • UAT and Production Instance Management
  • User Roles
  • View Lists
  • Virtual Agents
  • Webhooks
  • Workdays
  • Workflows

Instance Synchronization Status

An instance is considered "in-sync" when:


  • It matches the version of the current instance
  • A UAT restore has been performed from production after upgrading to v2.104
  • All configuration dependencies are properly aligned

⚠️ Synchronization Considerations

When synchronizing instances:

  • Changes are applied sequentially from oldest to newest
  • All dependencies must be included in the synchronization
  • Base configurations must exist in both environments
  • Consider making changes within concentrated time periods

Synchronization Methods

Automatic Synchronization

For synced instances, you have two primary options:

  • Sync Changes: Send configuration changes to another instance
  • Pull Changes: Retrieve configuration changes from another instance

From v2.178+ when syncing or pulling changes between instances you will be prompted to select a cut off date. Only changes made on or before (older than) this date will be synced/pulled. 


As of v2.198.1+, a permission has been added to restrict who can push changes to production. Only agents with "Can push configuration changes to other instances" set to "Yes" will be able to. This is set on those with the "Administrator" role by default.


Manual Export/Import

For more granular control:

  • Select specific changes from the configuration change list
  • Export selected changes to a JSON file
  • Import the JSON file into another instance

    Click "import"

    Paste the JSON into the memo box

Important: When synchronizing instances:

  • Changes are applied sequentially from oldest to newest
  • Each change replicates the exact API request from the source instance
  • Ensure all dependencies exist in the target instance before synchronizing

Syncing using Pipelines (v2.182+)

When managing instances on version 2.182+ of Halo you will be able to restrict syncing between specific instances to a defined pipeline. This means each instance in the pipeline can only sync changes from its source instance and this sync is only in one direction.


This allows you to have more control over your instance syncing, as, by creating a linear relationship between instances you can ensure changes are synced sequentially with the appropriate testing being carried out before syncing to production. 


Example Structure:

In the above example pipeline changes will only be able to be pushed/pulled between Development and UAT then between UAT and Production. Changes should first be tested in development then synced to UAT where they can be tested in line with existing configuration. Then when testing is complete sync to Production. Changes made in development cannot be synced directly to Production. 


Configuring Pipeline stages

Pipeline syncing will only take affect once you have specified a source instance for one of your instances. Once this is set pipeline syncing will be enabled and you will only be able to sync changes according to the pipeline. 


Hosted Customers:

To set a source instance head to configuration > instances > select an instance you would like to set a source for, use 'Set Source Instance' to choose the instance you would like to be the source for this one. Each instance can only have one source (parent) instance. 

On Premise Customers:

To set up multiple connected instances, please consult the following guide: Setting up the “Instances” area for On-Premise Halo Instances



UAT Instance Management

For non-production instances, additional management options are available:

Restore from Production

Use the "Restore from Production" button to:

  • Create a support request with Halo Support
  • Update your UAT instance with the latest production data
  • Ensure testing environments match production

Note: When requesting a UAT restore using this button all the ticket data in your UAT instance will be lost and replaced with the ticket data in your Prod instance. 

Change Tracking

Monitor configuration differences through:

  • Changes Behind: View changes needed to catch up to production
  • Changes Ahead: View changes made in UAT that aren't in production

Best Practice: Regular synchronization between environments helps:

  • Maintain consistent testing environments
  • Reduce configuration drift
  • Simplify change management
  • Ensure accurate testing results

Managing Mailboxes between Instances 

Configuring Multiple Credentials per Mailbox (v2.182+)

If you are on v2.182+ you will be able to configure multiple credentials per mailbox. This allows you to link credentials to a specific instance, so a single Halo mailbox can contain credentials to access multiple Azure/Google/SMTP mailboxes. Each of these mailboxes will be linked to your production, UAT or dev instance, this instance will then only process mail in the mailbox the credentials give access to.

  • The setting 'Enable config change tracking for mailboxes' under config > advanced settings, must be enabled to use this functionality. 

Important: The credentials configured must authorise different Azure/Google/IMAP/POP3/EWS mailboxes. If you configure two sets of credentials for the same (Azure/Google/SMTP) mailbox mail will be split between the two instances. 

This means that now when changes are pulled/synced between instances mailbox configuration will be pulled/synced too, so UAT environments can be used to test email configuration. 


This new functionality allows you to:

  • Create a mailbox in Prod or UAT and sync mailbox configuration between instances
  • Configure instance specific mailbox credentials - When configuring credentials you will have an option to specify what instance the credentials are used for
  • Complete testing in UAT instances using the same mailbox as the Prod instance
  • Restore UAT to Prod without loosing the UAT mailbox

Single Credential per Mailbox 

If you are on a version prior to v2.182 only one set of credentials can be configured per mailbox. This makes it difficult to push changes between instances and complete email related testing as the same credentials should not be used to authorise the same mailbox in a different instance. You will need to create a separate Halo mailbox just for your UAT environment. When a UAT is refreshed (synced to Prod) the mailbox against the UAT instance is deleted, and when changes are pulled from UAT into prod, the mailbox setup in UAT will not be pulled into prod.  

Configuration Migration Best Practices

Planning Changes

  • Make changes in concentrated time periods
  • Document all changes and their dependencies
  • Test changes in UAT before applying to production
  • Maintain a regular sync schedule between environments

Security Considerations

  • Sensitive data and passwords are automatically encrypted
  • Access to configuration management should be restricted
  • All configuration changes are tracked and auditable
  • Regular backups should be maintained

Critical Reminder: Always verify these points before major configuration changes:

  • All required dependencies are present in both environments
  • Backup of current configuration is available
  • Team members are notified of pending changes
  • Change window is properly scheduled and communicated

Mitigating API calls between Instances

When changes are synced/pulled between instances this will include any custom integrations/runbooks/webhooks. To mitigate API calls from UAT and Dev environments impacting data in your production environment you will either need to disable any webhooks/runbooks/custom integrations created in UAT/Dev or amend these so data is posted to the correct address (not to production environment).


Make API calls instance Specific 

If you are on v2.178+ webhooks/runbooks/custom integrations can be set to only trigger in chosen environments so when changes are synced to another instance the webhook/runbook/custom integration will be created but no API calls will be made. This is done using the 'Enabled for Instances' setting, found against the webhook/runbook.   

Note: When changing the value of the setting 'Enabled for Instances', the config change must be synced to the other instance(s) before the setting will take effect in the linked instances.

Mitigating Notifications between Instances

When changes are synced/pulled between instances this will include any notifications. To mitigate notifications you will need to amend/disable any notifications created in your UAT/Dev environment. 


Make notifications instance Specific 

If you are on v2.192+ notifications can be set to only trigger in chosen environments so when changes are synced to another instance the notification will be created but not triggered. This is done using the 'Enabled for Instances' setting, found against the notification.   

Note: When changing the value of the setting 'Enabled for Instances', the config change must be synced to the other instance(s) before the setting will take effect in the linked instances.

Quick Reference Tags

 

Features

Configuration Tracking Change Management Rollback UAT Sync Production Sync Import/Export Version Control Audit Trail

Environments

Production UAT Development Testing Multi-Instance

Processes

Configuration Migration Change Tracking Version Management Backup Restore Security Encryption
#Halo #ConfigurationManagement #ChangeTracking #UAT #Production #SyncManagement #ConfigMigration #VersionControl #Configuration #HaloGuide #ConfigurationBackup #ChangeManagement #BestPractices #ConfigurationControl #SystemAdmin #ITOperations

Popular Guides

  • Asset Import - CSV/XLS/Spreadsheet Method
  • Call Management
  • Creating a New Application for API Connections
  • Creating Agents and Editing Agent Details
  • Departments and Teams
  • Halo Integrator
  • Importing Data
  • Multiple New Portals with different branding for one customer [Hosted]
  • NHServer Deprecation User Guide
  • Organisation Basics
  • Organising Teams of Agents
  • Step-by-Step Configuration Walk Through

Footer

Products

Company

  • Contact us
  • Events
  • Channel Partners
  • Technology Partners
  • Distributors
  • Referral Program

HaloPSA

  • Features
  • Integrations
  • Mobile Apps
  • Blog
  • Pricing

Key Features

  • Service Desk
  • Sales CRM
  • Billable Time Tracking
  • Reporting
  • Contracts
  • Billing
  • Stock Management
  • Projects

Compare PSA

  • ConnectWise
  • Datto Autotask
  • Accelo
  • Harmony PSA
  • Naverisk
  • Top Desk
  • Kaseya BMS
  • Atera
  • Freshservice

Social

  • Terms and Conditions
  • Privacy Policy
  • Security
  • GDPR
  • Modern Slavery Statement
We've moved!

Please visit our new website at USEHALO.COM/HALOPSA