Start with what can change
A new request category, a changed screen layout or an updated data field can affect existing automation. A colleague leaving, an expiring connection or different supplier licensing also needs attention. Not every change immediately produces an error message.
Create a short maintenance record for each automation. Explain its purpose, the systems and data it needs, and who communicates relevant changes. This is a different task from designing the initial pilot: the question now is how to keep an existing service useful.
Assign the recurring work
Name someone responsible for the business outcome and someone able to assess technical operation. In a small organisation, these may be the same person. Identify a replacement as well. The record should be usable by someone who was not involved in the original build.
On a narrow screen, scroll the table sideways. With a keyboard, focus the table and use the arrow keys.
| Area | What to record | Reason to check |
|---|---|---|
| Ownership | Responsible person and replacement | Handover or staffing change |
| Dependencies | Systems, fields and connections | Source or supplier change |
| Outcome | Expected business result | Unexpected volumes or sample check |
| Maintenance | Last test and next check | Planned change or scheduled check |
Schedule checks according to the process's impact and rate of change. A monthly check may be a useful agreement; it is not a universal standard. Reserve time for changes that arise between scheduled checks. Without capacity to act, ownership remains little more than a name on a document.
Fictional example: a green status hides missed requests
A fictional wholesaler uses automation to route service requests to the right department. Its website adds a category for replacement parts. The existing automation processes familiar categories without errors but does not include the new one.
The technical dashboard stays green while requests remain unassigned. Comparing incoming requests with assigned requests reveals the gap. A lasting improvement is to require advance notice of category changes from the website owner and update test cases alongside the form. This example shows why maintenance must cover changes in meaning and coverage.
Make changes repeatable
Record which version is in use and which change was tested before release. Use examples with expected results defined in advance. Check whether a change affects neighbouring steps, and note who can explain what changed.
For Power Platform, Microsoft describes unmanaged solutions for development and managed solutions for testing and production. This provides a concrete pattern for separating changes from live use. Choose an approach that fits your platform. Handling an error that has already occurred is covered separately in automation exceptions and recovery.
Check coverage and business outcomes
Alongside technical errors, check whether expected requests are picked up, processing finishes on time and results are correct. Agree who investigates a deviation. Otherwise, you have a dashboard everyone can view but nobody acts on.
Establish what monitoring actually covers. Microsoft's Automation Center shows only solution-based cloud flows in its cloud-flow run history; cloud run history can take up to an hour to appear. Permissions and retention settings also limit visibility. An empty view therefore does not necessarily establish that everything is working.
Track supplier changes as maintenance work
Context — 29 October 2026. Microsoft documents notifications from October for pipelines deploying to unmanaged target environments. Administrators have thirty days to approve Managed Environments before future deployments may be blocked. An extension can be requested. This is a documented rollout change, not a notice that existing automations will stop. Check your tenant notification and licensing against the pipeline documentation.
Track product retirements too. UiPath removed Unassisted Task Mining from Automation Cloud on 1 December 2025, including associated projects. This does not apply to all task mining, but it illustrates why a dependency record should include product versions and available exports.
Practical do’s and don’ts
- Do: connect system changes with checks of affected automations.
- Do: include maintenance, licensing and handovers in recurring costs.
- Do not: take a successful run as proof that every intended case was processed.
- Do not: leave knowledge of connections and definitions solely with the original builder.
Frequently asked questions
Does every automation need an extensive maintenance process?
No. Match the effort to its impact and dependencies. A short maintenance record can provide sufficient structure for a simple application.
Who identifies a change in another system?
Agree this explicitly with that system's owner. Naming a technical maintainer does not, by itself, ensure that change information reaches them.
When is further modification no longer worthwhile?
Compare the remaining value with maintenance effort, risk and available alternatives. Update recurring costs in the automation business case. Simplifying or replacing the automation may be the better choice.
Make maintenance manageable
Want to identify where existing automations need more attention? Describe the application, the systems involved and any changes coming up.
Discuss your question