ScreenPlay for Web Tool

Help Something Else
1

if we have the opportunity to use a simple tool like ScreenPlay for Web, why should we develop rpa workflows?
i’m really confused

2

Hi @Sal23

For a few reasons:

  1. Consumption of AI units - RPA can use free techniques while Screenplay consumes AI units
  2. Navigation Speed - Because Screenplay is interpreting a prompt and then attempting to execute all actions in real-time, it is slightly slower.
  3. Prompt Accuracy - Screenplay requires you to have decent knowledge of prompt engineering. If you use a bad prompt, you get a bad workflow… Not as “easy” as you think.
  4. Sometimes its just really not necessary… If you’re doing basic navigation and capturing, go with RPA. It’s easy and accurate because you can manipulate selectors like we’ve been doing for years. Screenplay isn’t just a “Fix all my issues” solution.

Hope this helps :slight_smile:

3

thank you so much for your response,

so because of these reasons, we prefer the normal rpa techniques,
so when should we use the Screenplay and not a normal workflow ?

4

Hi @Sal23

We prefer traditional UiPath RPA workflows whenever possible because they are deterministic, reliable, easier to govern, and typically do not consume AI units during execution, making them more cost-effective for stable applications. ScreenPlay should be used when selectors are unreliable, the UI changes frequently, or the maintenance effort of traditional automation becomes high. Although ScreenPlay can consume AI-powered capabilities and associated AI resources, it can reduce overall maintenance costs and improve resilience in complex UI scenarios.

If helpful, mark as solution. Happy automation with UiPath

5

Here is a use case where regular RPA was not working and ScreenPlay worked well. It saved time, was efficient, and provided faster resolution. Downside: it will consume AI units, so it’s always a trade-off.

Unable to Extract All Flight Details from MakeMyTrip Search Results - Help / Studio - UiPath Community Forum

6

Hi @Sal23,

For faster, reliable, and AI-free automation, use RPA workflows. Use ScreenPlay where UIs change frequently (e.g., during application testing with regular code deployments) or when UI interactions are too complex for traditional automation, such as extracting large amounts of data from dynamic screens.

The best approach is often hybrid: ScreenPlay for adaptive UI interactions, and RPA workflows for the remaining business logic and orchestration.

Thanks

7

Well here’s a good example. I had to use Screenplay for this process recently:

I created a UI process that had to navigate through an ERP and capture a few fields etc. During the capturing, when a specific field was clicked, a popup appeared, but it wasn’t your “normal” popup. It was a JavaScript injected popup - meaning that adding a new “Use Application/Browser” activity didn’t latch onto this window, and the JS injector activity also failed. Also, within this window, it was very difficult to scroll down and select the resource I needed, because it had nothing unique about it to configure in the selector as opposed to it’s corresponding fields.

So I decided to use Screenplay. I prompted Screenplay to find the new JavaScript popup and then scroll to find the resource that had an icon next to it which needed to be selected. I gave it 5 very precise prompts (numbered accordingly) and it worked perfectly. This for me was the best solution and upon testing, never gave an issue.

It’s these small tasks where it might be necessary. It’s also great for testing… If you have volumes of test cases to run which have similar UI based navigations (not identical) but with different data, then Screenplay is also great.

I would say first try use generic activities to your best ability, and if you really struggle, then look at Screenplay. It’s a really cool tool though.