An adaptive enterprise can change its processes without losing control of how work gets done. In software terms, that means workflows with clear rules, reusable integrations, visible ownership, and a way to revise and recover them.
AI-assisted coding makes it practical to explore custom automations by describing the intended behavior and iterating on an implementation. The important design work is deciding exactly what should happen, which system owns each fact, and who handles exceptions. A workflow that works once is a prototype; a useful operational workflow also survives interruptions and change.
Visual workflow, custom code, or a combination?
| Approach | Good fit | Tradeoff to examine |
|---|---|---|
| Visual automation | Standard connectors, routing rules, and approvals. | Connector limits, version history, export options, and per-run costs. |
| Custom code | Unusual transformations or precise behavior. | Hosting, tests, updates, and an accountable maintainer. |
| Combined | A visible business process with specialized steps. | Debugging across the workflow platform and the custom service. |
Try the hardest real case before selecting a platform. A connector that can create a record may not support the lookup needed to recover after a timeout. An attractive workflow diagram does not establish how the process behaves under failure.
Write a process contract first
Describe the trigger, required inputs, allowed transitions, completion condition, and exception owner. Separate business decisions from the mechanics of calling an API. Create an onboarding workflow
leaves too many decisions implicit; Reserve a laptop after an approved request, and record the reservation identifier
is testable.
- Identity: Give each request a stable identifier that follows it across systems.
- State: Store progress outside the memory of a running script.
- Authority: Decide which roles can request, approve, cancel, and retry.
- Completion: Define the business result, not merely a successful HTTP response.
- Recovery: Record how to continue or compensate after a partial failure.
Worked example: a laptop request
If the inventory service times out, look up the operation by its key before retrying. If it offers no reliable lookup or duplicate prevention, route that uncertain result to an operator. A local completed flag cannot settle whether a remote request succeeded.
If the employee's start is canceled after reservation, release that specific reservation according to the inventory system's rules. This illustrates a compensating transaction: a follow-up action addresses earlier work, and can itself require recovery. It is not necessarily a restoration of every system to its prior state.
Use AI assistance on bounded steps
Ask the assistant to produce the state table, sample inputs, and failure cases before code. Then implement one step using the actual connector or API documentation. Provide test credentials through the environment, rather than embedding them in a prompt or source file.
Design a laptop reservation workflow with explicit states and a persisted request ID. Approval must come from an authorized manager. Notification retries must not reserve more equipment. Model a timeout after the inventory service has accepted the request. Identify API guarantees we must verify, then propose tests before implementation.
Keep routine routing deterministic. If a model classifies free-text requests, treat its output as a suggestion constrained to allowed categories, and define what happens when the text is ambiguous. Text submitted by a requester should never become authority to bypass an approval.
Test, release, and measure the workflow
Exercise rejection, cancellation, duplicate submissions, a connector timeout, missing permissions, and a restart between steps. Verify that a user cannot approve their own request unless that is explicitly allowed. Inspect business records as well as logs: a green workflow status can conceal a missing reservation.
Version the rules and record which version each request uses. Decide whether in-flight requests finish under the old version or migrate to the new one. Begin with a small team and keep a manual recovery path available.
Useful measures include completion time, requests awaiting intervention, duplicate operations, and recovery time. Measure time saved against the effort of maintaining connectors and handling exceptions. Assign an owner for API changes, expired credentials, and process revisions.
When is an automation ready?
When someone other than its author can explain the states, find a failed request, and recover it using the documentation. Keep related integration details in an API integration guide and recurring execution rules in a job scheduling plan.