Change Requests

Change Requests (CRs) provide a controlled, branch-based process for making changes to items. Each CR creates an isolated editing branch in the workarea’s git repository, and modifications go through an approval workflow before merging back to main.

Change Request List

Navigate to Change Requests in the sidebar. Filter by status: All, Draft, Open, In Review, Approved, or Merged. CRs are grouped into Active and Closed sections when viewing all.

Creating a Change Request

1. Navigate to Change Requests in the sidebar
2. Click New Change Request
3. Enter a title and an optional description explaining the proposed change
4. The CR is created in Draft status with its own branch

The Change Request Lifecycle

A CR’s status is driven by its workflow — use the status dropdown in the detail page header to see and perform the available transitions, exactly as for items. The default change-request workflow is:

Transition	From → To
Submit	Draft → Open
Request Review	Open → In Review
Approve / Reject	In Review → Approved / Rejected
Merge	Approved → Merged
Reopen	Rejected → Draft

Administrators can change these statuses and transitions — including which statuses may merge — in Settings → Workflows (the Change Request workflow). Transitions can carry guards and permission requirements like any other workflow.

Note: A CR’s status can never be changed by editing a field — it only moves through workflow transitions.

Working in CR Mode

1. Open a CR and click Enter Branch to enter CR mode
2. A blue Change Request Mode banner appears at the top of the screen showing the CR ID, title, and branch name
3. Edits to existing items are now recorded on the CR’s branch instead of main
4. Click Exit Branch in the banner to return to the main branch

Viewing Changes

The CR detail page shows a Changes section summarizing all modifications on the branch. Each change shows the item ID, title, type badge, and a color-coded change type (Added, Modified, or Deleted).

Merging Changes

Merging is part of the workflow: performing a transition into the Merged status is the merge. The Merge to Main button appears only when the CR’s workflow offers a merge transition from its current status and you hold that transition’s permission — with the default workflow, that means the CR must be Approved.

The merge first integrates the latest main into the CR branch, then fast-forwards main to include the branch’s changes, re-indexes the affected items, and deletes the CR branch. If the integration hits conflicts, the merge is aborted with the list of conflicting files and the CR’s status is left untouched — resolve by pulling from main first.

Pulling Updates

Click Pull from Main to merge the latest main branch changes into your CR branch. This keeps your branch up to date when others have made changes. If there are conflicts, the conflicting files are listed below the action buttons.