Versions and publishing
As your automations evolve, Rival Enterprise keeps clear version histories so you always know which configuration is live and can revert safely if something goes wrong. Publishing is the mechanism by which an updated draft becomes the active, shared release used by agents and team members across your workspace.
The same versioning and publishing model applies to both functions and workflows.
The role of versioning
Section titled “The role of versioning”Every meaningful change creates a distinct, numbered version tag. That history gives you three enterprise safety guarantees:
- Complete lineage — see what changed, exactly when, and which team member authored each modification.
- Instant rollbacks — revert to a known-good historical version in one click if a new release misbehaves or causes unexpected downstream errors.
- Production stability — draft edits do not affect running automations until they are explicitly published, so active business processes stay protected.
Publishing and the approval gate
Section titled “Publishing and the approval gate”Publishing a new version routes through administrative governance, which is what keeps untested changes from breaking live work:
- Direct publishing for admins — workspace administrators can review and publish updated versions straight to the Marketplace catalog.
- Approval routing for builders — when a non-administrative team member publishes an update, the new version goes to an administrative queue for review before it goes live.
- Controlled upgrades — people relying on an approved function or workflow are shielded from surprise behavior changes, because existing assets do not update silently underneath them.
The update lifecycle
Section titled “The update lifecycle”-
Draft your changes. Modify code handlers, schema parameters, or workflow step logic inside the editor without affecting active users.
-
Test interactively. Run draft test cases against live connections or sample payloads to verify execution accuracy.
-
Write release notes and submit. Attach clear notes describing the bug fixes or feature additions, select the target publication scope, and submit for review.
-
Administrative review and release. Once an admin approves, the new version deploys as the default active release. Older versions stay archived in history for rollback reference.
Draft, published, and archived states
Section titled “Draft, published, and archived states”| Capability | Draft state | Published version | Archived version |
|---|---|---|---|
| Execution scope | Isolated testing panel only | Active in production agents and workflows | Inactive; preserved for audit and rollback |
| Visibility | Visible to the builder and admins | Visible in the enterprise Marketplace catalog | Visible in version history logs |
| Administrative gate | No review required | Requires admin review for non-admin builders | Preserved as a previously approved snapshot |