ベスト プラクティス

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:

• 中断の多い不安定なセレクター
• 複雑な UI 構造と動的な要素
• ポップアップ、仮想化されたリスト、埋め込みテーブル、カスタム コントロールなど、アクセスしにくい UI 要素

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.

スタート アップ ガイド

The following paths are available, depending on your context.

問題のあるオートメーションをアップグレードする

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

• 繰り返し失敗するセレクター。
• UI が変更されるとオートメーションが動作しなくなる。
• 単純なタスク向けに記述された過度に複雑なロジック。

使用するアクションは、不安定なセレクターや長いカスタム ロジックではなく、自然言語のプロンプトを通じて定義できます。これにより、開発が簡素化されるほか、時間の経過とともにオートメーションの回復力も向上します。

オートメーションをゼロからきめ細かく構築する

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

各 [ScreenPlay] アクティビティは、スコープの適切な、プロセス内の小さなステップに対応している必要があります。自然なまとまりのある 2 つまたは 3 つのステップが最適です。

このような細かい部分に絞るアプローチには、次のような利点があります。

• 精度を最大化する。
• エージェントのフォーカスを維持する。
• 多すぎるコンテキストによるモデルの過負荷を回避する。

各ステップの複雑さに応じて、適切な AI モデルを選択し、費用対効果と機能のバランスをとることができます。

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.