Configuration: Testing: Wait Events

Updated

Configuration: Testing: Wait Events

Overview

Use this page to create, edit, and delete reusable wait events. A wait event is a named timing marker, such as Desktop ready or Logon completed, standing in for a hard-coded delay. Instead of repeating the same wait condition in every scenario phase that needs it, you define the marker once here and reference it by name wherever it applies.

Wait events sit between your systems-under-test configuration and your test scenarios: once you've seen a condition behave consistently during earlier test runs, you name it here, and scenario phases in Configuration: Testing: Scenarios pick it from a list instead of redefining the same timing logic each time. Renaming or deleting a wait event here can affect any scenario phase that references it, so treat changes here as changes to shared scenario configuration.

On this page, you can review the current list of wait events with their generated identifiers, refresh the list to pick up changes made elsewhere, open the editor to create a new entry or rename an existing one, and remove entries no longer needed.

Key concepts

  • wait event - A reusable, named timing marker that a scenario phase can reference instead of a hard-coded delay, so virtual users pause until the condition the name represents is expected to have occurred. (related: Configuration: Testing: Scenarios)
  • identifier - The unique, system-generated value assigned to a wait event when it is created. It distinguishes the wait event internally even if the Name is later edited.
  • scenario phase - A stage within a test scenario that can reference a wait event to coordinate its timing with other actions in the test. (related: Configuration: Testing: Scenarios)

When to use it

  • You're building a scenario and need a named marker for a recurring timing condition (for example, a login screen or application load state) instead of hard-coding a delay.
  • You want to reuse the same timing marker across multiple scenarios without redefining it in each one.
  • An existing wait event's name no longer matches what it represents and needs to be renamed.
  • A wait event is no longer referenced by any scenario phase and should be removed to keep the list manageable.
  • You need to check which wait events already exist before adding a new one, to avoid creating a duplicate.

Before you begin

  • Know the specific timing condition you want to mark (for example, a UI state like Desktop ready) so the Name you give it is meaningful to anyone configuring a scenario phase later.
  • Confirm your account holds a role with write access to wait events if you intend to create, edit, or delete one; read access to view the list is available to any signed-in user.

Common workflows

Create a new wait event

Persona: Load-test scenario designer

  1. Select New Wait Event in the page header.
    • Expect: An editor opens with an empty, required Name field.
  2. Enter a descriptive name for the condition you want to mark, then confirm the editor.
    • Expect: The editor closes and a new row appears in the table with that Name and a generated Identifier.

Verify: The new wait event's Name appears in the Wait Events table and becomes available to select from a scenario phase in Configuration: Testing: Scenarios.

Delete a wait event that's no longer needed

Persona: Test configuration admin

  1. Confirm in Configuration: Testing: Scenarios that no scenario phase still references the wait event you intend to remove.
    • Expect: You've verified the wait event is unused before deleting it.
  2. Select the Delete (trash) icon on that wait event's row.
    • Expect: A confirmation dialog opens asking you to confirm removal.
  3. Select Delete in the confirmation dialog.
    • Expect: The dialog closes and the row no longer appears in the table.

Verify: The deleted wait event's row is gone from the Wait Events table, and no scenario phase still references its Name.

Steps

Step 1

Open Wait Events under Configuration.

Expected result: The table lists the existing wait events, for example Citrix session established, Desktop ready, Logon completed, Outlook inbox loaded, and Word document opened, each with its Name and generated Identifier.

You start here to see which timing markers already exist before creating, renaming, or removing one.

  • A Credentials expiring notice may appear over the header; it concerns an API token, not wait events, and can be dismissed independently.
  • Each row's Actions cell holds its own Edit (pencil) and Delete (trash) icons. Configuration: Testing: Wait Events - step 1

Step 2

Select Refresh in the page header.

Expected result: The table reloads the current wait event list; with the earlier credentials notice cleared, Refresh and New Wait Event are visible at the top of the page and the column headings read NAME, IDENTIFIER, ACTIONS.

