Our fictional business starts with a simple automation: when an inquiry arrives, create a CRM record and notify the right person.
Then it adds territory routing, an approval step, a document request, a payment check and a reminder that must stop if somebody replies. The diagram is now beginning to resemble public transport for a city nobody has visited.
That doesn’t automatically mean the visual automation tool is wrong. It means the business needs to examine how the workflow remembers progress, handles exceptions and changes over time.
A custom service may be appropriate for some of that work. The decision should follow the operating requirements, rather than the number of colorful boxes.
Follow one case after the ordinary path breaks
Can the workflow explain where the case is waiting?
In our sample, a customer submits a document while the approval step is still pending. Staff need to see both facts without the workflow losing its place.
Look for durable state: a record of progress that survives interruptions and can be inspected later. That might be provided by the automation platform, another business system or a custom component.
The key question is whether the case can be understood without reading the execution history of several disconnected runs. A completed step and a completed business case are different things.
If staff already maintain a spreadsheet to remember which branch a case took, that is evidence to investigate. It may reveal a missing operational view rather than a reason to rewrite everything.
Our integrations and AI team builds connections that keep records in step.
Can a person recover one failed handoff?
Suppose the CRM update succeeded but the notification failed. Replaying the whole workflow may create another CRM record unless the integration handles duplicates.
The right recovery should target the unfinished work and recognize what has already happened. Webhook delivery adds its own concerns around retries, authenticity and visibility, as Svix’s engineering discussion explains.3
Check the actual platform’s capabilities. Some visual tools provide substantial history, retry and state features. Others may require additional design for the particular task.
What matters is the complete recovery path. A button labeled Retry is encouraging, but we still need to know what it will repeat.
Can the business change the rule without rewriting history?
Our fictional territory policy changes while some cases are halfway through approval. Which rule should those cases follow?
Versioned workflow rules can make that decision explicit. Record the relevant version and define whether existing cases continue under it or move through a controlled transition.
Without that policy, a mid-process case may be evaluated under a mixture of old and new assumptions. The diagram can remain visually immaculate while the business process starts time traveling.
CodeOpinion’s workflow writing provides useful background for making these transitions explicit and recoverable.1 The implementation can be graphical or code-based; the need for understandable behavior remains.
Related read: That 300-line function is trying to run the whole business.
Keep the parts that still do a clear job
A useful next step may be to retain the visual automation for straightforward connections and move the central case state into a service designed around the business process.
That service could own the rules, permissions and durable progress. The surrounding automation could still handle well-bounded notifications or routine exchanges.
A custom service introduces responsibilities of its own: deployment, maintenance, monitoring and support. Include those in the decision rather than presenting code as the place complexity goes to disappear.
I would choose one troublesome case and trace it through the current system with the people responsible for resolving it. Identify what they cannot see, which action they cannot safely repeat and which rule they cannot explain.
Then compare the smallest changes that address those gaps. Better configuration, a clearer operational view or a bounded custom component may be enough.
The goal is a workflow someone can operate with confidence. If the diagram becomes simpler as a result, lovely. If it remains large but understandable and dependable, that can be a good result too.