[RFE] Enhanced Workflow Artifacts: GUI Visibility, Secret Masking, and Artifact-Conditional Connectors

[fernandorocagonzalez]

Please confirm the following

• I have checked the current issues for duplicates.
• I understand that Ascender is open source software provided for free and that I might not receive a timely response.

Feature type

New Feature

Feature Summary

Summary

Workflow connectors in Ascender only support three types: on success, on failure, and always. There is no way to route workflow execution based on what actually happened inside a job beyond pass/fail.

This feature request proposes a fourth connector type that evaluates a condition against the parent node's artifacts (set_stats data) to decide whether to activate the downstream node.

Problem

Artifacts produced via ansible.builtin.set_stats are already persisted in the database and passed downstream as extra_vars. The data is there, but the workflow engine ignores it when deciding which nodes to activate next.

This forces users into workarounds like:

• A "router" job template that deliberately fails based on a condition, just to abuse the failure path toward the desired next node
• Cramming all branching logic inside a single monolithic playbook instead of using the workflow engine, because the workflow can't express "run node B only if artifact X equals Y"
• Wrapping the real logic in a workflow that calls sub-workflows, adding unnecessary complexity

These workarounds are brittle, hard to maintain, and defeat the purpose of having a visual workflow orchestrator.

Proposal

Introduce a fourth connector type, something like on condition, where you define an expression that gets evaluated against the parent node's artifacts after the job completes.

How it would work

A condition on an edge would have three fields:

• artifact_key: the artifact key to evaluate (e.g. environment)
• operator: comparison operator (==, !=, in, etc.)
• expected_value: the value to compare against (e.g. production)

A node connected via a conditional edge would only activate if the parent job completed successfully AND the condition evaluates to true. A failed job should not trigger condition paths (same as on success in that regard).

Example

[Check Environment]
    |-- on_condition (environment == "production")  --> [Deploy to Prod]
    |-- on_condition (environment == "staging")     --> [Deploy to Staging]
    '-- on_failure                                  --> [Notify Failure]

The playbook in "Check Environment" would simply do:

- name: Set deployment target
  ansible.builtin.set_stats:
    data:
      environment: "{{ target_env }}"

Phased approach

Phase 1 (MVP): Simple key-value equality only (artifact_key == expected_value). This covers the majority of real use cases and keeps the scope manageable.

Phase 2: Extended operators (!=, in, >=, etc.), multiple conditions per edge with AND/OR logic, and potentially Jinja2 expression evaluation for more complex scenarios.

Areas of the codebase affected (preliminary)

• Models: new fields on the workflow node edge relationship, or a new model for conditional edges
• Workflow engine (task manager): evaluation logic when determining which downstream nodes to activate after a job completes
• API: serializers and viewsets for CRUD on condition configuration
• UI: workflow visualizer updates with a new connector style and a configuration modal for setting the condition
• Migrations: backward-compatible schema migration, existing workflows would not be affected

Prior art

This specific feature has never been formally requested in upstream AWX. The upstream project treats artifacts purely as a data-passing mechanism and has never explored using them for routing decisions. This would be a differentiating capability for Ascender.

Some related upstream issues that show broader community interest in improving the artifact system:

• ansible/awx#447: Show artifacts set by jobs (implemented)
• ansible/awx#3249: Hide artifact values in workflow jobs (still open)
• ansible/awx#16036: Enable direct artifact download from job view (still open)

Willingness to contribute

I am happy to develop this and submit a PR. I would prefer to get feedback on the design before investing time in code. Specifically:

1. Is this something that fits with Ascender's roadmap?
2. Are there ongoing refactors or architectural constraints I should know about?
3. Any preferences on how to structure the PR?

I have previous contribution experience with the Ascender codebase (merged PR fixing UnifiedJob.save() / finished timestamp handling).

Open to discussing the design further.

Select the relevant components

• UI
• API
• Docs
• Collection
• CLI
• Other

Steps to reproduce

Just create any workflow

Current results

No direct capacity to orchestrate connectors between jt

Sugested feature result

Introduce a fourth connector type, something like on condition, where you define an expression that gets evaluated against the parent node's artifacts after the job completes.

Additional information

No response

[cigamit]

I think this could be a worthwhile contribution. I don't know if it should go in before the upgrade to Patternfly, as components, etc.. may change and have to be reworked.

I would also like to see a connector for "Changed" where it only traverses the path if something reported as changed in the playbook before it (or maybe only the hosts that reported as change traverse?). Would save me a bit of time.

[fernandorocagonzalez]

Ok , once @blaipr finish the pattern fly move to pf 6 wil begin with that

[fernandorocagonzalez]

I left out the thing of propagating the changed hosts on purpose because I have an idea about that .

But since its very different we may want to discuss in a new thread and just close that one

[fernandorocagonzalez]

@cigamit following up on the "Changed" connector idea, this is now covered by the combination of two PRs:

• Add conditional workflow connectors based on job artifacts (#505) #561 adds the fourth connector type, On Condition: the edge stores a trigger (success, failure or always), an artifact key, an operator (eq/ne) and an expected value, and it only traverses when the parent finished with that outcome and the condition matches its artifacts.
• Add automatic ascender_stats_* job artifacts (changed/failed flags and host lists) #562 makes every playbook job automatically publish ascender_stats_* artifacts derived from the playbook stats, no set_stats needed: ascender_stats_changed and ascender_stats_failed booleans plus sorted host name lists (ascender_stats_changed_hosts, ascender_stats_non_changed_hosts, ascender_stats_failed_hosts, ascender_stats_non_failed_hosts).

So your example ends up being an On Condition edge with ascender_stats_changed == true, without needing a dedicated fifth connector type. And for the second part of your idea (only the hosts that changed traverse), the host lists propagate downstream as extra vars like any other artifact, so the next node can run with something like limit: "{{ ascender_stats_changed_hosts | join(',') }}". Failed and unreachable variants come free with the same primitive, and the stats keys of sibling jobs (slices, nested workflows, converging parents) are merged so nothing gets masked.

I went with generic conditions instead of a hardcoded Changed connector on purpose: it covers your case and also anything a playbook reports via set_stats, without touching the visualizer again for each new outcome we might want later.