Best Practices

Recommended approaches for adopting ScreenPlay in new or existing UI Automation workflows, and practices for keeping them fast and economical at scale.

Recommended approaches for adopting ScreenPlay, whether you are integrating it into existing UI Automation workflows or building new agent-driven automations, and for keeping those automations fast and economical once they run at scale.

Where ScreenPlay belongs in an automation

ScreenPlay is designed to excel at specific, high-friction points, also known as Controlled agency scenarios, representing small, critical areas of automation where traditional tools are most fragile. Rather than replacing entire workflows, ScreenPlay brings agentic execution to the parts that need it most:

• Spröde Selektoren, die leicht kaputt gehen.
• Komplexe UI-Strukturen und dynamische Elemente.
• Schwer zugängliche UI-Elemente wie Popups, virtualisierte Listen, eingebettete Tabellen oder benutzerdefinierte Steuerelemente.

The corollary matters just as much. In unattended automation, you have to trust a run you are not watching, and the deterministic parts of a workflow are the only parts that behave identically every single time. They are also the fastest and cheapest to execute, which is what makes them viable across thousands of runs.

The goal is a maximally deterministic, minimally agentic workflow: classic UI Automation wherever the interface is stable and the steps are known, and ScreenPlay where agentic execution is the only way to reliably meet the business need.

Erste Schritte

The following paths are available, depending on your context.

Aktualisierung von problematischen Automatisierungen

You can use ScreenPlay activities to fix the problematic steps of your current UI Automation, such as:

• Selektoren, die wiederholt fehlschlagen.
• Automatisierungen, die nach UI-Änderungen unterbrochen werden.
• Übermäßig komplexe Logik, die für einfache Aufgaben geschrieben wurde.

Sie können die Aktionen definieren, die Sie über Prompt in natürlicher Sprache anstelle von zerbrechlichen Selektoren oder langer, benutzerdefinierter Logik verwenden. Dadurch wird die Entwicklung vereinfacht und Ihre Automatisierung im Laufe der Zeit robuster.

Erstellen einer Automatisierung von Grund auf granular

If you start a UI Automation from scratch, you can build it entirely using ScreenPlay with granularity.

Jede ScreenPlay-Aktivität sollte einem kleinen, gut definierten Schritt in Ihrem Prozess entsprechen, idealerweise zwei oder drei Schritte, die natürlich zusammengehören.

Dieser granulare Ansatz hat folgende Vorteile:

• Maximiert die Genauigkeit.
• Damit bleibt der Agent fokussiert.
• Verhindert die Überladung des Modells mit zu viel Kontext.

Sie können ein der Komplexität der einzelnen Schritte entsprechendes KI-Modell auswählen, um Kosteneffizienz und Funktionalität in Einklang zu bringen.

Building with a coding agent

You can also build the automation with an AI coding agent using the UiPath Agent Skills, which teach the agent how to author, run, test, and deploy UiPath automations from your development environment. For the catalog and installation instructions, see the UiPath Agent Skills repository.

The authoring skills focus on generating RPA, so what the coding agent produces is deterministic by default, which is the baseline you want. The recommended approach is to review the generated workflow and add ScreenPlay activities at the points where the agentic approach is required.

Those additions should stay deliberate and few. Each one is a place where behavior stops being guaranteed, and where execution time and token consumption increase.

Designing for speed and cost at scale

An automation that runs a handful of times a day and one that runs thousands of times have very different economics. The following practices reduce latency and token consumption without giving up reliability.

Keeping the agentic surface small

This is the highest-impact decision, and it is made at design time rather than tuned afterwards. Every step that can be expressed deterministically is a step that costs no model call, adds no latency, and cannot vary between runs.

The deterministic baseline comes first, with agentic steps added only where they earn their place.

Choosing the right model for each step

The models available in the Model drop-down keep getting faster and more capable at the same time, so speed and quality are much less of a trade-off than they used to be.

Because each ScreenPlay activity carries its own model selection, you can match the model to the difficulty of the step: a fast Basic tier model for routine interactions, a Standard tier model for the steps that genuinely need more reasoning. For the full list of available models, see ScreenPlay.

If your automation was built against an older model, revisiting the selection is one of the cheapest speed improvements available.

Batching multiple actions on the same screen

The ScreenPlay agentic harness can execute several actions on the same screen in a single batch, rather than one action per model call. Fewer model round-trips means lower end-to-end latency, and the difference is most visible on action-dense screens such as long forms.

This is not the default behavior. By default, the harness performs one action at a time, and batching happens only when the task prompt asks for it explicitly. The harness honors these indications when the actions target the same screen.

For example, instead of:

Fill in the customer details form.

use:

Fill in the customer details form. Fill in all the fields visible on the screen in one go, then submit.

Batching applies only to actions that can be performed on the currently visible screen. Steps that require navigation, a page transition, or a change of application are still executed sequentially, because the model needs to observe the new screen before deciding what to do next.

When to stop optimizing

Optimizing purely for execution time and token consumption can push you toward deterministic implementations that are brittle and expensive to keep alive. A selector-heavy workflow that breaks with every minor UI change can cost more over its lifetime than the tokens it saved.

Healing Agent narrows that gap, but it does not close it. Its recovery strategies are a defined and limited set, and they all work at the level of re-identifying a target element for an activity that already exists:

• Changed selector attributes.
• Timing.
• Anchor position.
• AppCard titles.
• The design-time Semantic Selector fallback.

Healing Agent also applies AI-based strategies for:

• Pop-ups obstructing the target element.
• Semantically rephrased labels.
• Computer Vision.

That covers a large share of everyday UI drift, but it cannot absorb changes in the interaction itself, such as a new confirmation dialog, a reordered set of screens, a field that moves to another step, or a flow that now requires a different sequence of actions.

Enabling Healing Agent is not a substitute for designing the workflow well, and it does not keep a fragile deterministic implementation alive indefinitely.

For the parts of an application where you expect that kind of change, ScreenPlay is the better answer. Describing the outcome in natural language and letting the agent work out the interaction at runtime removes the maintenance burden for those steps, at the cost of the model call. Deciding which steps deserve that treatment is worth revisiting as the target applications evolve.