AI automation combines model-generated interpretation or prediction with a workflow that acts on the result. Choose the workflow first, then decide where AI is useful and where a fixed rule or explicit approval is more appropriate. A model producing an answer does not establish that the answer is correct or that a business action is authorised.
Microsoft’s AI Builder documents prebuilt and custom models within Power Apps and Power Automate. Its approvals documentation describes separate decision steps. These are useful building blocks for explaining the difference between an AI result, a workflow transition and an approval. They are not measured accuracy evidence for your business data. AI Builder overview, Power Automate approvals.
Which work should you automate first?
Choose a recurring task with identifiable inputs, a useful output and a named operating owner. Describe how staff currently decide the result and what happens when information is incomplete. A workflow that nobody can explain clearly is difficult to evaluate after automation.
A hypothetical document-intake process illustrates the distinction. AI might suggest a document category or extract candidate fields. Fixed rules might check whether required fields are present. An approval step might authorise the next action. Keeping those layers separate makes it possible to investigate an error without treating every problem as a model failure.
Do not start with a promise to replace an entire department. Select a bounded task whose result can be checked against meaningful examples. Include difficult and incomplete inputs in the evaluation, not only clean examples selected to make the demonstration succeed.
How do rules, AI and approval differ?
| Component | Suitable question | Evidence to retain |
|---|---|---|
| Fixed rule | Does the input meet a defined condition? | Rule version and tested examples |
| AI model | What interpretation or prediction does the model propose? | Input reference, model configuration and observed result |
| Approval step | Is the proposed action authorised? | Decision, approver and action scope |
| Business action | What changed in the target system? | Resulting record and external effect |
The table is an editorial architecture aid. It does not assert that a particular platform automatically records every field. Require the actual implementation to show how each decision and effect can be investigated.
What do prebuilt and custom models change?
Microsoft describes using either a prebuilt model for common scenarios or a custom model tailored to business needs. The custom-model workflow includes selecting business-specific data, tailoring and training. That documentation establishes a capability, not a guarantee that the resulting model meets your acceptance criteria.
Evaluate the model using representative inputs kept separate from the examples used to configure it where appropriate. Record incorrect results and cases that should be routed for clarification. Do not convert an attractive demonstration into a percentage accuracy claim without a defined dataset and measured result.
Also check feature release status. Microsoft warns that some AI Builder features remain in preview and are not intended for production use. It notes that availability can differ by location. Confirm the relevant feature and environment rather than assuming a general platform account includes every capability. AI Builder scope and release status.
How should approval be configured?
Approval models represent different business decisions. Microsoft’s documentation distinguishes everyone-must-approve, first-to-respond, custom-response and sequential patterns. These choices should follow the business’s authority structure rather than whichever template is easiest to select.
For example, a first-response approval is not equivalent to agreement from every required role. The everyone-must-approve pattern has its own rejection behaviour. A sequential pattern introduces an order of decisions. Define the intended result and test both approval and rejection before enabling downstream actions.
Avoid a workflow that treats a missing response as implicit approval unless the business has explicitly adopted and documented that rule. This article does not invent a deadline or escalation interval. The operator needs a visible pending state and a route for resolving a stalled request.
An original automation contract
Write a short contract for each automated task:
Trigger: the event that starts work and how repeated events are recognised.
Input: the minimum information required and where it comes from.
AI boundary: the interpretation the model may propose and what it must not decide.
Rule boundary: conditions checked deterministically before proceeding.
Approval boundary: authorised decision-maker and the exact action being approved.
Action: target system, allowed change and expected evidence.
Failure: what remains pending when a model, connector or target system fails.
Recovery: how work is retried or resumed without duplicating the action.
Stop control: who can disable the automation and inspect outstanding work.
Acceptance: real test cases, actual results and unresolved defects.
This contract is an original requirements artefact. It is designed to make a workflow understandable and reversible where possible, not to certify an implementation as safe or correct.
What should happen when part of the workflow fails?
Distinguish a failed model call from an action whose result is unknown. If a target system accepted a change but the confirmation was lost, blindly repeating the whole workflow can create a duplicate. Keep the target record reference and inspect the existing result before retrying an external action.
Give operators an exception queue containing the task reference, last completed step and next legitimate action. Do not fill it with unexplained technical messages. Staff should be able to tell whether the customer needs clarification, an approval is missing or a connector needs investigation.
Test an incomplete input, an incorrect model suggestion, a rejection, a repeated trigger and an interrupted downstream action. Record what actually happened. Those cases produce more useful evidence than a statement that the automation “ran successfully” once.
What belongs in the business decision?
Compare the automated route with a simpler rule-based process and the current staff-led workflow. Consider the work needed to maintain source information, investigate exceptions and update integrations. Automation can move work rather than remove it, especially when the process lacks a clear owner.
Discuss a bounded workflow through Spout’s web development service or start an enquiry with the automation contract and representative examples stripped of unnecessary personal data.
For an approval request, preserve the proposed action as it appeared when the decision was made. If the underlying record changes afterwards, establish whether a new decision is required. An approval attached only to a mutable record can otherwise become difficult to interpret during investigation.
If the automated task answers customer conversations, include the separate WhatsApp Business message and handover requirements.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.