manage execution policies in leapwork go.md

Manage Execution Policies in Leapwork Go

This article explains how customer admins can manage execution policies in Leapwork Go, where these policies are applied, and how they affect timeline execution when failures accumulate.

It is intended for customer admins and workspace owners who want consistent execution-control rules across projects.

What execution policies are

Execution policies let admins centrally control how Leapwork Go responds when sequence failures build up during a track item run.

Each execution policy defines two things:

Setting	What it controls
Failed-sequence limit	How many failed sequence runs a track item can tolerate before the policy threshold is exceeded
Stop behavior	Whether the track item stops when that limit is exceeded or continues to the end

Execution policies are separate from performance policies. Go policies define response-time bands. Execution policies define how failed sequence counts affect track item execution.

Why this matters

It helps stop runs that are clearly failing instead of letting them continue unnecessarily.
It reduces wasted execution time and shared test capacity.
It makes failure handling more consistent across teams and projects.
It gives admins a controlled way to define different failure tolerance for different projects.

Before you start

You need an admin-capable role to create, edit, or delete execution policies.
You should decide whether you need one company-wide default, project-specific policies, or both.
You should agree internally on how many failed sequence runs are acceptable before a track item should stop.
Execution policy thresholds use whole numbers in the range 0 to 999.

How to manage execution policies

Open Settings in Leapwork Go.
Go to Policy Configuration > Execution.
Select Add policy.
Enter a policy name.
Choose the scope you want to use.
Enter the allowed number of failed sequence runs.
Decide whether the track item should stop when the limit is exceeded.
Save the policy.
Review and update policies whenever your failure tolerance or test strategy changes.

In practice, Organisation works as the shared company-level fallback and Project overrides it for a specific project.

How policies are applied

Leapwork Go applies execution policies in this order:

Order	Behavior
`1`	If a user explicitly selects a policy in `Edit Timeline`, that selected policy is used for the track item.
`2`	If no explicit selection is made and a project policy exists, the project policy is used by default.
`3`	If no project policy exists, the `Organisation` policy is used.
`4`	If neither exists, no execution policy is applied.

When no applicable policy exists, the execution policy area is not shown for that track item.

What users will experience when a policy is applied

In Edit Timeline Track item, a policy selector appears when a project or Organisation policy is available.
When both project and Organisation policies exist, the project policy is used by default.
Users can select a different available policy for a track item when needed.
If admins rename a project or Organisation policy later, the updated name is reflected the next time users edit affected timelines.
If stop behavior is turned off, the track item continues even when the failed-sequence count exceeds the configured limit.

Important behavior to know

If no project or Organisation execution policy exists, no execution policy is applied and no policy selector is shown.
Selected execution policies are not preserved through timeline copy/paste or import/export. Imported or pasted track items use the applicable project or Organisation default instead.
In highly parallel runs, the final failed-sequence count can end slightly above the configured limit because some sequence executions may already be in progress when the stop condition is reached.

Impact on your testing workflow

Execution policies help teams fail faster when a track item is already outside acceptable quality limits.
They reduce the need for manual monitoring of obviously failing executions.
They make track-item behavior more predictable across projects.
They help teams balance early stop behavior against the need to let a run continue for investigation.
They do not define response-time bands or performance classifications. They control what happens when sequence failures accumulate during execution.

Recommended admin practices

Start with an Organisation policy if you want one consistent default across the company.
Add project policies only where a project genuinely needs a different failure tolerance.
Use lower thresholds for scenarios where early stop is important to protect time or capacity.
Leave stop behavior enabled for runs where continuing after repeated failures adds little value.
Review policies after major releases, environment changes, or shifts in expected stability.