This is a ready-to-use change and version log for a single GxP RPA bot. Open a new row every time the bot’s own logic changes, the platform is patched or upgraded, or a system the bot drives changes in a way that could affect the bot. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. This content is educational reference, not legal or regulatory advice.
Form control
| Field | Entry |
|---|---|
| Form title | RPA Bot Change and Version Log |
| Form number | <<FILL: FORM-ID, e.g. FORM-RPA-004>> |
| Bot ID / name | <<FILL: from the bot register>> |
| Parent validation plan / report | <<FILL: VAL-RPA-.. reference>> |
| Owner | <<FILL: role, e.g. RPA governance lead>> |
Why this form exists
RPA breaks the “validate once, leave alone” assumption harder than most system classes, because the applications underneath a bot change independently of the bot. A version log that tracks only changes to the bot’s own logic misses the more common failure: a LIMS, ERP, browser, or operating system upgrade that moves a field or changes a response time and silently breaks a bot nobody touched. This form captures both kinds of change in one place, so an auditor, or a developer returning to the bot months later, can see exactly what it has lived through. It also closes a gap between two other controls that often get filed separately: the bot inventory register that lists which systems a bot depends on, and the periodic review that watches the bot’s exception rate for drift. Without a single change history tying those together, a reviewer who notices a rising exception rate has no quick way to check whether a system change explains it, and ends up re-investigating from scratch something this form would already have answered.
Change log (one row per change)
| Change ID | Date | Trigger type | What changed (before) | What changed (after) | Systems affected | Impact assessment outcome | Retest required? | Retest evidence ref | Approved by / date |
|---|---|---|---|---|---|---|---|---|---|
<<FILL: CHG-001>> | <<FILL>> | <<FILL: bot logic / platform upgrade / target-system change / credential rotation>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: no impact / impact, retest / impact, retire>> | <<FILL: Y/N>> | <<FILL: protocol ID or test record>> | <<FILL>> |
<<FILL: CHG-002>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Field definitions and instructions
| Field | Instruction |
|---|---|
| Trigger type | Classify every change, including ones nobody at the company asked for: a vendor patch to the LIMS is logged exactly like a developer editing the bot’s selectors. |
| What changed (before/after) | Describe the actual difference: a field moved, a selector was rewritten, a library version changed, a credential was rotated. An entry that just says “updated bot” does not meet the bar. |
| Systems affected | Name every system touched by the change, cross-referenced against the “systems driven” column of the bot inventory register. |
| Impact assessment outcome | State the conclusion and who reached it. A conclusion of “no impact” needs the same rigor behind it as “impact, retest”; it is never a default. |
| Retest required? | If yes, link the retest evidence before the row is closed. A change is not closed until any required retest is recorded. |
| Approved by / date | The approver is independent of whoever made the change. |
Retain this log as a controlled record for not less than <<FILL: retention period>>, alongside the bot’s validation package.
Acceptance criteria
- Every change to the bot’s own logic appears here, with no unexplained gap between consecutive versions.
- Every change to a system the bot drives that could plausibly affect the bot also appears, not only changes to the bot itself.
- A “no impact” conclusion states the basis, not just the word.
- No row shows “retest required: yes” without a linked retest record.
- This log stays current with the bot register’s “systems driven” column, so a system not listed there cannot generate a surprise entry here.
Filled specimen
| Change ID | Date | Trigger type | Before | After | Systems affected | Impact assessment | Retest? | Retest ref | Approved |
|---|---|---|---|---|---|---|---|---|---|
| CHG-014 | 2026-09-02 | Target-system change | LIMS v7.2, result field at screen position 4 | LIMS v7.3, result field moved to screen position 6 after a vendor UI update | LIMS | Impact: the bot’s selector was coordinate-based and would read the wrong field. Retest and selector rework required before go-live of LIMS v7.3. | Y | VAL-RPA-012-T2 | R. Gomez, QA, 2026-09-04 |
| CHG-015 | 2026-09-10 | Bot logic | Read-back comparison used exact string match only | Read-back comparison also normalizes trailing whitespace before comparing | RPA-STAB-01 bot only | No impact on other bots; the change narrows this bot’s own false-positive exception rate | Y | VAL-RPA-012-T3 | R. Gomez, QA, 2026-09-11 |
CHG-014 is the case this form exists for: nobody changed the bot, the LIMS vendor did, and a coordinate-based selector would have silently read the wrong field after the upgrade. Catching it as a scheduled impact assessment, before the LIMS upgrade went live, is what the bot register and this log are built to do together.
Common inspection findings this form prevents
- A LIMS, ERP, or platform upgrade with no record that anyone checked whether a dependent bot was affected.
- A “no impact” conclusion with no documented basis.
- A retest claimed with no evidence record behind it.
- Gaps in a bot’s own version history with no explanation.
- The change log and the bot register disagreeing about which systems a bot depends on.
How to adapt this form
- Set the form number and link it to the bot’s validation plan and its bot-register entry.
- Make “systems affected” a controlled list drawn from the register rather than free text, so it stays consistent across bots.
- Wire your system-change-ticket process to open a row here automatically whenever a system named in the register changes.
- Require retest evidence to be linked before a row can be marked closed.
- Review open rows at the same cadence as periodic review, so nothing sits half-assessed.