Breaking changes

Mitigate the impact of version 2026.8 breaking changes

• No reinstall or redeployment is needed when these changes ship. They will apply as standard database migrations during your normal automation orchestrator upgrade.
• There is no supported downgrade path once a version containing one of these changes has been applied. If you may need to revert, back up your PostgreSQL database before upgrading. Automation orchestrator does not manage or back up your database for you.
• Because these changes make delete operations remove more data than before, review the contents of a workflow, project, user, or group before deleting it. There is no restore capability for any of these resource types.
• Export or back up any resources you might need before upgrading, because resource deletion is now permanent.

Projects: deleting a project permanently deletes everything in the project (2026.8)

In a future release, deleting a project permanently deletes all of its contents, including workflows, workflow versions, execution history, and credentials. Today, project deletion already removes most of this, but going forward the behavior is fully consistent. A project and its contents are not recoverable after a project is deleted.

Workaround: Before deleting a project, make sure nothing inside it needs to be kept. Export any workflows you want to preserve, and move or recreate any credentials you still need elsewhere first.

Users and groups: deleting a user or group permanently removes more associated data (2026.8)

In a future release, deleting a user permanently removes that user's data. This includes group memberships, linked identities, active sessions, approval-approver associations, API token configuration, and usage records. Deleting a group permanently removes its memberships, identity-provider group mappings, and approval-approver associations. In both cases, role assignments tied to the deleted user or group are also removed. If a deleted user had previously created a group, the group itself is not deleted. Only the recorded creator is cleared.

Workaround: Before deleting a user or group, confirm that any role assignments, approvals, or memberships tied to them do not need to be preserved elsewhere. They are not recoverable once the deletion completes.

Approvals: approval detail responses expose full downstream step parameters, including script code (2026.8)

Issue: GET /approvals/{id} returns the full parameters of the downstream workflow steps and approval gates. These parameters, including script step code, appear in the next_step_approved and next_step_rejected fields.

This response includes more detail than an approver needs to make a decision. An approver might not have permission to view the workflow's contents, and step parameters can contain proprietary logic or sensitive values.

Possible breaking change: If this is fixed by removing parameters from next_step_approved and next_step_rejected, any integration reading those fields (for example, to display script code to approvers) stops receiving that data. This would not be an OpenAPI schema change (the field was never a declared property). However, it would remove something the response currently and consistently includes.

Workaround: None yet. No change has shipped. If you depend on next_step_approved.parameters or next_step_rejected.parameters, be prepared for those fields to disappear if this is addressed.

Approvals: unrecognized query parameters on list endpoints (2026.8)

Issue: A report claims that unrecognized or misspelled query parameters on GET /approvals (and similar list endpoints) silently return zero results instead of being rejected or ignored. This makes it impossible to distinguish a genuinely empty result set from a malformed request. This behavior was not reproducible against the current codebase. The issue is being tracked in case it resurfaces in a specific deployed version and leads to an issue before the fix is released. Unrecognized filter fields and invalid filter values already return a 422 validation error today.

Possible breaking change: If a fix is still needed, the outcome depends on the approach. Rejecting unrecognized parameters with a 422 turns a previously successful request into an error. This would be a breaking change for any caller currently sending unrecognized parameters. Silently ignoring unrecognized parameters and applying only recognized filters would not be breaking.

Workaround: Not applicable, no defect currently confirmed. If you encounter unexpected empty results tied to a query parameter, check the parameter name and value against the documented filters for that endpoint. For approvals the documented filters include status and execution_id.

Mitigate the impact of version 2026.8.1788958058 breaking changes

• No reinstall or redeployment is needed. These changes are delivered through the normal automation orchestrator upgrade process. The operator applies database migrations automatically during upgrade.
• Automation orchestrator database migrations do not provide a supported downgrade path. If you might need to revert the upgrade, create and verify your own PostgreSQL backup before upgrading.
• After upgrading, review service-account credential lifetime settings, replace calls to the removed /health endpoint, and update API clients for the response-field and status-code changes described above.
• Before deleting a workflow or credential, verify that the associated history or integration references are no longer needed.

