Overview

Source Control in Nected lets your teams version, manage, and collaborate on all automation assets using Git. It introduces a structured development workflow where every change is tracked, reviewed, and promoted through a predictable lifecycle—whether you use GitHub today or Git providers in the future.

If you are running the On-Premise Agent, upgrade to v1.0.5+ to enable Source Control.

Source Control is optional, but once enabled:

• The Git panel shows real-time sync status (Ahead, Behind, Ahead & Behind)

• Any difference between your workspace and the selected Git branch becomes visible through sync indicators

This allows teams to build safely, test confidently, and maintain full traceability across all Synced Entities.

Why Source Control Matters

Source Control provides a unified, auditable development workflow across Rules, Workflows, Integrations, Datasets, Variables, and other Synced Entities. It gives every contributor—engineering, product, or business—access to the same disciplined lifecycle your software organization already uses.

With Source Control, your teams can:

• Version every structural change to Synced Entities in Git

• Work on multiple branches without affecting production

• Collaborate through pull requests, reviews, and approvals

• Merge changes safely using Git workflows and protection rules

• Push and pull updates between Nected and your repository

• Maintain full historical lineage of all updates

• Resolve sync conflicts with clear UI options inside Nected

This ensures accuracy, repeatability, compliance, and safer collaboration across your entire automation development pipeline.

What Gets Synced / Not Synced

Nected syncs the following assets into your connected Git repository:

Resource Type	What Is Tracked
Rules	Everything including published versions
Workflows	Everything including published versions
Integration	Name and metadata except the configuration and the credentials.
Datasets	Everything
Cron/Schedulers	No. Enabled only on the default branch if Git is enabled in Nected
Workspace Settings	No
Teams & Users	No
Variables	All the global and secret variables (only names, not the credentials)

Any integration configs and sensitive credentials (like authorizations and api_key) are never exported in Git sync, only the references with the names. You need to update those configs manually during/after sync.

How It Works (Development Lifecycle)

Source Control in Nected follows a clear Git-driven lifecycle that matches the way modern engineering teams build, review, and deploy software. When you enable Source Control, all changes to your Nected workspace flow through Git—ensuring traceability, predictability, and controlled releases.

The full lifecycle includes: Repository setup → Branch selection → Push/Pull operations → Review & Merge → Production deployment

Below is the complete flow, including how it behaves across workspaces.

1. Connect Git Repo

The lifecycle begins when the workspace admin prepares the Git repository.

Create a Personal Access Token (Git Admin)

Before any workspace admin connects or authenticates with the Git repository, the Git Admin (or Workspace Admin with GitHub access) must create a Personal Access Token (PAT). This token is required for Nected to push and pull changes to the repository.

You may use either:

Fine-Grained Personal Access Token

When generating a Fine-grained PAT:

• Select the specific repository that will be connected to Nected

• Under Repository Permissions, grant:

  • Contents → Read & Write

• No additional permissions are required

Fine-grained tokens offer better security and are preferred for production work.

Classic Personal Access Token

If using a Classic PAT:

• Only the repo permission (Read & Write) is required

• No other scopes are needed

Classic tokens are simpler but less restrictive than fine-grained tokens.

After that, give the PAT to your workspace admin (or if you're the workspace admin, then save it), as now the admin needs to configure the git through UI.

Note: Connecting a Git repository, selecting the default branch, setting the token, and completing initial configuration can only be done by a Nected workspace admin.

Based on your access to the workspace, your flow of connecting to Git will be different. Here are the two flows:

If you're a Workspace Owner / Primary Admin

This flow applies only to the workspace owner or the first workspace admin responsible for configuring Source Control.

This admin performs the full Git setup once per workspace.

Steps:

1. Create a blank GitHub repository.

2. Generate a Personal Access Token (Fine-grained or Classic) with Read/Write permissions.

3. In Nected, go to Git Repository → Connect to Git.

4. Enter the:

   • Repository URL (HTTPS or SSH)

   • Personal Access Token

5. Nected connects to the repository and fetches the available branches.

6. If no branch exists, master becomes the automatic default.

7. If multiple branches exist, select the default branch for the workspace.

If you're an Additional Workspace Admins

This flow applies when the workspace owner adds another user and assigns them the Admin role. In this case, the repository is already connected, so the new admin only needs to add their own PAT.

Steps:

1. The Git repository is already configured by the primary admin.

2. The new workspace admin opens Git Repository → Add Personal Token.

3. Enter a valid Personal Access Token provided by the Git admin.

4. This token grants the admin permission to work on authorized branches.

Learn more about how to connect with GitHub

Note: The Git repository is immutable once connected. Choose the correct repository during setup.

2. Select Branch

Once the Git repository is connected and authenticated, the next step is selecting the branch you will work on.

Learn about how to set your Branch

For Primary Workspace Admin

• After connecting the repo, Nected automatically detects all branches.

• If the repository has no branches, GitHub’s default (master) becomes the workspace’s default branch.

• If multiple branches exist, the admin can select the default/base branch, typically main or master.

Only the primary workspace admin defines this default branch, and it is configured once per workspace.

For Additional Workspace Admins

• Additional admins do not choose the default branch—it is already set by the primary admin.

• They only see and can switch to branches they have been granted access in GitHub.

This ensures full alignment with GitHub’s access and security rules.

3. Creating & Editing Logic in Nected

Once connected:

• Users create or modify Rules, Workflows, Datasets, Integrations, API triggers, and Schedulers.

• Every change is auto-saved locally.

• The Git panel shows whether the workspace is:

  • Ahead (local changes not pushed),

  • Behind (remote changes not pulled), or

  • Ahead & Behind (diverged).

Changes remain local until committed.

4. Commit & Push

Users commit changes directly from the Nected UI:

• Workspace-level commits (push everything modified)

• Resource-level commits (push only a specific Rule, Workflow, or Dataset)

Learn more about how to Push changes

During a push, all versions of all Synced Entities are included: Draft, Staging, Published

The push writes the changes to the selected branch in Git.

Review and Merge

• Merge approval is not handled in Nected.

• PR creation, review comments, merge approvals, and conflict resolution all occur in GitHub.

• GitHub remains the authority for: Code governance, Branch protection, Review rules, Merge decisions

5. Pull & Update Workspace

After a PR is approved and merged in GitHub:

• Users click Pull in Nected to import the updated branch state.

• Nected updates all corresponding entities and resolves conflicts through:

  Merge & Pull, Override & Pull, Archive / Archive Overwrite (when conflicts exist)

Learn more about how to pull changes and Sync

This ensures the workspace always reflects the current branch state.

Actual deployment of infrastructure or Nected runtime remains outside the GitHub Sync scope and is controlled via your hosting or GitHub-based CI/CD pipeline.

Teams who want to automate publishing and environment promotion can use GitHub Actions for scripted deployment flows.