Hello! I wanted to share my testing results, observations, and recommendations after experimenting with the UiPath Screenplay Task activity. My goal was to understand how prompt structure, DOM usage, and configuration choices impact performance, reliability, and scalability.
Scenario Overview
To test Screenplay, I built a simple GPU price-checker automation that:
- Loops through three electronics retailers (Newegg, Micro Center, Amazon)
- Searches for Radeon RX 7000 GPUs
- Sorts by best/highest rated
- Returns the top 2 non-sponsored results with:
- Name
- URL
- Price
- Rating
Automation Structure
- A Main.xaml sequence reads a config file that defines the scenarios to run.
- A switch statement selects one of five prompt variations per run.
- The Screenplay Task activity is called inside a loop using the selected prompt.
This setup worked well as a lightweight testing framework and could easily be reused to benchmark other Screenplay scenarios.
Parameters Tested
Prompt Variations
I tested five prompt variations to evaluate:
- Variable substitution vs. plain text
- Explicit interaction constraints (keyboard vs. mouse)
- The effect of allowing or disallowing product-page navigation
- Using Custom Instructions vs. embedding everything directly in the prompt
Note:
I attempted to read prompts dynamically from the Config file, but Screenplay no longer replaced prompt variables (e.g.,<[ProductLookup]>). While string replacement could work, I hard-coded prompts in XAML for this round of testing.
| ID | Prompt Summary | Notes |
|---|---|---|
| 1 | Variables + explicit “avoid hotkeys, favor mouse clicks” + do not click listings | Over-instructed |
| 2 | Variables + do not click listings |  Best overall |
| 3 | Plain-text, no variables | Mixed results |
| 4 | Plain-text, allows clicking listings |  Worst performer |
| 5 | Variables + “do not click listings” via Custom Instructions | Strong, site-dependent |
Screenplay Task Properties
| Property | Value | Notes |
|---|---|---|
| Use DOM when available | Config-driven | Tested both on and off |
| Disable Variable Security | True when Custom Instructions present | Required for passing instructions |
| Type by Clipboard | Whenever possible | Significantly faster than key-by-key input |
| Model | Screen Agent (Gemini 2.5 Flash) | Other models showed similar behavior |
| Input Mode | Chromium API | Used as baseline; others not tested |
Test Results Summary
Best Performing Prompt
Prompt 2 (variables + “do not click listings”, no hotkey instruction)
This was the best overall configuration across all three stores without DOM:
- Newegg: 1.58 min
- Micro Center: 0.89 min
- Amazon: 3.98 min
The difference between Prompt 1 and Prompt 2 is subtle — removing the “avoid hotkeys / favor mouse clicks” instruction actually improves performance, likely by reducing reasoning overhead with no loss of reliability.
Clear Failure Mode
Prompt 4 (allows clicking product listings) is the single biggest performance killer.
- Newegg: 9.37 min
- Amazon: significantly slower as well
Once the agent is allowed to open product pages, runtimes balloon dramatically. This test confirms that “Do not click any product listing” is a critical instruction and should always be included.
Mixed Results
Prompt 3 (plain text, no variables)
- Fastest Amazon run with DOM (2.06 min)
- Poor performance on Newegg without DOM (3.90 min + partial output)
Variable substitution does not appear to harm performance and provides far better reuse, so there’s little motivation to use fully hard-coded text.
Custom Instructions (Prompt 5)
Using Custom Instructions to inject “do not click listings” works very well:
- Fastest Newegg run without DOM: 1.56 min
- Strong Micro Center performance
However, on Amazon with DOM, it produced the slowest Amazon run (4.18 min). Amazon appears more sensitive to added reasoning paths introduced by Custom Instructions.
DOM Observations
- Micro Center: DOM usage makes little difference
- Amazon: DOM helps some prompts (P3, P4) but severely hurts others (P1, P2)
- One data anomaly returned Micro Center URLs during an Amazon run, suggesting a browser context issue—its timing should be ignored
Best Overall Configuration
Prompt 2 + No DOM
Reliable, fastest average performance, and consistent across all three sites.
Screenplay Takeaways
What Screenplay Does Well
- Handles net-new and unfamiliar systems with zero selector work
- Self-corrects when UI structure changes instead of hard-failing
- Produces clean, structured output when prompts are well designed
- Ideal for attended or unattended automation and exploratory workflows where runtimes of 1–10 minutes are acceptable
Scalability Ceiling
Screenplay has a hard performance floor:
- Each reasoning loop costs ~15–60 seconds of inference time
- This latency compounds quickly
- Three sites × one task totaled 15–18 minutes before tuning and 6-8 minutes after tuning.
- A realistic enterprise process (10–20 steps) would be unworkable at scale, even after tuning.
This is not an implementation flaw—it’s the inherent cost of agentic execution.
Recommended Usage Pattern
Use Screenplay as a first-responder and fallback, not a primary execution engine.
Suggested pattern:
- Route new or unknown systems through Screenplay
- Collect runtime and stability data
- Promote frequently-used systems to selector-based automations
- Retain Screenplay as:
- A discovery tool
- A break/fallback path
- A safety net when selectors fail
Screenplay shines by eliminating the barrier to first automation and by ensuring automations never “just stop working.”
Practical Usage Tips
1. Create a Testing Framework
- Standardize prompt variants and DOM settings
- Log execution time and output quality
- Compare results to identify the best “recipe” per scenario
2. Keep Tasks Focused
- Each Screenplay Task should have a single, well-defined outcome
- Favor modular, composable tasks over end-to-end prompts
3. Prompt Engineering Matters
- Over-instruction adds reasoning overhead
- Too much freedom increases exploratory actions
- Balance clarity with restraint
4. Use the HTML Trace Files!
The Trace Files output generates a detailed HTML report with:
- Agent reasoning
- Step-by-step actions
- Screenshots
They are incredibly valuable, but dense. I fed them into another AI agent to extract tuning recommendations.
Example recommendations:
- Extract ratings directly from search results pages
- Only navigate to product pages as a last resort
- For Newegg, click the search button instead of pressing Enter
- Pre-navigate to “Highest Rated” URLs to eliminate sorting steps
5. Exception Handling
The ScreenPlay Task can fail to achieve its outcome, and may return an exception. Handle exception as needed for your use case.
Wishlist Feature
Screenplay would be dramatically more powerful if it learned over time.
Idea:
- On first run, record resolved selectors (search bar, sort control, price field, etc.)
- Cache them by domain and page structure
- On subsequent runs:
- Try cached selectors first
- Fall back to AI reasoning only when they fail
- Update the cache when changes are detected
This would preserve Screenplay’s self-healing nature while allowing it to converge toward native selector performance over time.
Conclusion
I’m excited to add Screenplay to my automation toolbox. Used correctly, it’s an excellent discovery engine and resilience layer—not because it’s fast, but because it can find its way through the unknown.
When implemented thoughtfully, Screenplay can make an entire RPA program more adaptive, maintainable, and future-proof.
