HR onboarding duplicates accounts due to sequence
A global HR shared service onboards 300 new hires per month across nine countries. A Pega Robotics automation reads a Workday report and creates Active Directory accounts, email mailboxes, payroll records, badge requests, and laptop orders. The current sequence creates the AD account before the HR record is validated by the local HR partner. If the partner later changes the start date or department, the bot creates a second AD account on the next run because the matching key is first name plus last name. Six percent of hires currently receive duplicate accounts, costing about two days of rework each and creating access-review findings. The bot also sends a welcome email immediately after AD creation, before payroll is confirmed, and some hires receive a start date that later changes. The business wants to reduce onboarding cycle time from five days to two days. There is no unique worker ID in the Workday report, but the HR system has one.
1. What process design flaws explain the duplicate accounts, and what sequence would you recommend?
Read the worked answer
The duplicates come from three design choices: creating AD before HR validation, using first name plus last name as the matching key, and having no idempotency check before create. A name is not a unique identifier, and a later start-date or department change should update the existing record, not create a new one. The target sequence should start with a validated HR record that carries the worker ID from the HR system. The bot should read the worker ID, check whether an AD account already exists for that ID, and only then create or update. Payroll should be confirmed before the welcome email, and the welcome email should wait until the start date is stable. Badge and laptop can follow, but they should also correlate on worker ID. This is a process redesign, not just a robot fix. If the Workday report lacks worker ID, the first action is to have HR add it or provide a reliable cross-reference. Automating a bad sequence faster would increase the duplicate rate.
2. What controls and exception handling should accompany the redesigned bot?
Read the worked answer
Add an idempotency check before every create action, keyed on worker ID and object type. If an account exists, update it rather than create. If the worker ID is missing or ambiguous, stop and route to an exception queue; do not guess. Build a reconciliation report that compares HR records, AD accounts, payroll records, and badge requests daily. For start-date changes, define a business rule: before the start date, update; after the start date, route to HR for review. Handle rehires explicitly so they do not get a second identity. The exception queue should carry the worker ID, the failed step, the source data, and the reason. Notify the local HR partner with a clear action, not just an error. Audit every create and update. These controls turn the bot from a fast source of duplicates into a controlled provisioning process.
3. How would you define success and collaborate with HR and IT security?
Read the worked answer
Success should be measured by duplicate accounts per 100 hires, onboarding cycle time, access-review findings, welcome-email accuracy, payroll setup accuracy, and exception aging. A two-day cycle time is not a win if duplicates rise. Collaborate with HR as the data owner to include worker ID and validation status, and with IT security on naming and access rules. Agree on a validation SLA so the bot is not waiting indefinitely. Pilot in one country with a known duplicate problem, compare before and after, then scale. Hold a weekly review with HR, IT, and security during the pilot. The reasoning is that the bot depends on upstream data quality and downstream identity rules; those are cross-team agreements, not robot settings.