Refreshing confirms you're working from the latest list before you create, edit, or delete a wait event.

  • New Wait Event opens an empty editor to define another marker.
  • NAME, IDENTIFIER, and ACTIONS label the same columns shown in the previous step. Configuration: Testing: Wait Events - step 2

Field reference

Field Purpose Format / Validation Required Default
Name Identifies the wait event wherever it's selected, including from a scenario phase's wait event picker. Choose a specific, descriptive name (what condition it marks) rather than a generic one, since scenario authors rely on this text alone to pick the right marker. Free text Yes -

Column reference

Column What it shows How to read it
Name Displays the wait event's current name in the list. Scan this column to find the wait event you want to open with Edit or remove with Delete; the accent styling does not indicate a separate navigation link.
Identifier Shows the generated unique ID for each wait event. Use this value to confirm exactly which wait event is in play if two rows have similar names.
Actions Hosts the per-row Edit and Delete controls. Each row carries its own Edit and Delete icons; there's no control here that acts on more than one row at a time.

Controls reference

Refresh

Reloads the Wait Events table from the server.

When to use: Use after another user or process may have added, renamed, or removed a wait event, or if the list looks out of date.

Side effects: Read-only; does not modify any wait event data.

New Wait Event

Opens an empty editor with a required Name field so you can define a new wait event.

When to use: Use when a scenario phase needs to reference a timing marker that doesn't exist yet.

Side effects: Mutating once you confirm the editor: adds a new row with a generated Identifier. Closing the editor with Cancel makes no change.

Edit (pencil icon, row)

Opens the editor pre-filled with the selected wait event's current Name.

When to use: Use when the condition a wait event marks has changed and its name should be updated to match.

Side effects: Mutating once you confirm the change; canceling the editor leaves the wait event unchanged.

Delete (trash icon, row)

Opens a confirmation dialog asking you to confirm removal of that wait event.

When to use: Use when a wait event is no longer referenced by any scenario phase and should be removed from the list.

Side effects: Opens the confirmation dialog only; the wait event is not removed until you confirm Delete inside it.

Cancel (New/Edit Wait Event editor)

Closes the editor without saving any change to the Name field.

When to use: Use if you opened New Wait Event or Edit by mistake, or decide not to proceed with the change.

Side effects: Read-only; no change is persisted.

Delete (confirm)

Permanently removes the selected wait event from the list.

When to use: Use only after confirming the wait event is not referenced by any active scenario phase, since removing one that's still referenced can affect that scenario's timing.

Side effects: Mutating: the row and its Identifier are deleted; this cannot be undone from this page.

Cancel (Delete Wait Event confirmation)

Closes the delete confirmation dialog without deleting the wait event.

When to use: Use if you selected Delete by mistake or want to check scenario references first.

Side effects: Read-only; the wait event remains in the list unchanged.

Verify the result

After creating a wait event, it appears as a new row in the table with the Name you entered and a newly generated Identifier. After renaming one, the updated Name shows immediately in its row. After deleting one, the row no longer appears in the list. If a change doesn't show up, select Refresh to confirm whether it saved, then check for an error message above the table and confirm your account holds write access to wait events.

Troubleshooting

  • Symptom: New Wait Event, Edit, or Delete controls aren't visible, even though the list displays. Fix: Your account doesn't currently hold the role that grants write access to wait events; request it, since read access is available to any signed-in user but write actions require that extra permission.
  • Symptom: A wait event you deleted was still referenced somewhere, and a scenario starts behaving differently. Fix: Before deleting a wait event, confirm in Configuration: Testing: Scenarios that no phase still points to it.
  • Symptom: The Credentials expiring notice covers the Refresh and New Wait Event buttons. Fix: Close the notice, or reissue the token it names under Configuration then Credential Profiles; the notice is unrelated to wait events but can overlap the header until dismissed.
  • Symptom: A wait event you just created or renamed doesn't show up where you expect it, for example in a scenario phase's picker. Fix: Select Refresh on this page, then reload the scenario editor so it fetches the current wait event list.
  • Symptom: The editor won't let you save a new or edited wait event. Fix: Enter a value in the required Name field, marked with an asterisk; the editor won't accept an empty name.
Was this article helpful?
0 out of 0 found this helpful