Control failure status

By default, DoesQA Flows can be configured to stop on first failure.

That is usually the right behaviour for critical functional paths.

Decide what should actually stop your Flow

With Control Failure Status, you can decide whether a step returns:

If a Flow is set to stop on first fail, only steps marked as Fail will trigger that stop.

• Warning

• Accessibility audits

• Performance checks

• Visual regression comparisons

• Broken or invalid links

• SEO validations

• Third-party script behaviour

• Attempt to dismiss a popup if it exists, continuing cleanly if it does not

• Validate optional UI without breaking the main journey

• Keep Flows stable across environments

• Trigger unnecessary reruns

• Consume runner concurrency unnecessarily

Built for non-functional testing

Warnings and Pass statuses allow the Flow to continue cleanly.

This gives you precise control over what truly matters.

Handle real-world UI complexity

Some checks are important, but not release-blocking.

Control Failure Status lets you surface these signals without turning them into blockers.

Protect runner concurrency and environments

Attempt to dismiss a popup if it exists, continuing cleanly if it does not

Validate optional UI without breaking the main journey

Smarter automation, better signal

This keeps your automation resilient without masking real failures.

When everything is treated as critical, teams often:

By classifying steps correctly, you ensure only genuine blockers stop execution.

Concurrency stays available for work that delivers real value elsewhere.

Control Failure Status allows your tests to reflect real-world priorities:

Because strong automation is not about failing more often.