File storage endpoint incorrectly required when creating an instance: When you create an automation orchestrator instance using the form view in the OpenShift console, omitting the file storage configuration produces the error Required value for field spec.fileStorage.endpointURL. The documentation and the form help text both state that S3-compatible object storage is optional. Mitigation: Provide a file storage endpoint URL in the form, or create the instance using YAML view and omit the fileStorage section entirely.

PostgreSQL CA certificate secret required even when SSL is disabled: Setting the PostgreSQL SSL mode to disable in the AutomationOrchestrator custom resource does not prevent the operator from requiring the pg-ca-cert secret. The operator reports PostgreSQL CA cert secret not found: pg-ca-cert even though a CA certificate is only needed for verify-ca or verify-full modes. Mitigation: Create an empty or placeholder pg-ca-cert secret in the namespace, even when SSL is disabled.

Ansible Automation Platform identity provider creation is not idempotent: Configuring the Ansible Automation Platform identity provider a second time, for example during troubleshooting or redeployment, fails with the error OAuth Application Syntara already exists. Re-applying the same identity provider configuration does not update the existing resource or succeed silently. Mitigation: Manually delete the existing OAuth application before re-applying the identity provider configuration.

Ansible Automation Platform integration shows "unknown" status after successful configuration: After you configure an Ansible Automation Platform integration and pass the connection health check, the integration status displays as "unknown" in the integrations list. The status remains "unknown" even after workflows run successful jobs using that integration. Mitigation: None. The integration functions correctly despite the incorrect status display.

"Use input variables" toggle invalidates the selected Ansible Automation Platform job template: Toggling the "Use input variables" setting on an Ansible Automation Platform Job Template node can clear or corrupt the selected job template. Saving or updating the node can fail with the error Job Template ID must be a valid positive integer, even though the job template was correctly selected before the toggle change. Mitigation: After toggling "Use input variables," reselect the job template before saving the node.

Workflow verification fails after enabling "Use input variables": Enabling "Use input variables" on an Ansible Automation Platform Job Template node causes the workflow Verify action to fail with the error Additional properties are not allowed ('use_input_variables' was unexpected). One error appears per affected node. Mitigation: Save the workflow, reload the browser page, then click Verify. The reloaded definition no longer contains the internal field that causes the rejection. The input variables toggle continues to display correctly after reload.

Imported workflows render with jumbled layout: When you import a workflow that does not include an Ansible Automation Platform integration ID, the workflow builder renders the graph with overlapping and duplicated node placement. Mitigation: Assign the Ansible Automation Platform integration to the Ansible Automation Platform execution nodes in the imported workflow, then refresh the page. The layout corrects itself after the integration is assigned.

Ansible Automation Platform integrations listed without selecting a project: When you create a workflow without selecting a project, the Ansible Automation Platform Job Template node shows a list of Ansible Automation Platform integrations that are not available globally. You should not see project-scoped integrations until you assign the workflow to a project. Mitigation: Select a project for the workflow before configuring Ansible Automation Platform Job Template nodes.

Deleting a workflow does not cancel pending approvals: When you delete a workflow that has a pending approval, the approval request remains active. If approved after the workflow is deleted, the run continues. This contradicts the deletion confirmation message, which states that in-progress runs will stop immediately. Mitigation: Reject or deny any pending approval requests before deleting the workflow.

Webhook and EDA triggers require a service account token: Webhook and EDA trigger endpoints require a valid service account bearer token, even when you do not configure a service account on the trigger. Sending a request without authentication fails with A valid service account Bearer token is required to invoke this webhook. Mitigation: Create a service account, generate a credential, and include the bearer token in webhook requests. See Add a webhook trigger for the complete setup procedure.

Misleading help text in EDA trigger endpoint configuration: The help text for the EDA trigger endpoint URL states "Configure your EDA rulebook to send a POST request to this URL." You cannot send a POST request directly from a rulebook to the endpoint. You must configure an Ansible Automation Platform job template as the action in your rulebook, and that job template sends the POST request to the automation orchestrator endpoint. Mitigation: Follow the procedure in Add an Event-Driven Ansible trigger, which describes the correct integration pattern using a job template action.

Trigger node mock data not used by downstream nodes: When you pin mock data on a trigger node's Output panel and run a downstream step using "Use mock data," the trigger's mock output data is not sent to downstream nodes. The system prompts for manual inputs instead of using the pinned mock data. Mitigation: Instead of pinning mock data on the trigger node, set mock data directly on the downstream node's Input panel using the "Set mock data" option in the Run Step dialog.

Pre-resolved node shows empty run details after Run Step with mock data: After you run a step with mock data for a predecessor node, clicking the predecessor (pre-resolved) node in the execution view shows an empty run details table. The mock output data supplied for the skipped node is not visible anywhere in the UI. Mitigation: None. The downstream step receives the mock data correctly, but you cannot inspect the mock data values in the execution view for skipped predecessor nodes.

Trigger node mock data editor is not schema-aware: The mock data dialog for a trigger node's Output panel presents a generic JSON editor with no reference to the trigger's input schema. Mock data that does not conform to the trigger's input schema is accepted without validation and can cause downstream failures. Mitigation: Reference the trigger's input schema definition before entering mock data. Ensure that the JSON structure matches the expected trigger payload format.

Execution details show runtime values instead of pinned mock data: After a workflow run that used pinned mock data, the execution details panel shows runtime values instead of the mock data that was active during the run. There is no visual indicator to distinguish between live execution data and mock-data-driven execution data. Mitigation: None. Use the mock data dialog on each node to verify which mock data is currently pinned.

Node Output panel shows last-run data instead of pinned mock data: When you pin mock data on a node and reopen the node editor after a run, the Output panel displays data from the last execution rather than the pinned mock data. The mock data dialog correctly shows the pinned values, but the Output panel does not. Mitigation: Use the "Edit mock data" or "Use mock data" option on the node to view the pinned mock data values, rather than relying on the Output panel.

Existing nodes do not reflect upstream pinned mock data in Input panel: For nodes that have been run at least once, the Input panel displays the last actual execution output from the upstream node instead of the upstream node's pinned mock data. Newly added nodes correctly display upstream mock data. This affects only nodes with prior execution history. Mitigation: Add a new node in place of the existing one to see the upstream node's pinned mock data reflected in the Input panel.

Run Step mock data dialog does not pre-populate with pinned data: When you run a step for a node that has pinned mock data on its predecessor, the "Set mock data" dialog opens with a blank JSON editor instead of pre-populating the existing pinned mock data. Existing pinned data can be accidentally overwritten. Mitigation: Before using Run Step, note the currently pinned mock data values from the predecessor node's Output panel or mock data dialog, then re-enter them in the Run Step mock data editor.

Settings AI/LLM tab displays upstream project name: The default Task agent system prompt in Settings > AI/LLM references "Syntara" instead of "Automation Orchestrator." Mitigation: Edit the Task agent system prompt to replace "Syntara" with "Automation Orchestrator."

Misleading error message when assigning roles to service accounts: When you assign a role to a new service account, a validation message prompts you to select at least one role even after you have selected a role. The message does not prevent the role assignment from completing successfully. Mitigation: None needed. Ignore the validation message and proceed with the role assignment.

Approval details lack structured data views: The approval details pane displays the entire approval object as a raw JSON block. There is no option to switch between Schema, Table, and JSON views for structured data such as workflow context inputs and previous step output. Mitigation: Copy the JSON data from the approval details pane and use an external JSON viewer to inspect the structured data.