Every organisation has processes that run on reminders: someone checks a list, chases a signature, forwards an email and hopes nothing falls through. You can automate business processes without code, but only if the automation is something the team can read, trust and change. This article covers which processes to automate first, how to express them as rules, and how to keep them auditable.
Why so many processes still run on reminders
Automation projects usually stall for one of two reasons. Either the work goes to a development queue, where a simple approval flow competes with larger priorities, or someone builds it with a patchwork of scripts, mail rules and spreadsheet macros that only they understand. The first is slow; the second is fragile.
There is also a quieter problem. The process itself is often not written down. Everyone knows roughly what happens, but nobody could say exactly when a request should escalate, or who approves when the usual approver is away. Automating a process forces those answers, which is useful in itself.
Start with a process map, not a tool
Before you build anything, write the process out as steps and decisions. For each step, note:
- The trigger. What starts it: a new record, a change of status, a date, or a message from another system.
- The actor. Who acts, by role rather than by name.
- The condition. Any rule that decides the path, such as an amount above a threshold or a missing document.
- The outcome. What changes when the step is done.
- The time limit. How long the step may wait before someone should be told.
A business analyst can usually produce this in a short working session with the people who do the work. The map becomes the specification, and it stays useful as documentation afterwards.
Four patterns that cover most business automation
Most operational processes are built from a small set of patterns. Recognising them makes the build much quicker.
Approvals. A record moves to a reviewer, who approves, rejects or returns it with a comment. Variations include multi-level approvals based on value, and parallel approvals where several people must sign off. The rule should say who approves, in what order, and what happens on rejection.
Escalations. When something waits too long, a rule notices and acts: it reminds the owner, reassigns the work, or alerts a manager. Escalations replace the person whose job was to check the list every morning.
Scheduled jobs. Some work is driven by the calendar rather than by an event: a monthly review, a contract approaching renewal, a certificate about to lapse. A scheduled rule finds the records that need attention and creates the tasks.
Notifications. People are told when something needs them, and only then. Good notifications carry enough context to act and link straight to the record.
Express automation as rules people can read
In Vibe, workflows are generated along with the data model and screens when you describe the application, and you refine them by pointing and clicking or in plain language. AI helps while you build by proposing rules from your description and explaining what a change will do before you make it. The FAQ on how AI helps while building has more detail.
A rule written in plain terms, such as "purchase requests over the department limit go to the finance lead after the line manager approves", can be checked by the people who own the process. That matters more than it sounds. When automation is hidden in a script, errors surface as mysterious behaviour months later. When it is a visible rule, someone notices on the first day.
A few principles help:
- Keep each rule to one decision.
- Name rules after what they do, not after who asked for them.
- Give every waiting state a time limit and an escalation.
- Decide what happens when the expected person is unavailable.
Keep every automated step auditable
Automation moves decisions out of inboxes, which means the evidence has to live somewhere else. Vibe applications keep an audit log of data changes and administrative actions, so you can see who approved a request, when, and what it looked like at the time. Role-based access applies to every entity and action, so only the right people can approve, override or change the rules themselves.
The rules are also versioned. Every change to the application is recorded and reversible, so if a new escalation rule starts sending too many alerts, you can roll it back in one step and investigate calmly. For audit and compliance teams, that history answers the question "what were the rules on that date?" See audit trails and compliance for business apps for how this supports a review.
Automating across systems and teams
Few processes live entirely inside one application. An approved order may need to reach the finance system; a new starter recorded by HR may need accounts created elsewhere. Vibe applications connect over REST, webhooks and events and expose their own APIs, so a rule can call out to another system, or another system can start a workflow. See whether Vibe can connect to your other systems.
When a process crosses several teams, such as sales handing to operations handing to finance, it often works better as one application with a clear state for each hand-off than as a chain of emails. Connected workflows across sales, ops and finance looks at that in detail.
A checklist before you switch it on, and where to start
- Is the process written down, with triggers, actors, conditions and time limits?
- Does every waiting state have an escalation?
- Have the people who do the work read the rules and agreed them?
- Are permissions set so only the right roles can approve or change rules?
- Have you run a handful of real cases through it, including the awkward ones?
- Is there an owner who will review the rules when the process changes?
Run the automated process alongside the old one for a short period if the stakes are high, then retire the reminders.
As for where to start, the best first candidate is the one that generates the most "has anyone approved this yet?" messages. Describe it, and you can have a working application with its approvals and escalations in hours. The product overview shows what Vibe generates; if you would rather hand the build over, the services team builds custom applications. Or bring the process to the design partner programme and tell us about it.