Releases & change control
Build the change in Development (Pro), a working copy of Production with its data. Preview every item and its dependencies, decide conflicting screens, rules and workflows item by item, and publish a release Bondi refuses if Development or Production changed after your review.
30-day trial with Pro capabilities · no card required
A release on Pro
The client sign-off change AI Builder proposed is ready in Development. It touches a table, a rule, a screen and a workflow, and a colleague reordered the same screen in Production last week.
Change set 4 items
| Type | Item | Change |
|---|---|---|
| Table | deliverables | Add approved_by and approved_on |
| Rule | Deliverable status | Block Completed without client approval |
| Screen | Deliverables board | Add a client approval column and filter |
| Workflow | Delivery hand-off | Assign the delivery lead when the client approves |
Conflict
Screen · Deliverables board
Keep Production
Columns reordered by a colleague
Take Development (chosen)
Client approval column and filter
Preview
Every item, its dependencies and why any item is skipped or blocked
Preflight
Checked against Production as it stands at merge time
Fingerprint
Refused if either side changed after your review
A release carries schema and configuration, not records: rows created in Development never replace Production data. Removed columns that still hold values are archived and purge-protected for 30 days.
Diagram of a release from Development to Production: the change set, the conflict decision, the preflight and the fingerprint check follow the product's behavior. Names are sample data.
Want to see this on your own process? Our team will walk through it with you.
Walk through your release processWhat it does
Development starts as a working copy of Production, with its schema and business data, so you check each change to tables, rules, screens and permissions against the records your teams work with today. Workflows are built and reviewed there but run only in Production, and run history is not copied.
Tables, rules, screens, permissions and workflows move together as one change set. Before anything reaches Production, the review shows every item, what it depends on and why any item is skipped or blocked.
When the same screen, rule or workflow changed in both places, the owner or admin publishing the release decides each one: keep Production or take Development. The release waits until every one has a decision. Where both sides edited the same simple field, such as a title, Production's version is kept and the review shows Development's change as skipped.
A release is bound to a fingerprint of the preview and preflight you reviewed. If Development or Production changed since then, Bondi refuses the release and you review again. If a database step ends with an uncertain outcome, Bondi marks the commit for recovery and raises a high-severity incident instead of running the migration twice.
Removing a table or column that still holds data archives it instead of dropping it. For 30 days no one can purge it. Restore it, or export an archived column's values as CSV.
Screens, workflows and task types keep version history. An owner or admin restores an earlier version as a draft, reviews it and publishes it like any other change.
The principle
A change to how your operation runs gets the discipline of a software release: built in a copy of Production, reviewed as one change set, published by an owner or admin, and refused if either side moved after the review.
Under the hood
The mechanisms behind the page, for the architects and security reviewers evaluating it.
Read the technical documentationEach environment has a dedicated PostgreSQL database and its own Data API worker. Development is a copy-on-write branch of Production's database; automation run history is not carried over. Each Production environment has one Development environment at a time, and only Production can be branched.
Before it executes, a commit re-checks that the environment's schema metadata, the selected changes, a fingerprint of each change and fingerprints of the database objects they affect still match what was prepared. Any mismatch refuses the commit. An uncertain DDL outcome marks the commit as failed to finalize and raises a high-severity incident instead of re-running the migration.
Each merge runs as a tracked operation with a preview and a preflight check against current Production, and is bound to a hash of both; a stale review is refused. A conflicting configuration item takes an explicit Production or Development decision, bound to the state of both versions. Conflicts on tables, columns, indexes and custom types block the merge until Development is recreated from current Production.
Removed schemas, tables and columns that still hold data are renamed under a legacy prefix instead of dropped, and an owner can purge them only after 30 days. Empty ones are dropped. Schema migrations move forward; recover a change through the archive or, on Pro, by restoring a version.
Designed boundaries
Standard has one Production environment, and changes apply to it directly. Separate Development and Production environments are a Pro capability.
Development contains a copy of Production data, and the roles and permissions copied from Production apply there too. Review who holds which role before you create a Development environment.
A conflict on a table, column, index or custom type has no side to pick. It blocks the release until you create a new Development environment from current Production.
Publishing is limited to your organization's owners and admins. One of them publishes a release; there is no two-person approval step.
How access is controlledAvailability
Questions buyers ask
You reverse a release with another release. On Pro, restore earlier versions of screens, workflows and task types as drafts and publish them. Removed tables and columns that held data stay in the archive, protected from purge for at least 30 days, and can be restored until an owner purges them. There is no one-click rollback, and schema migrations only move forward.
Yes. Development is a copy-on-write branch of Production, with its schema and data but without its run history. The same roles and permissions as in Production apply there, so review who holds which role before you create it.
A release carries schema and configuration changes. Records created in Development never replace Production data.
On Standard, owners and admins draft changes and publish them directly to the single Production environment. Pro adds Development, merge review, conflict decisions and version restore.
Your organization's owners and admins. One of them publishes a release; there is no two-person approval step.
Next step
Show us how your team changes systems today: who asks, who approves, who publishes. We'll map it to Development, merge review and release, and answer the change-control questions in your security review.
