Semantic versioning in Artifact Tracker, looping over targets, Git-backed processes, OPA policies, and finer permissions. See what's new in Q3 FY27.
TL;DR
Q3 FY27 makes Release Orchestration better at tracking what you ship and repeating work across targets. Processes, inputs, and activities can now live in Git, and new OPA policy checks and fine-grained permissions give you more control over who can run what.
When we introduced Harness Release Orchestration, the goal was to give teams one place to plan, run, and audit releases. Q3 FY27 (August to October 2026) builds on that with 12 enhancements across four areas: tracking what you ship, repeating work across targets, managing release definitions in Git, and controlling who can do what.
Artifact Tracker and Changesets
Artifact Tracker shows what is going into each release. This quarter it gets better at ordering versions, mapping services, and linking artifacts with less manual setup.
Semantic versioning for artifacts
Semantic versioning is now on by default and can be toggled per service mapping. Artifact Tracker compares versions in semantic order, so a hotfix 1.0.1 that arrives after 2.0.0 is compared with 1.0.0, keeping changesets meaningful.
Learn more
Service mappings can select upstream services from any scope
Service mappings can now select upstream services from the account, organization, or project scope, wherever the mapping is created. Before, an account-scoped mapping could pick only account-level services, and an org-scoped mapping only account or org-level ones.
Learn more
Changeset Git source inferred automatically
The Git source for changesets is now inferred from the build's connector and provider, reducing manual setup. Defaults can still be set at any scope and overridden per service mapping.
Learn more
Automatic artifact association for pipeline-triggered releases
Artifacts from pipelines that directly trigger a release are now automatically associated with that release. For other setups, add a Pipeline Queue activity to link matching artifacts.
Learn more
Looping
Some release work repeats for every target. Looping lets you define it once.
Looping over deployment targets
Looping runs a phase, or a single activity, once per target in a list, creating one child execution per target. Configure targets in the Looping Strategy panel with a static list or a dynamic one from a Queue Activity output, reference the current target with <+target.<field>>, and retry or ignore failed children independently. Looping is in Limited GA; contact Harness Support to enable it.
Learn more
Expression support for the Select Activity Queue field
The Select Activity Queue field accepts an expression as well as a fixed Pipeline Queue activity, so the queue a loop reads from can vary by execution and new services or environments are picked up without editing the process.
Learn more
Git Experience
Processes, process inputs, and activities can now live in Git and stay in step with what is in Harness.
Move to Git for processes, process inputs, and activities
The Move to Git action converts an inline process, process input, or activity into a remote entity in your Git repository, copying the YAML unchanged. Each entity moves independently, except a process input, which can move only after its parent process. Set up the repository, branch, and Git connector first.
Learn more
Branch selector for remote processes in ad hoc releases
The ad hoc release wizard now shows a branch selector next to a remote process, so you can run a process from another branch, for example, to test a change before merging.
Learn more
Automatic sync of Git-backed entities on push
With bidirectional Git Experience enabled, Harness listens for push events on tracked folders such as .harness/. Pushing a new YAML file to the default branch creates the entity, and pushing a change refreshes it after validating the YAML. Invalid YAML leaves Harness unchanged.
Learn more
Governance and Permissions
More control over what runs, who runs it, and under which identity.
OPA policy evaluation for save-for-release groups
Policy sets can now target release groups on save, alongside processes and activities. Error severity blocks the save and shows your deny message, while Warning lets it continue. Typical rules include requiring an approval activity or an owner on every phase.
Learn more
OPA policy evaluation during release runs
Policies also run when a process or release is triggered, for both regular and ad hoc releases. A common rule denies direct process execution, keeping every run scheduled and auditable. Test policies in the Testing Terminal and review results on the Evaluations tab.
Learn more
Fine-grained permissions for activities and processes
Release Management in Access Control now has separate rows for Releases, Activities, and Processes, each with Create, View, Edit, Delete, and Execute, so a team can author processes without running releases. Existing custom roles are migrated automatically. A new setting, Use Service Principal for Pipeline Authentication, runs pipeline activities as the Release Management service, so initiators don't need Execute on the pipeline.
Learn more
What's Next
We are continuing to build toward the areas we outlined at launch, including analytics, cross-release dependencies, and collaboration. To explore everything Release Orchestration offers today, head to the Harness documentation.
Get Started
Explore the Release Orchestration docs linked above, or read the launch post for an overview of processes, phases, activities, and release groups. To see these features in your environment, reach out to your Harness account team.
