Whether you can automate a process reliably depends mainly on one question: can you describe the desired behaviour without ambiguity? The number of steps or exceptions matters less. A process with two hundred clear rules can be automated very well; a five-step process that needs interpretation may not. In addition, the practical conditions must be right: reliable data, access to the systems, good error handling, maintenance and enough volume.
Rules versus complexity
Many steps, exceptions and systems do take more time to build and test. But whether software can do the work reliably depends on something else: software follows rules precisely, but it is poor at guessing. So the question is: can someone explain what must happen in every situation, so that two colleagues handle the same case in the same way? Two processes from the same company show the difference.
| Characteristic | Process A: order confirmations | Process B: feasibility |
|---|---|---|
| Steps and exceptions | Many | Few |
| Can every decision be described? | Yes, as a condition with a fixed outcome | No, the core decision needs expertise and interpretation |
| What does a person do after automation? | Only cases where data is missing or an agreed limit is exceeded | The assessment itself |
| What can be automated? | The whole process, from start to finish | The work before and after the assessment |
Process A is more complicated and yet easier to automate. Many administrative processes in a manufacturing company resemble it: order entry, purchase invoices, bills of materials from the PDM system (the system for product data) to the ERP. With clear rules, such processes often run fully automatically. Worked-out examples are in 12 examples of work companies can automate.
And artificial intelligence (AI)? AI software can help to read a PDF or a free-form email, but it does not make a vague rule reliable. In its own documentation on AI agents, UiPath writes that tasks with high accuracy requirements, or with legal, financial or regulatory constraints, should continue to rely on deterministic automation: software that follows fixed rules and does the same thing with the same input.
How to capture a process in rules
The rules you write down later become the brief for the build and the list of test cases. Work in these steps.
- Understand what happens, and why. Follow real cases with the employee who does the work now. At each step, ask why they do it. The why often gives the real rule: "I check the delivery date" becomes "I check whether the material is there before the production order starts".
- Write each decision as a condition. Use the form "if … then …" and make vague words exact. "I accept a small price difference" becomes "if the price differs by at most 2 per cent, then I accept it". Words such as "usually" or "you can tell" are questions that still need an answer.
- Record the exceptions as rules too. Collect the exceptions of the past months, for example from the purchasing mailbox. Give each exception a rule: how does the software recognise it, and what does the software do then? End with one fixed rule: if no rule applies, the software stops and reports the case.
- Mark where a person judges. If asking why gives no unambiguous answer, mark that step. Check whether it really is a judgement, or a rule that was never spoken out loud. The latter is common.
- Test the rules on real cases. Let a colleague who does not know the work handle recent cases with only the rules. If they reach a different outcome from the buyer, that rule is not yet unambiguous.
For process A, part of the result looks like this. Such a table is called a decision table: each row is one condition with one action. The review queue in the table is the list of cases that an employee reviews.
| Check | If | Then the software | Person needed? |
|---|---|---|---|
| Purchase order | The order number is not in the ERP | Changes nothing in the ERP; the case goes to the review queue with the message "unknown order" | Yes, data is missing |
| Item | The supplier uses its own item number, which is in the cross-reference table | Converts it to the company's own item number and continues the checks | No |
| Quantity | The quantity is in a different unit, for example per box | Converts it with the unit from the item master and then compares | No |
| Price | The difference is at most 2 per cent | Accepts it and updates the price in the purchase order | No |
| Price | The difference is more than 2 per cent | Sends it to the review queue, with both prices side by side | Yes, the limit is exceeded |
| Delivery date | Later than requested, but before the required date of the production order | Accepts it and updates the expected date | No |
| Delivery date | After the required date of the production order | Updates the date and sends the process planner a notification | No, the process planner gets a signal |
| Other | No rule applies | Stops, changes nothing in the ERP, sends it to the review queue | Yes |
Assumptions: the 2 per cent limit is an example, purchasing agrees the real limit, and the cross-reference table and the required date are already in the ERP. The software processes every confirmation that passes all checks without an employee having to be present. The run stays traceable through a log. A person only gets involved when data is missing or a limit is exceeded: that is error handling, not a judgement halfway through the process.
Excel or Word is enough for such a table, as long as each row has one unambiguous condition and one action. There is also an international standard for it, DMN (Decision Model and Notation) from the Object Management Group (OMG). According to the OMG, DMN records business rules in unambiguous decision tables that are also readable for the people in the business who set the rules.
When a person must decide halfway
In process B, the engineer's judgement is the core. You do not automate that judgement, but you do automate the work around it. Before the decision, software can register the request, check whether the drawing and specifications are complete, and look up comparable earlier orders. After the decision, it records the outcome in the ERP and replies to the customer. The engineer gets a prepared task and only has to assess it.
Platforms support this: in UiPath Action Center (the part where an employee handles tasks), an automation waits for input from an employee and then continues by itself. Such a human step is a choice where the process calls for it, not a fixed part of every automation. How to set it up is explained in automating with a human decision halfway.
Beyond rules: what else decides reliability
Clear rules are the basis, but they are not enough. Five other points decide whether an automation runs reliably in practice.
- The quality of the data. A correct rule with wrong data gives a wrong result. If a supplier is in the ERP twice or the unit in the item master is wrong, things go wrong without the rule being wrong. Clean up such master data (fixed data about customers, suppliers and items) before you automate.
- Access to the systems. The software must be able to read and write data: through an integration (API, a fixed entry point that lets software talk to other software), an import function or the screens, as a software robot (RPA, software that takes over an employee's actions on screen) does. The pros and cons of each route are in RPA or API integration: which is the best choice? The software also needs its own account with only the permissions it uses, and with its login details in secure storage instead of in a script.
- Error handling. Keep two kinds of errors apart. If data is missing or incorrect, trying again does not help. If a system does not respond, it sometimes does. UiPath makes a similar distinction and by default does not retry errors caused by the data. A good automation stops rather than guesses, leaves nothing half-finished in the ERP and records every case.
- Maintenance. Rules change: a new supplier, a different price limit. Screens change after an update. Someone in the department owns the decision table and reports changes. What that costs is explained in what maintaining a software robot costs.
- Volume. A process with perfect rules that occurs twice a month rarely earns back the build and the maintenance. Calculate it with when automation pays off for a small business and what it costs to automate a business process.
Even if all of this is right, nobody can honestly promise that nothing will ever go wrong: a supplier changes its PDF, a system is unavailable for a morning. A reliable automation does not prevent every error, but it notices errors, stops in time and reports them to the right person.
Automate directly, adjust first or do not automate
There is no fixed step-by-step plan for every process. If a process already works well and predictably, record the rules, test them and automate, without a long preliminary project. Sometimes a small change is enough: if the price limit now depends on the buyer who opens the confirmation, one agreed limit solves that. And sometimes the best answer is to improve the process, without automation.
| Approach | Fits when | Strong in | Limitations |
|---|---|---|---|
| Automate directly | The rules are clear and the process already works well | Quick result; the decision table is the specification straight away | Testing, monitoring and maintenance are still needed |
| A small change first | One or two decisions are still vague, or a cross-reference table is missing | Removes the ambiguity at low cost | Needs agreements with colleagues, sometimes with suppliers |
| Automate around a human decision | The core of the process is a judgement | Takes away the preparation and processing work | The lead time depends on the availability of the reviewer |
| Improve without automation | The volume is low, or the process or system will change soon | No costs for build and maintenance | The manual work remains |
When the last row is the best answer is explained in when it is better not to automate a process.
Self-check: four questions
Answer these questions for one specific process. The same four questions appear briefly on the services page.
- Can you explain what must happen, including the exceptions? Would a colleague with only your explanation handle the same case in the same way?
- Does the work come back often enough? Daily or weekly, in a quantity you can name?
- Is the data digital and reliable? Does the input arrive as a file, form or system export, and is the master data correct?
- Can an automation reach the systems? Through an integration, an import function or the screens, with its own account?
Four times yes: the process is a good candidate. With a no on question 1, first write down the rules as described above, or mark the step where a person judges. With a no on question 2, it probably does not pay off. With a no on question 3 or 4, solve that point first: clean up the master data, agree a fixed submission format or ask the system's supplier which integration is available.
Question 1 weighs most for reliability, question 2 for the return. Outside help makes sense if the rules are in the heads of people who do not agree with each other, if nobody has time to follow cases, or if you are not sure whether a step is a judgement or an unspoken rule. A process analysis records the rules and the exceptions and ends with advice. That advice can also be: do not automate.
Conclusion
Do not ask how complicated your process is, but whether you can explain it. An extensive process with clear rules can often be automated from start to finish. With a short process that has a judgement in the middle, you automate the work around that decision. Start with one decision table for one process: it shows what can be automatic, where an agreement is still needed and where a person decides.