18.2 Running Local Triggers & the Event Inspection Tool
Key Takeaways
Run Local Triggers starts all local triggers of the project in parallel through a generated TriggerEventArgs workflow.
Each trigger workflow receives a TriggerEventArgs argument with the trigger type, name, and target element or form details.
Stop Local Triggers cancels running trigger workflows while the main workflow continues.
Enable Local Trigger and Disable Local Trigger switch individual triggers on and off at run time.
The Event Inspection Tool (UI Explorer > Inspect Events) records native events such as Click, Key pressed, and Focus gained, with Clear and CSV export.
18.2 Running Local Triggers & the Event Inspection Tool
Core Concept: The exam description names "native event triggers: Run Local Triggers & Stop Local Triggers" and the Event Inspection Tool. Run and Stop Local Triggers control when an attended project listens for events, and the Event Inspection Tool shows which native events a UI element raises so you can configure an Application Event Trigger correctly.
Run Local Triggers
Run Local Triggers initializes and starts all local triggers of the project, that is, every trigger workflow listening for events on the user's machine.
- Behind the scenes it generates a separate, read-only workflow named TriggerEventArgs at run time or while debugging. That workflow contains Trigger Scope activities that run all the project's triggers in parallel.
- It can be used inside a workflow, or invoked from another workflow with Invoke Workflow File.
- Activities placed after Run Local Triggers in the same workflow run only after the triggers stop.
The TriggerEventArgs argument
After the first run, each trigger workflow receives its own TriggerEventArgs argument with information about the event that fired it:
- The trigger type and trigger name.
- For user event triggers: the TargetElement that fired the trigger, with its Attributes, Selector, ImageBase64 (an image of the element), and DisplayDpiScaleFactor.
- For form triggers: the FormSourceId and the form's Instance Name, plus the form components involved.
Use these values instead of searching the screen again, for example to read which row of a grid the user clicked.
Stop Local Triggers
Stop Local Triggers terminates the local triggers:
- It cancels all ongoing actions, including workflows that triggers started and that are still running.
- The activities of the main workflow continue as usual.
A typical design lets a "Close assistant" button on the side form call Stop Local Triggers, after which the main workflow saves its work and ends.
Enable and Disable Local Trigger
When many triggers are active, or when triggers only make sense at certain stages of the user's work, use:
- Disable Local Trigger to pause one or more triggers that Run Local Triggers started.
- Enable Local Trigger to activate them again, including triggers whose Enabled property was False at start.
Example: the "Submit claim" trigger is disabled until the "Check policy" workflow has passed, then enabled.
The Event Inspection Tool
Application Event Trigger needs an event type, and the available events depend on the element and its technology. A web element may expose different events than a Java or desktop element. The Event Inspection Tool shows which events the element really raises when the user interacts with it.
Opening and using it
- Open UI Explorer, select a valid UI element, and select Inspect Events on the toolbar.
- In the Event filter, choose the event types to monitor, such as Click, Key pressed, Focus gained, and Focus lost.
- Start recording and interact with the element as the user would.
- The Event list shows each captured event with its details.
- Clear deletes the recorded events, and CSV exports them for analysis.
Then configure the Application Event Trigger with the event type you saw.
Native event families
Application Event Trigger supports native events from several technologies: WND (top-level windows), CTRL, JAVA, WEBCTRL, HTML, and UIA. For a top-level window, examples are Appeared, Disappeared, Title changed, State changed, and Location changed. Each event passes a matching argument type, such as TextChangedArgs for title changes or StateChangedArgs for state changes.
Application Event Trigger Settings Worth Knowing
| Setting | Meaning |
|---|---|
| Target | The top-level window or element; only strict selectors, without anchors |
| Event type | Required; the list depends on the element |
| Selectors | Additional full selectors to monitor for the same event |
| Include children | Also monitor the element's children (not for Appeared or Disappeared, and not for top-level windows) |
| Match sync | Synchronous selector matching, supported only for Java events other than Appeared and Disappeared |
| Scheduling mode / Enabled | As for other triggers |
Worked Example
A service desk agent should see customer details whenever they select a ticket row in a desktop ticketing tool.
- With Inspect Events, the developer finds that selecting a row raises a State changed event on the row element, not a Click event on the grid.
- The trigger workflow starts with an Application Event Trigger on the grid with Include children selected and the event type found in step 1, using Sequential Collapse so rapid row changes only process the latest selection.
- The workflow reads the ticket ID from TriggerEventArgs and updates a side form with Set Form Values.
Troubleshooting Checklist
- The trigger never fires: inspect the element's events with the Event Inspection Tool; the event you chose may not be raised by that element.
- The trigger fires too often: narrow the target, turn off Include children, or use Sequential Collapse so bursts collapse into one run.
- Workflows keep running after the user is done: call Stop Local Triggers from a close action.
- A stage-specific trigger fires too early: start it with Enabled set to False and enable it later with Enable Local Trigger.
What happens when Stop Local Triggers runs while two trigger workflows are still executing?
The two trigger workflows finish, and then the main workflow stops.
The whole process ends immediately, including the main workflow.
Only triggers with Concurrent scheduling mode stop.
The ongoing trigger workflows are canceled, and the activities of the main workflow continue as usual.
A developer does not know which native event a desktop grid raises when the user selects a row. What should they use?
The Event Inspection Tool, opened with Inspect Events in UI Explorer, to record and view the events the element raises.
The Immediate panel during debugging.
Orchestrator monitoring.
The Workflow Analyzer.
What does Run Local Triggers generate behind the scenes?
A new Orchestrator process for each trigger.
A time trigger in Orchestrator.
A read-only TriggerEventArgs workflow that runs all the project's triggers in parallel, and a TriggerEventArgs argument for each trigger workflow.
A queue that stores events until a robot is free.
Sections you finish are checked off in the contents.