Configuration: Testing: Wait Events

Configuration: Testing: Wait Events

Overview

Use this page to create, edit, and delete wait events used as timing markers in scenario phases. A wait event is a reusable checkpoint, such as Logon completed or Desktop ready, that a scenario phase references so the platform can record when that specific point in a test flow was reached. Without a defined catalogue of wait events, scenario authors would have no consistent way to mark the same meaningful moment across different scenarios and runs.

Wait events exist independently of any single scenario. You define them once on this page, then select the one you need from the Configuration: Testing: Scenarios page when you build or edit a scenario phase; the platform records timing data against that marker whenever the scenario runs.

This page manages only the catalogue of wait events, not their use inside a particular scenario. It lists every existing wait event by name and identifier, and lets you refresh the list, add a new wait event, rename an existing one, or delete one that is no longer needed.

Key concepts

  • wait event - A reusable timing marker, identified by a name, that a scenario phase references so the platform can record when that point in the test flow was reached. (related: Configuration: Testing: Scenarios)
  • identifier - A system-generated, unique value assigned to a wait event when it is created; it stays the same even if the wait event's name is changed later.
  • scenario phase - A stage within a test scenario where a wait event can be referenced to time how long that stage took during a run. (related: Configuration: Testing: Scenarios)

When to use it

  • You're building or editing a scenario phase and need a reusable marker to record when a specific point in the flow, such as a login or page load, is reached.
  • You want to reuse the same timing marker across several scenarios instead of recreating it for each one.
  • You need to rename a wait event label that's used inconsistently across scenarios.
  • You want to confirm a wait event's current identifier before referencing it elsewhere.
  • A wait event is no longer referenced by any scenario and you want to remove it from the catalogue.

Before you begin

  • Your account holds the role that grants write access to Wait Events; without it you can still view the list, but the New Wait Event, Edit, and Delete controls do not appear.
  • You know which scenario phase on the Configuration: Testing: Scenarios page needs a timing marker, so you can give the new wait event a name that matches its purpose there.
  • If you're renaming or deleting an existing wait event, confirm whether any scenario phase on the Configuration: Testing: Scenarios page still relies on it under its current name.

Common workflows

Add a new wait event for use in a scenario phase

Persona: Scenario author preparing timing markers before building a test flow

  1. Select New Wait Event in the page header.
    • Expect: The editor opens with an empty Name field.
  2. Type a descriptive label, such as Outlook inbox loaded, into the Name field.
    • Expect: The text appears as you type; the field is required and can't be confirmed while blank.
  3. Confirm the entry to save the new wait event.
    • Expect: The editor closes and the new wait event appears as a row in the table with a generated identifier in the IDENTIFIER column.

Verify: The new name appears in the NAME column with a unique value in the IDENTIFIER column, ready to be selected from a scenario phase on the Configuration: Testing: Scenarios page.

Remove an obsolete wait event

Persona: Administrator cleaning up unused timing markers

  1. Select the Delete icon on the row for the wait event you no longer need.
    • Expect: A confirmation modal opens asking you to confirm removal.
  2. Confirm the deletion in the modal.
    • Expect: The modal closes and the row no longer appears in the Wait Events table.

Verify: The deleted wait event's name and identifier no longer appear in the list. If a scenario phase still referenced it, check that phase on the Configuration: Testing: Scenarios page.

Steps

Step 1

Open Wait Events from the left navigation menu.

Expected result: The list loads showing five existing wait events, each with a label in the NAME column, a generated value in the IDENTIFIER column, and Edit and Delete icons in the ACTIONS column.

This gives you the current catalogue of timing markers before you add, rename, or remove one.

  • NAME shows the wait event's current label.
  • IDENTIFIER shows the GUID assigned when the wait event was created.
  • Each row's ACTIONS column holds the Edit (pencil) and Delete (trash) icons. Configuration: Testing: Wait Events - step 1

