Multi Enviorment
Nected natively provides two runtime environments: Staging and Production. Git-based Source Control extends this model by allowing teams to maintain and manage any number of development environments using Git branches.
With this combined approach:
Git branches represent development environments
Nected Staging represents the testing environment for those branches
Nected Production represents the live execution environment once branches are merged
This lets teams work on multiple features, QA cycles, experiments, and releases in parallel—each isolated within its own Git branch.
How Git Branches Become Separate Environments
Each branch in your Git repository acts as its own “environment” during development. For example:
dev/payment-service→ Payment team’s development environmentqa/rule-updates→ QA testing environmentuat/feature-x→ UAT environment for business reviewersrelease-candidate→ Pre-production environment
When you switch to a branch inside Nected:
All Rules, Workflows, Datasets, and Variables load from that branch
All changes you make belong only to that branch
You can test them in Nected Staging without affecting other branches or Production
Merging the branch in GitHub promotes those changes toward Production
Git branches allow unlimited environment parallelism; Staging/Production allow runtime isolation.
Typical setup using Git branches could be look like this:
Feature Environments
Independent development for new functionality; isolated experimentation
feature/discount-rule
feature/new-eligibility-check
QA Environments
Regression, performance, and functional testing by QA teams
qa/regression-suite
UAT Environments
User acceptance testing by product/business teams before approval
uat/invoice-logic
Release Environments
Preparing release candidates, stabilizing logic before production merge
release/2025-q1
Production
Live production branch used for real execution and published logic
main / master
Each of these branches is a separate environment inside Nected until merged.
Last updated