Overview

The Test Run Pack Wizard creates a Test Run Pack — a named, reusable group of tests you can run on demand or on a schedule. It has five steps, and you can't advance past a step until its required fields are valid.

Before you begin

The project needs tests already. See Test case or AI-generated tests.
The project needs a base URL for the environment you intend to run in, or execution will have nowhere to send requests. See Project settings.
Open Execution from the top navigation, then select New Test Run Pack.

Step 1 — Pack Details

Field	Notes
Pack Name (required)	Must be unique. The placeholder reads "Enter a unique name".
Description	A short summary of what the pack covers.
Pack Type (required)	Functional or Workflow.
Pack Status	Whether the pack is active.

Pack Type decides what step 2 offers you:

Type	Contains
Functional	Endpoint test cases run against your API. The default, and what most packs are.
Workflow	Multi-step workflows executed end to end. See Understanding workflows.

You can't mix the two in one pack — the type chosen here determines which selector step 2 shows.

Validation: "Pack name is required" if left blank, "Pack name already exists" if the name is taken.

Step 2 — Select Tests

Choose the Project.
Select the tests (or workflows, for a Workflow pack) to include. Use Search… to filter long lists.

Validation: "Please select a project", then "At least one test case must be selected" — or "At least one workflow must be selected" on a Workflow pack.

Step 3 — Execution Preferences

This step decides where and how the pack runs.

Field	What it does
Environment	Which environment to run against. The list comes from the environments configured on the project.
Base URLs by Environment	Shows the base URL that will be used, resolved from Project settings.
Execution Mode	Whether the pack runs on the Shift-Left Engine (server-side) or the Shift-Left Agent (locally). See Execution mode.
Authentication Profile	Which project authentication profile the requests use.
Override	Enables the per-pack overrides below, instead of inheriting project defaults.
Headers (JSON)	Per-pack header overrides.
Query Params (JSON)	Per-pack query-parameter overrides.
Auth (JSON)	Per-pack authentication override.

The overrides exist so one pack can differ from the project default without you editing the project — a pack that needs a specific API version header, say. Leave Override off unless you need that; inheriting from the project is what keeps packs consistent.

Validation: "Please select an environment". Concurrency, where configurable, must be between 1 and 999 — "Concurrency must be between 1 and 999".

Step 4 — Notification Settings

Configure who hears about a run and when. You can preview the notification before saving, so you're not discovering the format from a real failure at 3am.

Notification content is driven by templates — see Email templates and Scheduled reports and alerts.

Validation: "Invalid URL format" if a webhook or callback URL is malformed.

Step 5 — Schedule & Finalize

Leave this step alone for a pack you only intend to run manually — scheduling is optional.

Field	Notes
Repeat	The recurrence pattern, including Once.
Start Date	When the schedule begins.
Time of Day	When the run fires.
Days of Week	Which days, Monday through Sunday.
Run every X minutes / Run every X hours	Interval-based recurrence.
Cron Expression	For patterns the simple fields can't express. The placeholder shows the shape: `0 30 14 * * MON-FRI`.
End Condition	When the schedule stops — including after a Repeat count.

Finish with Save, or Save & Run to save and start a run immediately. Save & Run is the better choice on a new pack, because it verifies connectivity and auth right away rather than at the first scheduled run.

Validation: "Start date is required" when scheduling, and "Invalid schedule data" if the combination doesn't resolve to real run times.

A scheduled pack only fires while it's Enabled — the toggle on the Test Execution table. A saved schedule on a disabled pack shows Never as its upcoming run.

After you create the pack

Run it once manually to confirm auth and connectivity before trusting a schedule.
Check the Test Count on the packs table matches what you selected.
Open the report and confirm you're getting the evidence you need — High level test report.

Troubleshooting

"Pack name already exists" — names are unique. Include the scope or environment to disambiguate, for example Orders smoke - QA.
The test list in step 2 is empty — the selected project has no tests of the pack's type yet, or you chose Workflow when you meant Functional.
Everything errors on the first run — usually the environment's base URL or the authentication profile. Check step 3 against Project settings.
The pack saved but never runs — confirm Enabled is on for the pack. See Test execution.
"Invalid schedule data" — the fields don't resolve to a real run time. A cron expression and the simple schedule fields disagreeing is the usual cause.

Test Run Pack Wizard: Create a Pack