The project changeset
Every edit you make in AI Studio — to a workflow, an app, an entity schema, an integration config, a webhook, or a setting — becomes part of the project’s pending changeset. The changeset is implicit: everything in the project that has been edited since the last release. You make changes; the project’s draft accumulates them. When you’re ready, a single Release publishes everything.Release semantics
| Property | Behavior |
|---|---|
| Atomic | All draft changes publish simultaneously. You cannot cherry-pick individual resources. |
| All-or-nothing | If the release fails (e.g., a migration fails), nothing publishes. The project remains on the prior version. |
| Rollback | Rolling back a release returns the entire project to the prior published state. Per-resource rollback is not supported. |
| In-flight executions | A workflow execution that started before the release finishes on its starting contract version. New executions start on the new version. |
The release UI
Clicking Release opens the release panel:- Summary — A plain-language description of what this release does, auto-generated by the system. Editable before you confirm. This summary becomes the immutable changelog entry once published.
- Per-resource diff — Every changed resource with field-level changes highlighted.
- Migration impact — If entity schema changes are part of the release: “The
risk_levelfield will default tonullon 847 existing patient records.” - Approval status — If approvals are required: who has approved, who can still approve, what’s blocking.
Release request lifecycle
When approval gates are configured, releasing creates a release request rather than publishing immediately:- The project is soft-locked: no new draft changes are accepted.
- If you need to make additional changes, cancel the pending request, edit, and re-request.
- There is no time-based expiration. Pending requests sit indefinitely until manually approved or cancelled.
Approval gates
Approval gates are configured at two levels: org → project.| Level | Default | Configurable by |
|---|---|---|
| Org floor | 0 approvers | Org admins |
| Project | Inherits org floor | Project owners (can only increase, not decrease below org floor) |
- Default is 0: new projects require no approvals. Direct publish is the default.
- Author cannot self-approve: when N>0 approvers are required, the release author is excluded from the approver pool for their own release.
- Any project member with release-approval permission can approve by default.
- No per-resource gates: different approval rules for different resources means different projects.
Sandbox
Sandbox is a project-level twin of production. It uses the same contracts, the same entities (with separate data), and the same runtime — but integration calls are edge-sandboxed.Edge-sandboxing
In sandbox mode, outbound integration calls are never made to real external systems. Each integration adapter declares a response schema; the sandbox runtime:- Renders the exact payload that would have been sent.
- Produces a schema-derived mock response.
When to use sandbox
- Always use sandbox for initial authoring and iteration.
- Use sandbox for testing schema changes before they affect production data.
- Use sandbox when sharing test access with colleagues who shouldn’t touch production.
Switching to production mode
The center pane (live app or test/run console) has a Sandbox / Production toggle. Switching to production mode routes real app traffic and workflow executions to production data and makes real integration calls. The toggle is clearly labeled and requires confirmation when switching to production.Entity migrations in releases
Schema changes are part of the changeset. When a release includes entity schema changes:- Before publish: the system shows the migration impact — affected record count, default value strategy, field disposition.
- On publish: the migration executes atomically with the rest of the changeset.
- Failure: if the migration fails, the entire release fails and the project stays on the prior version.