AA Advanced RPA common mistakes
AA Advanced RPA · Understand the traps and how to avoid them.
Treating RPA as equivalent to AI and asserting that a standard unattended bot can make judgement calls or learn from experience without any ML component.
Marketing language around 'intelligent automation' blurs the line between deterministic rule-based execution and probabilistic models, so candidates over-attribute cognitive capability to plain RPA.
What to do instead
Separate the layers explicitly: RPA executes deterministic rules on structured inputs; ML adds classification/prediction; NLP handles unstructured text; humans handle exceptions. For any scenario, state which layer performs which step and why a rule-based bot cannot cover the judgement step.
Choosing a technology (RPA vs API integration vs OCR/IDP vs ML) by defaulting to 'build a bot' for every process, including ones with stable APIs or high-volume structured data exchange.
Candidates learn RPA tooling first and pattern-match any automation scenario to it, ignoring that UI automation is the most brittle and least efficient option when a system interface exists.
What to do instead
Apply a decision order before tooling: eliminate/re-engineer, then API/service integration, then document/structured data extraction, then UI automation last. Justify the choice with volume, stability of the UI, and availability of interfaces.
Designing a bot as one monolithic linear sequence with no modular components, no reusable sub-processes, and no separation of business logic from UI interaction.
Candidates optimise for getting a single happy path working end-to-end and never refactor, because the exam scenario 'works' in their mental model.
What to do instead
Structure solutions into layers: a thin UI/action layer, reusable business-object components, and a configuration/data layer. Describe at least one reusable component and how it is invoked across processes.
Omitting exception handling taxonomy, treating every failure as retryable, and providing no defined behaviour for business exceptions versus system exceptions.
Candidates conflate 'the bot crashed' with 'the data was invalid' and assume retries fix both, which produces infinite loops or silent data loss.
What to do instead
Classify exceptions explicitly: business rule exceptions (route to human/queue, no retry), application/system exceptions (bounded retry with backoff, then escalate), and infrastructure exceptions (fail the job, alert). State retry counts and escalation paths.
Ignoring idempotency and transaction boundaries, so a bot that fails mid-process leaves duplicate records or partially committed work on re-run.
Candidates reason about the happy path only and do not consider what state exists when the bot restarts, a common gap for people without production operations experience.
What to do instead
For each process, define the unit of work, the commit point, and how a re-run detects already-completed items (status flags, unique keys, reconciliation checks). Mention compensating actions for partial completion.
Designing credentials and access for bots by giving the bot a human user's login or embedding secrets in the script/config file.
It is the fastest route to a working demo, and candidates have not internalised that bots are non-human identities requiring their own lifecycle.
What to do instead
Specify dedicated bot service accounts with least-privilege roles, secrets held in a vault/credential store, rotation policy, and no interactive logins. Tie each bot identity to an owner and a decommission path.
Presenting a CoE as a single central team that builds everything, or conversely as a purely advisory group, without defining its service catalogue and intake/prioritisation model.
Candidates memorise 'CoE = central team' and cannot articulate the operating model variants or how demand is triaged.
What to do instead
Describe the CoE's functions (standards, platform, pipeline governance, reusable components, enablement), its operating model (centralised, federated, hybrid) with a rationale, and a concrete intake scoring model (value, feasibility, risk) with stage gates.
Scaling by headcount only, ignoring the pipeline, reusable asset library, and change management needed to move from a few pilots to an enterprise programme.
Candidates equate scaling with 'hire more developers' and miss that bottlenecks shift to demand intake, testing, and business ownership.
What to do instead
Identify the binding constraint at each maturity stage and address it: standardised design templates and reusable components to cut build time, a prioritised backlog with business-owned business cases, and a federated champion network for demand generation.
Skipping a quantified business case and baseline, asserting benefits like 'saves time' with no volumes, handling time, error rates, or AHT assumptions.
Candidates focus on technical feasibility and treat benefits as self-evident, so they cannot defend prioritisation or post-implementation measurement.
What to do instead
For every candidate process, state transaction volume, current handling time, exception/error rate, and FTE capacity released, plus a measurement plan comparing baseline to post-go-live actuals. Distinguish hard savings from capacity release.
Treating testing and deployment as a single post-build step, with no test data strategy, no UAT with business sign-off, and no release/versioning or rollback plan.
Candidates build first and plan deployment last, and underestimate that bot failures are usually data and environment issues rather than logic bugs.
What to do instead
Define a test approach covering unit tests of components, negative/exception path tests, volume and performance tests, and business-led UAT with representative masked data. Add version control, environment promotion (dev/test/prod), and a documented rollback and hypercare plan.