Onboarding disconnected applications in IAM used to take us anywhere between 2 to 4 weeks per application, especially when you include full SDLC cycles (development, QA, UAT, and release approvals).
We recently brought that down to less than 2 days in most cases — without building new RPA workflows per app.
This wasn’t about optimizing selectors or improving existing bots.
We ended up rethinking how we approach UI automation itself.
The problem (which I think most teams face)
Working with SailPoint IdentityIQ, we had:
- ~100+ disconnected applications
- Mostly legacy / web-based
- No APIs
- Fully UI-driven
Traditional RPA (using UiPath in our case) works, but doesn’t scale well:
- Every app requires its own workflow
- Onboarding takes weeks when SDLC is considered
- Selector failures after UI changes are frequent
- Maintenance starts consuming more time than development
At some point, it becomes less about automation and more about managing automation.
What we changed
Instead of building automation per application, we tried a different model:
Treat UI automation as instruction execution, not workflow development.
We implemented an agent-based layer on top of UiPath Screenplay.
How it works (high level)
- SailPoint triggers the process for JML(Joined, Mover and Leaver) operations
- A Data Sense Agent layer standardizes incoming data
- A Prompting Agent layer combines:
- Application-specific context (navigation instructions)
- Runtime values (user data, entitlements)
- A Screenplay agent executes those instructions dynamically
Instead of building selectors and workflows, we generate execution instructions at runtime.
Aggregation (accounts / groups)
Disconnected apps don’t expose APIs, so syncing data back is always a challenge.
We used a hybrid approach:
- Agents → handle navigation
- RPA → handles structured extraction and transformation
This avoided overcomplicating the agent layer while still reducing overall effort.
What actually improved (based on our setup)
Onboarding time per application (~85–95% reduction)
Before (2–4 weeks):
- Requirement gathering
- Workflow development
- Selector identification
- QA, UAT, release approvals (full SDLC cycle)
Now (< 2 days):
- Define context grounding (navigation instructions)
- Minimal prompt tuning
- Plug into existing framework
No need to build a new workflow from scratch.
Most of the time is now spent on understanding the app, not developing automation.
Development effort per application (~70–80% reduction)
Earlier, each application required:
- Dedicated workflow
- Exception handling logic
- Reusable components re-implemented per app
Now:
- Same execution layer is reused
- Only configuration + prompt tuning is needed
- Very limited coding (only for edge cases)
So effort shifted from development-heavy → configuration-driven, which reduced overall effort significantly.
Selector-related failures (~60%+ reduction)
Previously:
- Automation depended heavily on static selectors
- UI changes (IDs, layout shifts, dynamic elements) caused frequent failures
Now:
- Execution is instruction-driven (prompt-based navigation)
- Reduced reliance on brittle selectors
- Selectors still exist underneath, but are not the primary dependency
Result: fewer breakages when UI changes.
Maintenance effort (~50% reduction)
Before:
- Each app had its own workflow
- Fixes had to be applied across multiple automations
- High duplication of logic
Now:
- Centralized execution model
- Updates mostly limited to:
- Context grounding files
- Shared components
This removed repetitive fixes and reduced long-term maintenance overhead.
JML turnaround time (~40% improvement)
Joiner/Mover/Leaver operations improved because:
- Applications get onboarded much faster
- Fewer runtime failures → less manual intervention
- Reusable framework → consistent execution across apps
So overall request processing time reduced, not just bot execution time.
Scalability (100+ applications)
Earlier:
- Each new app increased:
- Development effort
- Maintenance load
- Operational complexity
Now:
- Same framework supports 100+ applications
- Adding new apps doesn’t significantly increase system complexity
This is where the biggest impact came from—
scaling without proportional increase in effort.
What this is (and what it isn’t)
I’m not claiming this is entirely new — there’s clearly movement toward:
- Agentic automation
- Prompt-driven execution
- Reducing dependency on static selectors
But applying this specifically to IAM disconnected applications at enterprise scale made a noticeable difference for us.
The shift that mattered
We moved from:
“Build automation per application”
to:
“Build a reusable execution model and configure per application”
That’s what reduced both development and long-term maintenance overhead.
Curious to hear from others
For teams working with disconnected apps or any web based automations :
- Are you still building per-app RPA workflows?
- Have you tried reducing selector dependency in a different way?
- How are you handling aggregation reliably without APIs?(If it is a disconnected app automation)
Would be interesting to compare approaches.
#UiPathMvps Agentic Automation agents maestro uiautomation agentic-automation mvp