Environments, config promotion and go-live discipline in Halo
How configuration moves from Development to Test to Production in Halo — what the
platform enforces for you, what it deliberately does not, and the governance that needs to be
agreed before your first live promotion.
Each instance has a single source instance. Development cannot sync straight to Production.
Changes apply in order
Halo applies changes sequentially. It cannot detect conflicts or dependencies between them.
Rollback is not an undo
Rolling back reverts every change made after and including the one you select.
Environment model
Production is the source of truth. Everything else is a clone of it.
Sub-production environments in Halo are not built from scratch — they are copies of Production,
brought back into line when the pipeline drifts. Configuration enters at Development and moves up.
Build
Development
Entry point for all configuration. Developer access only — not a sandbox.
Validate
Test / UAT
Mirrors Production. Where user acceptance testing happens before anything is promoted.
Live
Production
Source of truth. Config editing locked once you are live.
Push — Development → Test → Production
Illustration of the standard Halo promotion pipeline — not a product screenshot.
One source per instance
From v2.182 you can set a source instance under Configuration > Instances, and
syncing then runs in one direction only. Pipeline syncing takes effect as soon as a source is set.
A single linear chain is the model to aim for.
Restore is a support request
Restoring a sub-production instance from Production raises a request with Halo Support — and
the ticket data in that instance is lost. It is not a casual refresh button, and nobody should
trigger one outside an agreed window.
Same version across the pipeline
Every instance in a configuration pipeline must be running the same version of Halo. Syncing
between instances on different versions is not supported and is blocked by the platform.
The exception: more than one instance feeding Production
A single linear chain is the recommendation, and it is what most organisations should run. It is
possible to have more than one instance flowing into the same environment where there is a real
reason for it — the common case being a separate Beta or Test instance used to trial
upcoming features, deliberately kept off the main chain so that work does not hold up the normal
Development to Production flow for months at a time.
Treat it as a considered exception with a named owner, not a starting point. Every additional
inbound path is another way for the change log to interleave, and interleaved changes have to be
pushed together whether you planned for that or not.
Instances that sit outside the pipeline
Sandbox
Free-form space to prototype and try approaches without polluting the pipeline. Once something
works, rebuild it cleanly in Development. Usually kept in line with Production so prototyping
reflects the real live state.
Beta
Runs the Halo beta release so teams can evaluate upcoming features ahead of general
availability. Valuable in larger organisations with longer planning cycles, and a poor choice
for any instance inside a live pipeline.
Release Candidate
A copy of Production on the next scheduled version, used to confirm an upgrade breaks nothing.
Halo's own guidance is that most customers do not need one — it is a trust-but-verify step
some larger enterprises keep.
Config tracking
Every save is logged. Every change moves in order.
Halo tracks configuration changes automatically and promotes them sequentially. That makes the
audit trail excellent — and makes discipline in Development non-negotiable.
An automatic audit trail
Config change tracking is switched on under Configuration >
Advanced Settings. From then on every save to a tracked entity writes to the change list
at View config changes, newest first. Passwords and
sensitive data are encrypted and their detail is not shown.
Sequential, not selective
Changes are applied in order, and the platform cannot detect conflicts or interrelationships
between them. Skipping one risks ID misalignment, cross-wiring of unrelated processes, and
dependency breaks that surface much later.
Push, pull and the gap between
Sync changes up to the next instance or pull them down from the source. Halo shows how many
changes each instance is ahead or behind, and lets you set a cut-off date so only changes older
than that point are carried across.
Rollback takes the stack with it
“Roll back before this change” reverts every change made after and including
the one selected. It is not a single-change undo, so roll back a whole batch — never
something halfway down the list.
Lock Production
Disable editing of config tracked entities in production
stops direct changes in the live instance. Administrators see a banner, which can be used to lift
the lock temporarily if a genuine emergency demands it.
Not everything is tracked
Around twenty entity types sit outside config tracking — including language packs, AI
suggestions, tax rates and rules, screen layout profiles, call scripts and cost centres. These
must be replicated in each instance by hand.
Source: Halo configuration change tracking and instance pipeline management guide —
Halo Support Portal
The harder pattern
When you are still onboarding and already live
A single pipeline is straightforward. It gets harder when live customers need enhancements at the
same time as new ones are being built — two streams of change heading for the same Production
instance.
Stream A — business as usual
Dev 1
UAT 1
Production
Enhancements and fixes for customers already live. Small, frequent, change-controlled.
Stream B — onboarding
Dev 2
UAT 2
Pre-prod
Build for the next customer. Pre-production is where the two streams are reconciled before
anything reaches live.
The rule that makes it work
Every time the live stream pushes to Production, that change has to come straight back down to
pre-production and then into the onboarding UAT — and the onboarding work has to be re-tested
against it. Skip that and the two streams drift until a promotion silently overwrites something
that mattered.
A branched model like this needs to be designed deliberately rather than assembled as you go.
Agree the sync order, the ownership of each hop, and who is permitted to request a restore
— before the first customer goes live.
Integration safety
A restored instance will happily fire at your live systems
When a sub-production instance is restored from Production, the integration configuration comes with
it. Left unchecked, a test environment starts emailing real users and raising real alerts.
Enabled for Instances
Webhooks, runbooks and custom integrations can be restricted to chosen environments. The object
still syncs to the other instance, but no API calls are made. Note the setting change itself has to
be synced before it takes effect there.
Notifications too
Notifications carry the same instance-scoping setting — so a restored test environment does
not start notifying real end users about tickets that were copied down with it.
A mailbox per environment
From v2.182 a single Halo mailbox can hold multiple sets of credentials, linked to specific
instances, via the Credentials button on the mailbox. Point
non-production at a dedicated test mailbox — never the live one.
Restrict sign-in per instance
A single sign-on connection can be scoped to one instance, and claim validations then control who
may sign in based on what the identity provider returns — so only developers reach
Development. Connection secrets belong to the instance they sit in.
Alerting and monitoring
Re-point or disable alert destinations after a clone-back. Non-production alerts belong in a test
channel, not in the queue your service desk works from at three in the morning.
Decide the data question early
A copy-down brings live ticket, contact and asset data with it. Agree in advance with your security
and data protection people what may exist in a sub-production environment, and what has to be
wiped — before the first clone, not after.
Access and control
Who can change what, and where
Halo gives you the controls. Deciding who holds them is a governance question, and it is best
answered before the pipeline is live rather than after something goes wrong.
Control
Setting
Where
Lock Production
Disable editing of config tracked entities in production — blocks direct edits to any tracked entity; admins see a banner that can lift it in an emergency.
Configuration > Advanced Settings
Who can promote
Can push configuration changes to other instances — per-agent permission, on by default for the Administrator role.
Agent role configuration
Refuse inbound pushes
Do not allow config changes from other instances to be pushed to this instance — useful where administrators differ between instances.
Configuration > Advanced Settings
Enforce the pipeline
Set Source Instance — one source per instance, one direction only. Development cannot sync directly to Production (v2.182+).
Configuration > Instances
Sign-in per environment
Each environment has its own instance URL. Scope each single sign-on connection to one instance, then use claim validations to control who may sign in.
Single Sign On module
Entity linking across instances
Entities are matched across instances by Halo ID. Where those differ, Use third-party IDs for linking Agents, Users, Roles, Teams, and CABs to change tracked entities matches on an external ID from Entra or a CMDB instead.
Configuration > Advanced Settings
Version alignment
All instances in a pipeline must run the same Halo version. Cross-version syncing is blocked by the platform.
Platform-enforced
Wrap it in your change process
✓Raise platform changes as change records in Halo itself, with a change type that identifies the platform, so releases are visible to the people who own service stability.
✓Consider break-glass rather than standing admin rights in Production — temporary elevation against a raised request, then removed.
✓Name who is allowed to request a restore, and require notice. A clone-back nobody expected is one of the fastest ways to lose a week of work.
✓Keep a shared configuration record that admins update as part of the change, so the platform is documented as it evolves rather than reconstructed later.
Plan around Halo's release calendar
Because every instance in a pipeline has to sit on the same version, upgrade timing is a pipeline
concern, not just an infrastructure one.
✓The stable path upgrades quarterly, rolled out across several weeks.
✓The release candidate is announced and available to opt into four weeks before it becomes stable.
✓The upgrade schedule is communicated two weeks before the process starts — enough notice to set a freeze window around a go-live.
✓The beta path moves roughly every two weeks, which is why beta is a poor choice for an instance inside a live pipeline.
Pipeline discipline
Seven rules that keep a Halo pipeline healthy
Most pipeline problems are not platform problems. They come from how the team works inside it.
1
Development is not a sandbox
The moment somebody experiments in Development, its change log fills with work nobody intends to
promote — and the only clean way out is a clone-back. Prototype in a Sandbox instance
instead, outside the pipeline, then rebuild the approach cleanly in Development once it works.
2
Promote in small batches, and finish one before starting the next
Even a modest configuration change can generate hundreds of individual entries in the change log.
Short cycles keep each promotion reviewable and each rollback survivable.
3
Agree who owns which area before two people open it
Once changes from different people become interleaved in the change log they cannot be separated
cleanly — they all have to be pushed together, in order. If one team is mid-way through a
large piece of work, nobody else can push ahead of them. Concurrent work in Development ties
everyone's push timeline together.
4
Rehearse a promotion — and a rollback — before the live one
Your first promotion into Production should not be the first promotion anyone has done. Run the
full loop while the platform is still unused, including the rollback, so the mechanics hold no
surprises on go-live morning.
5
Treat manual export as an emergency tool, not a workflow
Selected changes can be exported to JSON and imported elsewhere, which is invaluable when one
urgent fix has to move without everything behind it. Used routinely it produces silent
misalignment that surfaces weeks later. Halo advises against it, and so do we.
6
Nobody requests a restore without telling everyone
A restore resets the instance to Production and takes its ticket data with it. Tie it to a
maintenance window and a named approver, and confirm no unsynced changes are sitting in the
instance first.
7
Keep a manual list of what does not travel
The untracked entities will not follow a promotion. Keep a written list of what has to be
recreated by hand in each instance and check it as part of every go-live, because nothing in the
platform will remind you.
FAQ
Common questions
How many environments do we actually need?
Three covers most implementations: Development for building, Test or UAT for validation, and
Production. A fourth pre-production instance earns its place when you are enhancing a live platform
and onboarding new users of it at the same time, because it gives you somewhere to reconcile the two
streams before anything reaches live. Sandbox, Beta and Release Candidate instances are separate
again — they sit outside the pipeline and serve different purposes.
Can more than one instance push into Production?
It is possible, but it is the exception rather than the model to design for. A single linear chain
is what we would recommend for almost every organisation, because it keeps the change log
predictable and the promotion order obvious. The case that genuinely justifies a second inbound
path is a Beta or Test instance used to trial upcoming features, held off the main chain so that
work does not block normal delivery for months. If you go that way, do it deliberately and give
each path a named owner.
Can we push a single change without everything behind it?
Technically yes — individual changes can be exported to JSON and imported into another
instance. Halo's own guidance is that this is ill-advised, because a change that depends on one you
skipped produces a misalignment that may not surface for weeks. Keep it for genuine emergencies and
make sure the whole dependency travels with it.
What happens if we roll back a change in Production?
Halo reverts every change made after and including the one you select — it is not a
single-change undo. In practice that means rolling back a complete batch, so the safest position is
to promote in small batches and roll back from the top of the list rather than from somewhere in the
middle of it.
Will our integrations fire from a test environment?
They will, unless you scope them. Webhooks, runbooks and custom integrations carry an
“Enabled for Instances” setting, and so do notifications, so the object can exist in a
sub-production instance without making live API calls. Mailboxes hold separate credentials per
instance from v2.182 so non-production can point at a test mailbox.
What does not get promoted between instances?
Around twenty entity types sit outside config tracking, including language packs, AI suggestions,
call scripts, certificates, cost centres, currency, tax rates and rules, screen layout profiles,
asset templates and billing templates. Ticket, contact and asset records are data rather than
configuration and do not travel either. Halo publishes the current list and will confirm the status
of anything not on it.
Can Allied ESM set this up for us?
Yes. We can design the environment model, configure the pipeline and instance settings, and work
with your service management team on the governance that sits around it — scoped and quoted as
part of your project. If you already have a pipeline that has drifted out of line, we can review it
and set out what it takes to get back to a clean promotion path.
Get the pipeline right before the first go-live.
Environment design, instance configuration and promotion governance — scoped as part of your Halo
implementation, or as a standalone review of a pipeline that has already drifted.