Step 2

Select Refresh in the page header.

Expected result: The list reloads from the server, and the full header toolbar, including New Wait Event, is now visible above the table.

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

  • Refresh re-fetches the list without changing any wait event.
  • New Wait Event opens the editor to add a new entry. Configuration: Testing: Wait Events - step 2

Field reference

Field Purpose Format / Validation Required Default
Name Identifies the wait event in the list and wherever it can be selected inside a scenario phase. Use a clear, specific label describing the checkpoint it marks so scenario authors can pick the right one without opening it. Free text, single line Yes -

Column reference

Column What it shows How to read it
NAME Shows the label entered for the wait event when it was created or last edited. Read this value to identify which checkpoint the wait event marks; it's the name scenario authors see when selecting it.
IDENTIFIER Shows the identifier the platform generated for the wait event when it was created. Use this value to reference the exact wait event in exports or support tickets; it does not change even if the name is edited.
ACTIONS Holds the per-row controls for that wait event. No data is shown here, only the Edit (pencil) and Delete (trash) icons for the row.

Controls reference

Refresh

Reloads the wait events list from the server.

When to use: After a change may have happened elsewhere, or when you want to confirm you're viewing the current list.

Side effects: Read-only: re-fetches the list without changing any wait event.

New Wait Event

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

When to use: When you need a timing marker that doesn't already exist in the list.

Side effects: Opening the editor doesn't change any data; the wait event is only created once you confirm the entry.

Edit (row icon)

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

When to use: When you need to rename an existing wait event.

Side effects: Non-mutating until you confirm the change; confirming updates the NAME column for that row.

Delete (row icon)

Opens a confirmation modal for the selected wait event.

When to use: When a wait event is no longer needed.

Side effects: Non-mutating by itself; confirming in the modal permanently removes the row from the list.

Cancel (editor)

Closes the editor without saving.

When to use: When you opened New Wait Event or Edit by mistake, or decide not to keep your changes.

Side effects: Read-only: discards any unsaved text in the Name field.

Cancel (delete confirmation)

Closes the delete confirmation without removing the wait event.

When to use: When you opened Delete by mistake.

Side effects: Read-only: the wait event stays in the list.

Delete (confirm)

Permanently removes the selected wait event.

When to use: After you've confirmed in the modal that the correct wait event is being removed.

Side effects: Mutating: the row is permanently deleted from the list.

Create First Wait Event

Opens the editor to create the first wait event.

When to use: When no wait events exist yet and the table shows an empty state.

Side effects: Opening the editor doesn't change any data; the wait event is created once you confirm the entry.

Verify the result

After you create, rename, or delete a wait event, the Wait Events table reflects the change: a new or renamed entry shows its label in the NAME column with a value in the IDENTIFIER column, and a deleted entry no longer appears in the list. If the table doesn't show the change you expect, select Refresh to reload the list from the server. If New Wait Event, Edit, or Delete are missing entirely, the account in use likely lacks write access to Wait Events rather than the change having failed.

Troubleshooting

  • Symptom: The New Wait Event, Edit, and Delete controls are missing from the page. Fix: The signed-in account doesn't hold the role that grants write access to Wait Events; read access still works, so ask an administrator to grant the role on the Operations: Permissions page.
  • Symptom: A wait event you just renamed or deleted still shows the old name or still appears in the list. Fix: Select Refresh to reload the list from the server; the table doesn't update automatically for changes made elsewhere.
  • Symptom: The editor won't let you confirm a new or edited wait event. Fix: Enter a value in the Name field; it's required and can't be saved blank.
  • Symptom: The table shows an empty state instead of a list. Fix: No wait events exist yet; select Create First Wait Event (or New Wait Event) to add one.
  • Symptom: You can't find a wait event you expect to see. Fix: Confirm it wasn't renamed or deleted by another user, then select Refresh.
Was this article helpful?
0 out of 0 found this helpful