Decide what should actually stop your Flow

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

That is usually the right behaviour for critical functional paths.

But not every issue deserves to halt execution.

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

• Fail

• Warning

• Pass

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

Warnings and Pass statuses allow the Flow to continue cleanly.

This gives you precise control over what truly matters.

Built for non-functional testing

Some checks are important, but not release-blocking.

Examples include:

• Accessibility audits

• Performance checks

• Visual regression comparisons

• Broken or invalid links

• SEO validations

• Third-party script behaviour

You want visibility.

You do not always want execution to stop.

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

Handle real-world UI complexity

Applications are not always predictable.

Cookie banners, marketing popups, optional UI components, and phased rollouts can change what appears on screen.

With Control Failure Status, you can:

• 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

This keeps your automation resilient without masking real failures.

Protect runner concurrency and environments

When everything is treated as critical, teams often:

• Trigger unnecessary reruns

• Consume runner concurrency unnecessarily

• Generate excess test data

• Add avoidable load to environments

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

Concurrency stays available for work that delivers real value elsewhere.

Smarter automation, better signal

Quality assurance is not binary.

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

• Critical functionality fails fast

• Secondary concerns remain visible

• Known limitations do not derail execution

Because strong automation is not about failing more often.

It is about failing for the right reasons.