Service accounts: credential maximum lifetime moved to a runtime setting (2026.8.1788958058)

The maximum lifetime for service-account credentials is no longer the APP_SA_CREDENTIAL_MAX_LIFETIME_DAYS environment variable. It is now the service_accounts.credential_max_lifetime_days runtime setting. This value is not configured on the AutomationOrchestrator custom resource.

Mitigation: After upgrade, set it in automation orchestrator: System Administration > Settings > Authentication > Credential maximum lifetime (days). You can also set it through the Settings API. Changes apply on the next credential create or rotate and do not require a restart.

A previous environment variable value is not migrated. If you customized APP_SA_CREDENTIAL_MAX_LIFETIME_DAYS, copy that number into Settings before creating or rotating credentials. If you do not change the setting, the default is 180 days. For more information, see Service account authentication error reference.

(AAP-87804)

Workflows: unsupported template expression scopes are now rejected (2026.8.1788958058)

The ${input.*}, ${inputs.*}, and ${variables.*} expressions are no longer treated as built-in template scopes. These expressions previously passed workflow validation but never resolved at runtime, causing the workflows that used these expressions to fail during execution.

Workflow versions are revalidated when they are published, including when an existing unedited version is republished. A workflow containing one of these unsupported expressions now receives an HTTP 409 response during publish. Already-published versions continue to run.

Mitigation: To update affected workflows use ${trigger.*} to read the manual-trigger payload data. To reference output produced by another workflow step, reference that step's ID (for example, ${step_id.result}). Replace any unsupported expressions before publishing the workflow again. For more, see Control workflow execution.

(AAP-87176)

Credentials: deleting a credential used by an integration returns HTTP 409 (2026.8.1788958058)

DELETE /credentials/{id} now returns 409 Conflict with the error code CREDENTIAL_IN_USE when the credential is still configured as an integration's management credential. Previously, the request returned HTTP 204 and silently removed the credential, leaving the integration unable to authenticate.

Deleting a credential that is not referenced by an integration continues to return HTTP 204.

Mitigation: Reassign or remove the credential from every integration that references it, then retry the deletion. For more information, see Credential API endpoints.

(AAP-87778)

Workflows: deleting a workflow permanently removes versions and execution history (2026.8.1788958058)

Deleting a workflow now permanently removes the workflow, all of its versions, and all executions associated with those versions. These records are removed rather than being marked as deleted, and they cannot be restored through automation orchestrator.

Workflow, workflow-version, and execution API responses no longer include the deleted_at and deleted_by fields. API clients that read or model those fields must be updated. During upgrade, the database migration also permanently removes workflow, workflow-version, and execution records that had already been soft-deleted.

Mitigation: Before deleting a workflow, export any workflow structure that you need to preserve and capture any execution history required for reporting or auditing. A workflow export contains one version's node, trigger, and edge structure. Importing that file creates a new workflow with a new ID and version history; it does not restore the original workflow, its other versions, or its execution records.

(AAP-72954)

Workflows: created_by and updated_by fields become user objects (2026.8.1788958058)

Workflow created_by and updated_by fields are now objects ({ "id": "...", "name": "..." }) or null, replacing the previous UUID string format. This applies to workflow list, get, create, update, and publish responses.

Mitigation: Update API clients to read created_by.id and created_by.name instead of treating the field as a bare string. Regenerate any auto-generated API client types.

(AAP-76837, AAP-90563)

Resource deletion is now permanent (2026.8.1788958058)

Deleting a resource permanently removes it from the database. Previously, automation orchestrator retained deleted resources with a deleted_at timestamp (soft delete). The append-only audit log retains historical records of all delete operations.

This change affects the following resources: users, groups, projects, workflows, workflow versions, executions, tools, tool providers, and identity providers.Deleting a project now cascades to all child resources, including workflows, workflow versions, executions, invocations, credentials, service accounts, approval requests, role assignments, roles, policies, secrets, and file metadata. The project deletion confirmation dialog requires you to type the project name to confirm.

Mitigation: Before upgrading, verify that any resources you might need are exported or backed up. After upgrading, deleted resources cannot be recovered from the database. Use the audit log to review historical records of deleted resources.