Synchronize configuration
Once Source Control is enabled, Casewhere keeps the Git-tracked folder and the running configuration in sync. This article explains the three ways configuration moves between them and the everyday Git workflow that ties environments together.
Automatic export on save
Every change you make in Casewhere Admin is written to the folder automatically as part of the same save. When you create, edit, or delete a resource, its JSON file is created, updated, or removed accordingly — so the folder always reflects the current configuration without any extra step.
Export runs after the change has been committed to the runtime, and a failure to write the folder is logged but never blocks your save. If the folder and runtime ever drift (for example after a crash, or a bulk migration), use Export All To Folder to reconcile them.
The Source Control page
Open Deployment → Source Control. Two toolbar actions move the whole folder to or from the runtime:
| Action | Direction | What it does | When to use |
|---|---|---|---|
| Export All To Folder | Casewhere → folder | Writes the current configuration of every product and resource into the folder. | Initial seed, or to reconcile after drift. |
| Reload From Folder | Folder → Casewhere | Imports resources whose folder content differs from the running configuration. The folder wins. | After a pull brought in changes. |
The Last result area reports the outcome — the totals processed, how many were imported or exported, and any errors.
Reload From Folder applies changes to live configuration, and the folder version wins on any conflict. Only resources whose content actually differs are re-imported (audit metadata is ignored in the comparison), so a reload is safe to run repeatedly, but always reload from a known, reviewed commit.
Replace the folder from a snapshot: Zip Push Deploy
Zip Push Deploy (toolbar) uploads a configuration-folder snapshot as a .zip and swaps it into place: the current folder is first backed up to a timestamped zip in a sibling …-backups folder, then emptied — the .git working tree is preserved — and replaced with the contents of the uploaded zip. Leave Auto Reload Folder after deploy ticked to apply the result to the runtime immediately. It is a quick way to move a whole configuration snapshot between environments without a Git round-trip, and the backup means the previous state is always recoverable.
Synchronize one resource: Fetch From Folder
You don't always need a full reload. On any management grid (Data Classes, Workflow Definitions, Rules, and so on), select a resource and choose DevOps → Fetch From Folder to reload just that one resource from the folder. Casewhere locates the file by its id and re-imports it only if its content differs from the running configuration. This is handy when you have pulled a change to a single resource and want to bring just that one into the runtime.
Drive Git from Casewhere
The Source Control page includes a Git menu that runs Git in the configuration folder, on the server — so you can do the everyday Git workflow without leaving Casewhere Admin. You can still use your own Git tooling or CI for anything; the menu is a convenience, not a replacement. Every command's raw output appears in the Last result area.
| Menu item | Runs | Notes |
|---|---|---|
| Status | git status |
The working-tree state of the folder. |
| View changes (diff)… | git diff |
Opens all pending changes in a side-by-side Monaco diff viewer with syntax highlighting. |
| Checkout to… | git checkout <ref> |
Switch to a branch, tag, or commit. Run Reload From Folder afterwards to apply the switched files. |
| Create branch… | git checkout -b <name> |
Creates a branch from the current commit and checks it out. |
| Fetch | git fetch |
Updates remote-tracking information without touching your files. |
| Pull | git pull |
Pulls and merges remote changes into the folder. Resolve conflicts, then Reload From Folder. |
| Sync with remote (discard local)… | git reset --hard + git clean -fd + git pull |
Destructive. Discards every local change (including untracked files) and replaces the folder with the remote. Gated by a type-DISCARD confirmation. |
| Commit… | git commit |
Prompts for a message and commits tracked changes. |
| Commit all (incl. new files)… | stage everything + git commit |
Stages new, modified, and deleted files, then commits (after an extra confirmation). |
| Push | git push |
Pushes committed changes. If the branch has no upstream, it is published and its upstream set automatically. |
| Log | git log |
Recent commit history. |
The Git menu acts with the server's Git identity and credentials, and Sync with remote is irreversible. Treat it as an administrative capability — see Access and permissions.
The everyday Git workflow
Git operations can be performed with your own tooling or from the Git menu above. A typical multi-environment loop:
sequenceDiagram
participant AdminA as Admin (environment A)
participant FolderA as Folder (environment A)
participant Remote as Git remote
participant FolderB as Folder (environment B)
participant AdminB as Admin (environment B)
AdminA->>FolderA: Save change in Admin (auto-exported)
FolderA->>Remote: Commit & push (Git menu or external)
Remote->>FolderB: Pull (Git menu or external)
FolderB->>AdminB: Source Control → Reload From Folder
- Make changes in Casewhere Admin on environment A. They are exported to the folder automatically.
- Commit and push the folder — from the Git menu (Commit all…, then Push) or with your own Git tooling / CI. Review changes as a pull request if you wish — every resource is a readable JSON file.
- On environment B, pull the changes — from the Git menu (Pull) or with Git.
- In environment B's Admin, run Reload From Folder (or Fetch From Folder for a single resource) to apply the pulled configuration to the runtime.
Best practices
- Reload from a reviewed commit. Because the folder wins, only reload after you have pulled a known-good revision.
- Reconcile, don't hand-sync. If you are unsure whether the folder matches the runtime, run Export All To Folder to bring the folder up to date, then commit.
- Keep secrets out of the repository. Configuration JSON can reference environment-specific values — manage environment differences through your deployment settings, not by committing per-environment secrets.
- Pair with DevOps packages for releases. Use Source Control for history and review, and DevOps packages to promote a curated release between environments.
- Combine with AI Integration. When you build configuration with AI Integration, Source Control captures exactly what changed so you can review and roll back AI-assisted edits like any other commit.