Branching

By default, every user works in the live branch. Changes made in the live branch take effect immediately — which could potentially break a production system.

Why Branching

Branching lets you make changes to schemas, task templates, and services in isolation. While inside a branch, all modifications are scoped to that branch and do not affect live. Once you’re done, changes can be either merged into live or discarded entirely.

Access & Permissions

Even when a user does not have write access to entities in an organization, group, or project, they are always allowed to create a branch and make changes — as long as they have permission to view the entities. This makes branching a safe way to propose changes without needing elevated permissions.

Since the branch creator may not have merge rights, branches can be shared with other users.

| Action | Who can do it | | ------------------ | ------------------------------------------------------ | | Edit the branch | Branch owner only | | Discard the branch | Branch owner only | | Merge into live | Anyone participating in the branch (with merge rights) |

Using Branches via API

Once a user has access to a non-live branch — either by creating it or having it shared — they can point an access token to that branch. When a task is then triggered via the API, it will use the branched versions of schemas, task templates, and services instead of the live ones.

Combining with Dev Overlay

When working on a branch, you can combine it with Dev Overlay to also test service implementation changes locally — without touching the published version of either the service definition or its code.