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:
- Navigate to Configuration > Advanced Settings
- Locate the "Config Change Tracking" setting
- 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
Once enabled, you can track and manage configuration changes through several interfaces:
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.
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:
- Navigate to the configuration change list
- Locate the change you want to roll back to
- Click "Roll back before this change"
- 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:
- Global settings
- Enabled modules
- Ticket Types
- Statuses
- Action config
- Workflows
- Templates
- Charge Types
- Service Categories
- Services
- Custom Fields
- Custom Tabs
- Custom Tables
- Field Groups
- Canned Text
- Qualifications
- Workdays
- Notifications
- Ticket rules
- Email Templates
- Asset Groups
- Asset Types
- SLAs
- View Lists
- Column Profiles
- Filter Profiles
- Categories
- Teams
- Organisations
- Departments
- Roles
- Lookup
- Asset Fields
- Site Fields
- Chat Profiles
- Approval Groups
- Approval Rules
- User Roles
- FAQ Lists
- Custom Buttons
- Ticket Areas
- Azure active directory integration
- N-able N-central integration
UAT and Production Instance Management
For organizations using both UAT and Production environments, Halo provides tools for managing configurations found in Configuration > Instances.
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.
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.
Quick Reference Tags
