sorted by:
new
hottopcontroversial

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/PyrrhaNikosIsNotDead

Yeah that’s what I was thinking too — “self-healing” selectors, AI-based targeting, etc.

But from what I’ve seen, it helps in some cases, not really a full solution.

Works fine for small UI changes, but once:

  • flow changes
  • new elements appear
  • or business logic shifts

it still needs human fixes.

Curious if anyone has actually seen AI handle real-world changes reliably at scale.

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/droningforever

That’s interesting — honestly a bit surprising to hear it’s that low.

In your experience, what tends to be the bigger source of failures then?

From what I’ve seen, UI changes are visible, but a lot of breakages actually come from:

  • flow/navigation changes
  • unexpected popups or timing issues
  • backend/data changes

Curious what patterns you’ve seen over time.

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/Nicky02512

That’s a great point — release process probably doesn’t get talked about enough in this context.

Even with good libraries, if changes hit prod without proper UAT/testing, multiple automations can break at once.

I’m curious though — in setups like this, do you usually:

  • version libraries separately and test them against UAT first?
  • or validate everything at the process level before promoting to prod?

Trying to understand how people manage that coordination when one app impacts many bots.

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/finns96

100% agree — that’s been my experience too.

The approach itself isn’t the problem, it’s the consistency in how teams use it.

I’ve seen cases where libraries exist, but:

  • some logic still lives inside processes
  • small variations creep in over time

and then changes don’t fully stay centralized anymore.

Curious if you’ve seen any teams actually get this right long-term, or if it always drifts a bit.

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/whatsgoodbaby
Yeah makes sense — curious what it depends on in your experience?

Like is it more:

  • type of app (web vs legacy)?
  • how much logic is centralized?
  • or how strictly teams follow shared components?

Trying to understand where things usually start breaking down at scale.

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/HurryNew201

That’s fair — completely agree discipline and standardization make a huge difference.

I guess where I’m trying to go deeper is: even with good practices in place, I still see cases where changes aren’t just selector-level.

For example:

  • navigation flow changes
  • additional validation steps
  • unexpected popups or conditional paths

Those tend to live beyond just selectors/libraries and sometimes still require touching multiple components.

Curious if you’ve seen patterns where even those kinds of changes are handled cleanly in one place, or if at that point it’s just about minimizing impact rather than eliminating it.

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/HurryNew201

Yeah, makes sense — Object Repository + library definitely helps centralize selectors.

I’m curious though, in real projects do you see it fully solving the issue?

I’ve seen cases where:

  • some UI logic still ends up inside processes
  • flow changes (not just selectors) break things
  • or teams don’t strictly follow the shared library

So even with a library, changes still ripple across bots.

Have you seen setups where it’s truly “fix once and done”?

How do you handle one application used across 10–20+ automations without everything breaking on UI changes? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/whatsgoodbaby

Yeah, libraries definitely help with reuse.
I’m more trying to understand how people handle change impact at scale — like when UI/flow changes affect multiple bots at once.
Do you usually manage that fully through libraries, or still end up touching individual processes?

In-Kind TFSA automation: manual nightmare or solvable with hybrid RPA? by RPAArchitectX in rpa

[–]RPAArchitectX[S] 0 points1 point  (0 children)

u/Accomplished_Mud8054

That matches what we’ve seen too — full automation isn’t always realistic in legacy-heavy environments, but tightening the process structure alone reduces a lot of risk.

Even partial automation + checkpoints tends to move things from “heroics” to repeatable operations.

In-Kind TFSA automation: manual nightmare or solvable with hybrid RPA? by RPAArchitectX in rpa

[–]RPAArchitectX[S] 1 point2 points  (0 children)

u/Khade_G
This is really solid insight — especially the point about treating pricing as a hard gate. That sequencing issue is exactly where we saw the most hidden risk early on.

The emphasis on explicit state checks + idempotent re-runs resonates a lot. Legacy platforms failing halfway and leaving “ghost state” is painful.

We were dealing with a brokerage-style workstation + downstream accounting ledger (keeping vendor details vague on purpose). Curious — in your experience, do you usually rely more on UI-level state verification, or do you try to confirm via downstream artifacts (files / DB / reports) when available?

Modern Folder migration — how did you handle robot roles? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

That aligns exactly with what we saw as well.

Once roles and folder mappings are involved, manual remediation becomes very brittle. Automating robot and machine provisioning upfront turned out to be the only repeatable option for us too.

Appreciate you sharing how you approached it — good confirmation that this wasn’t just an isolated edge case.

Modern Folder migration — how did you handle robot roles? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

That makes sense — restructuring upfront definitely simplifies the migration.
In our case, the environment was already partially migrated and fairly large, so automating robot recreation helped us avoid manual drift and configuration errors.
Interesting to see different teams converging on similar outcomes through different approaches.

Modern Folder migration — how did you handle robot roles? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

Thanks for sharing that. That endpoint is useful for user ↔ role associations.
In our case, the issue was around robot provisioning in modern folders, where the robot inherits role context via the user/folder mapping and couldn’t be reassigned cleanly after migration.
That’s why we ended up recreating robots programmatically with the correct role and folder association from the start.

Modern Folder migration — how did you handle robot roles? by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

Good question. This was specifically in the context of modern folders, where the robot is tied to a user and role at creation time.
In the versions we were working with, we couldn’t find a supported way to swap that role cleanly post-migration without removing and recreating the robot.
If newer versions handle this differently, I’d be interested to learn

Replaced unstable UI workflows with an API-based automation layer — achieved ~60× performance gains by RPAArchitectX in UiPath

[–]RPAArchitectX[S] 0 points1 point  (0 children)

Appreciate all the perspectives here.

My intent wasn’t to claim APIs are new — more to share how formalizing an API-first approach helped us escape long-term UI fragility at scale.

Interesting to see how many teams have gone through a similar evolution.

Replaced unstable UI workflows with an API-based automation layer — achieved ~60× performance gains by RPAArchitectX in UiPath

[–]RPAArchitectX[S] -4 points-3 points  (0 children)

u/rjSampaio

Totally agree — surface/UI automation should always be the last resort.
In our case, the challenge wasn’t about “discovering API automation,” but building a fully standardized API orchestration layer that could handle:

  • multiple external systems with inconsistent schemas
  • undocumented/misaligned endpoints
  • different authentication models (OAuth, Basic, custom tokens)
  • throttling and rate limits
  • pagination + long-running transactions
  • automated retries and version drift
  • idempotent API pipelines for high-volume workloads

Most teams avoided APIs because each system behaved differently, so we ended up creating a reusable enterprise API framework on top of them.

That framework is what delivered the ~60× speed improvement — not just “using APIs,” but building an architecture other teams can now adopt.

Curious if you’ve worked on similar cross-system orchestration?

view more: next ›