Is your workflow ready to automate?

Observe the real process before automating it

Choose one repeated outcome, such as creating an internal job after an accepted request. Follow several recent examples from start to finish. Record what actually triggered the work, which information was missing, who made each judgement and where the result was stored. The official procedure may say “copy approved requests into the tracker,” while the real process includes checking duplicates, resolving customer names and asking a manager about unusual work.

Automation makes an existing rule run more consistently; it does not make an unclear rule correct. If two experienced colleagues handle the same input differently, decide whether both paths are valid, whether a business rule is missing or whether judgement must stay with a person. Stabilize the smallest useful segment first. A process that changes every week may need redesign and measurement before it needs a connector.

Use this workflow readiness decision sheet

Complete the sheet for one defined workflow. Mark unknowns openly and give each one an owner. A row of tool names is not a process map; write the event, information and decision at every handoff.

• Trigger: Which observable event starts one workflow instance, and how is a repeated or corrected event recognized?
• Required inputs: Which fields must be present, what formats are valid and which system supplies the authoritative value?
• Rules: Which decisions are deterministic, who approved them and where can an operator read the current version?
• Exceptions: Which cases need judgement, missing information or a separate route, and how are they placed into a visible queue?
• System access: Do the tools provide supported APIs, webhooks or exports with suitable permissions and documented limits?
• Outcome owner: Who confirms that the business result is correct rather than merely seeing that a technical step ran?
• Manual fallback: How does the team continue safely, reconcile later and avoid performing the same action twice?

Check data quality at the workflow boundary

Define validation from the business meaning of each input. OWASP recommends validating as early as possible and using allowlists for structured values where practical. For a request type, that may mean a known identifier rather than any free-text label. For a date, it means a supported format and a sensible business range. Preserve the original record for investigation, but do not silently guess a missing value that changes the outcome.

Separate invalid data from a valid exception. A malformed date cannot be processed; an otherwise valid request above a threshold may require review. Route these states differently and make each visible to the right owner. Sample recent records to estimate how often required information is absent or inconsistent. The purpose is to expose work the proposed automation would otherwise hide, not to produce a flattering readiness score.

Hypothetical example: preparing accepted inquiries

Consider a hypothetical commercial cleaning business. Staff currently read website inquiries and create a preparation task when the postcode is in the service area, a preferred start month is present and the requester has confirmed they represent the site. Observation shows that free-text postcodes are inconsistent and multi-site requests require a coordinator’s judgement. The team standardizes the required fields and keeps multi-site work in a review queue.

The proposed automation starts only after the inquiry has been durably accepted. It validates the service-area code, checks a stable inquiry identifier for duplicates and creates one preparation task. The duty coordinator owns the outcome and reviews a daily count of accepted inquiries, created tasks and exceptions. During an outage, staff use the accepted-inquiry list and mark manually created tasks with the same identifier for later reconciliation. This is a hypothetical planning example, not a Kinetivy client result.

Name the access, outcome and change owners

NIST’s Cybersecurity Framework 2.0 places governance and asset understanding around operational controls. Apply that idea in proportion to the workflow: list the connected accounts, data exchanged, credential owner, business rule owner and person who can pause the automation. Use the least access the connection needs. A workflow that only creates tasks should not receive permission to delete projects or read unrelated customer records.

Define how a change becomes approved. A new form field, renamed pipeline stage or plan limit can break a stable workflow without changing its visible diagram. Record dependencies and review triggers beside the rules. The business owner should be able to explain the intended outcome; the technical owner should be able to explain monitoring, credentials and rollback. Both are needed before activation.

Make a clear ready, redesign or keep-manual decision

Choose “ready for a controlled pilot” only when the normal path is stable, inputs can be validated, exceptions have an owner and the result can be checked. Choose “redesign first” when repeated manual work comes from unclear responsibilities or incompatible records. Choose “keep manual” when judgement is central, volume is low or supported system access would create more risk than the saved effort warrants.

• Run sample records through the documented rules and compare two reviewers’ expected outcomes.
• Confirm supported authentication, API or webhook behavior, rate limits and plan availability in current vendor documentation.
• Test duplicate, late, corrected, missing and out-of-order inputs on isolated sample data.
• Assign an exception queue, response expectation, pause control and manual continuation procedure.
• Define evidence for a correct business outcome and a reconciliation count that exposes omissions or duplicates.
• Pilot a bounded segment, review exceptions and update the process map before expanding scope.