Automation maintenance
Learn to understand an existing workflow, investigate failures and check changes through a maintenance routine that another team member can follow.
Find your starting point
A good fit when you already build automations and need to understand failures, test fixes and leave documentation another person can follow. The approach is general and adapts to the tools your team uses.
- Hours and sessions
- 8 hours live · 4 sessions of 2 h.
- Group size
- Up to 12 participants per trainer as a reference, adjusted to the practice and feedback.
What you will learn
- 01
Explain an existing workflow and locate its connections, dependencies and failure points.
- 02
Follow a record through an execution and distinguish incorrect or incomplete data from a workflow failure.
- 03
Test a correction and document the incident, its impact and how to undo the change.
A proposed programme
Investigate incidents in an internal-request workflow that creates practice tasks. Follow each input, check which actions actually took place and decide what to correct or recover. The exercise ends with a tested correction and instructions that avoid blindly running the whole workflow again. Adapt the case and recovery approach to your team’s tools.
We adapt the selection and depth of the modules to the group's starting point and goals.
01Understand before changing
Workflow map, connections, owners and minimum operating documentation.
You will work on
- Map a request’s journey and locate connections, identifiers and actions that change data.
- Relate the request identifier to its execution and destination task, distinguishing the data belonging to each system.
- Agree who maintains the workflow, what to check and when to stop and request intervention.
- Practice
- Follow the classroom workflow and locate a request, its execution and the task record it produced.
- How you will check it
- A map with source, destination, owner and references that let someone follow the same request from start to finish.
02Investigate incidents
Available history, input data and ways to reproduce and isolate an error.
You will work on
- Compare history inputs, outputs and warnings to locate the first departure from the expected result.
- Distinguish incomplete data, access requiring intervention and a temporary failure that might allow a limited retry.
- Check which actions already took place before choosing a data correction, completing an outstanding step or repeating an isolated test.
- Practice
- Investigate a warning after task creation and compare it with a request missing a required value.
- How you will check it
- A report separating the cause, observed effect and outstanding action; a warning is not treated as proof that nothing happened.
03Change and maintain
Tests, change records, access reviews and recovery guidance.
You will work on
- Save a reference to the previous configuration, apply a small correction and test a normal input and an exception.
- Distinguish completing an outstanding step from replaying the whole workflow; check the environment’s recovery options, limit attempts and avoid repeated effects.
- Document the correction, tests, intervention owner and how to restore the previous configuration without promising to undo external actions.
- Practice
- Correct the incomplete-data handling, check the existing task and prepare recovery without creating it again.
- How you will check it
- A test matrix and recovery guide with references, retry limits, manual decisions and a way to revert the configuration.
A warning does not mean the task is missing
Teaching example
Suggested practice: investigate a warning in an internal-request workflow, check whether the destination task already exists and prepare recovery without repeating actions. Propose a correction, compare test cases and document the incident. The case is adapted to the tool your team uses.
Fictional classroom case. The workflow turns internal requests into practice task records. REQ-030 completes the journey; for REQ-031, task TASK-208 was created but confirmation recording failed. Another request, REQ-032, has no subject and needs that value corrected before task creation.
- Starting point
- The incident is described as “the workflow failed”. The link between request, execution and task is not retained, so it is unclear which part completed.
- First attempt
- The first attempt proposes running REQ-031 again from the start, which could repeat task creation. It also proposes retrying REQ-032 without correcting the subject, although another attempt would not supply the missing value.
- What we review
- The trainer asks the group to check the history and destination before acting. They find TASK-208, identify the outstanding confirmation and separate that problem from the incomplete data. They then choose recovery supported by the environment: complete only the outstanding work if possible, or prepare a checked manual intervention. Replaying the whole workflow is not equivalent to resolving the incident.
- Result
- The guide retains the REQ-031 → TASK-208 relationship and supports checking the outstanding confirmation without recreating the task. REQ-032 awaits a corrected subject. The decision, tests and attempt limit are recorded; if it is unclear whether an action occurred, review is requested before repeating it.
Follow the data before recovering
- Classroom request
Find the input
Identifier and received data.
- History and destination
Relate the references
Which task exists and which step failed?
- Decision
Choose how to continue
Correct data or request intervention before repeating.
- Task register
Check recovery
Retain the existing task and review what remains.
Teaching illustration of a fictional case; it groups workflow checks rather than reproducing every step or executing connections.
What happens to each input
Checked normal journey
- Request
- REQ-030
- Subject
- Prepare the delivery guide
- Practice task
- TASK-207 · confirmed
Expected result: one task linked to REQ-030 and a recorded confirmation.
The input identifier, history and TASK-207 are compared; a completed execution status alone is not sufficient.
Incident requiring intervention
- Request
- REQ-031
- Destination task
- TASK-208 · already exists
- Prepared incident
- Confirmation recording failed
Expected result: retain TASK-208 and resolve only the outstanding work after checking the cause.
History and destination are compared. Task creation is not replayed; recovery is chosen from the environment’s verified options.
Before calling it complete
- The request can be related to its execution and the destination task record.
- Recovery begins by checking which actions occurred and which data or permission is missing.
- Tests do not recreate the existing task, and the guide separates reverting configuration from undoing effects.
Four sessions to put it into practice.
Reference edition · 8 h live
Reference edition: 8 live hours in 4 two-hour sessions. Diagnosis, correction and testing take place in the sessions, using the classroom case. Practice is adapted to the client’s setup and its history and recovery options are checked.
- Session 12 h
Understand the workflow and its references
Follow a normal request, map connections and relate identifiers for the input, execution and destination.
By the endA workflow map and a check of the expected result.
- Session 22 h
Diagnose before making blind changes
Read inputs, outputs and warnings; compare incomplete data, invalid access and a prepared temporary failure.
By the endA focused incident report separating the cause from its effects.
- Session 32 h
Correct and prepare recovery
Save the previous reference, correct the test workflow and check which actions occurred before recovery.
By the endA correction checked against a normal case and one requiring intervention.
- Session 42 h
Review and leave instructions
Repeat the agreed checks with feedback, document retry limits and explain how to revert the configuration.
By the endA maintenance guide another person can follow without blindly repeating effects.
If your team needs to go further
- Operating live workflows, intervening in production incidents or taking over maintenance requires separate scope and responsibilities.
- High availability, load testing, exactly-once processing guarantees and complex integrations are outside this edition.
Learn with someone who develops automations.
Borja Martínez
Automation consultant
Over two years of experience developing projects for companies across industries and sizes.
Borja is the planned trainer for this programme. Dates, language and his availability are confirmed when the edition is agreed.
With guidance, practice and support.
Each delivery includes working materials, feedback on practical work and assessment against the agreed objectives.
Materials you can keep
Downloadable, versioned guides, exercises and review criteria for internal use.
To prepare and complete the delivery
A short recommendation, an editable communications kit and a group learning report.
TOF’s own certificate
A certificate of achievement after the agreed assessment. It is not a vendor certification.
A month of email support
On the content covered, up to two accumulated hours for the whole group.
Your team carries out the practice. Implementation services are agreed separately. See the scope →