Sales approvals in Teams with Power Automate: quotes, discounts, and credit
In 60 seconds: Trigger the workflow from a real change in the CRM or ERP, create a unique ID, and evaluate a versioned policy. Power Automate routes the exception and Teams presents the decision; neither replaces the system of record. The card should show the amount, currency, requested term, breached rule, commercial effect, owner, and expiry. A rejection needs a reason. Recheck that the quote has not changed before execution. Write the decision, approver, policy version, and execution result back to the CRM or ERP. Start with one route for one week and measure decision time, exceptions, and manual corrections.
A sales approval often fails before its connector does. It fails when nobody knows which quote version was approved, when a manager replies “go ahead” in chat, or when a valid decision never reaches the system that releases the order.
The goal is not to digitize the word “yes.” It is to build a controlled transition between a sales request and an action in the system of record. Teams can make human intervention convenient. Power Automate can coordinate the path. Policy and evidence need a more durable home.
The complete lifecycle, with no hidden jumps
Consider a quote with an out-of-policy discount. The useful workflow has five stages:
- Request. The CRM creates an immutable request for one quote version and assigns a correlation ID.
- Routing. A rule evaluates amount, currency, discount, margin, credit risk, region, and required role. The thresholds come from company policy, not from the automation.
- Decision. An authorized person sees the context in Teams and chooses approve, reject, or request information. The response expires and remains bound to that version.
- Write-back. The flow records the decision and, when permitted, executes the allowed CRM or ERP change after validating the data again.
- Notification. The requester, sales owner, and exception owner receive the outcome or failure with a link to the official record.
Do not post the card first and “fill in the record later.” Create the pending record before sending a notification. If Teams is unavailable or a run is interrupted, the case remains recoverable instead of becoming an orphaned conversation.
A minimal state model can be pending → approved/rejected/expired → applied/failed. “Approved” and “applied” are different states: a valid human decision does not prove that the ERP accepted the update.
Give each component one clear job
| Component | Responsibility | What it should not decide |
|---|---|---|
| CRM or ERP | Current quote, customer, terms, status, and final evidence | How the card is presented |
| Business rule | Thresholds, hierarchy, segregation, exceptions, and validity | AI-generated free text |
| Power Automate | Trigger, query, route, wait, revalidate, write, and handle failures | Commercial policy improvised in opaque branches |
| Teams | Present context and capture an authenticated response | Be the only copy of the decision |
| Copilot | Draft a summary from permitted fields | Approve, change amounts, or choose its own authority level |
A discount rule should be readable and versioned. Depending on the architecture, it can live in a managed table, Dataverse configuration, or the commercial system. Avoid burying it in a prompt or repeating it across ten flow conditions.
Power Automate fits when the connectors, volume, and state complexity are manageable. If the logic expands, several automations share an API, or resuming work needs tighter control, revisit when to use Power Automate, a connector, or custom development.
The card: the minimum context for a sound decision
A card should not copy the customer’s entire record. It should show the difference an approver needs to evaluate:
- request ID and link to the official record
- customer or account, without unnecessary personal data
- transaction type: quote, discount, credit, or payment term
- amount and currency, with a comparable base if policy requires it
- standard term and requested term
- the rule or threshold that triggered the exception
- margin, exposure, or other relevant effect calculated by the responsible system
- requester, sales owner, and required approver
- expiry date and time with a time zone
- quote version and policy version
Microsoft supports responding to approvals from a Teams card, Outlook, or the Power Automate action center. When the process needs a custom interface, Power Automate can also post an adaptive card and wait for a response. Test the card in the clients the team actually uses; a layout that works on desktop may need simplifying on mobile.
Use unambiguous actions: Approve, Reject, and Request information. A rejection should require a short reason, structured where practical. “Request information” does not preserve the prior approval: it returns the case to the requester, records the question, and requires a new version if the terms change.
Close or refresh the card after a response. Two concurrent clicks must not produce two executions: the first valid state transition wins, and later attempts receive the current status.
Timeouts and escalation without immortal runs
Treat the deadline as operating policy, not as a connector detail. The pending record stores expires_at, current approver, and escalation level. A scheduled flow can find expired cases, update their state, and create the next task according to the agreed matrix.
Escalation should mean more than sending extra reminders. Answer these questions:
- is the request delegated to someone with equivalent authority, or escalated to a higher level?
- does an approver’s absence pause the transaction or activate a recorded substitute?
- is an expired case rejected, cancelled, or returned to the requester?
- which channel receives an alert when the connector fails?
Microsoft recommends storing the approval in Dataverse when a flow might run for more than 30 days. For long-running processes, separate “create and notify” from “resume and execute.” Pending state survives the run, and a response is processed against the current record.
Before the pilot, verify connector licensing, the environment where approvals are created, DLP policies, Teams Workflows availability, the supported adaptive card version, and history retention in the actual tenant. These are deployment conditions, not capabilities to assume from a guide.
What must not live only in chat
The system of record needs enough evidence to reconstruct a case without opening Teams:
- request ID and affected commercial record
- version or hash of the approved quote
- values before and after the decision
- policy, rule, and approval route applied
- requester and approver identity and role
- response, reason, and timestamps
- write-back result, transaction ID, and normalized error
- attempts, escalations, and relationship to any superseded request
Store references and relevant fields; do not duplicate secrets, full conversations, or personal data the control does not need. Retention and access should follow company policy.
Teams can retain a convenient view. It should not be the sole evidence. Someone without access to the channel should be able to audit the authorized CRM, ERP, Dataverse, or other company-defined record.
Controls before releasing a transaction
Authority. Resolve approvers from managed roles or groups. Do not treat an address supplied by the requester as proof of authority. Record who held the role when the response was submitted.
Segregation of duties. A person requesting an exception should not approve it when policy requires separation. For credit or sensitive terms, approval and application may use different identities. The flow account receives only the permissions it needs.
Revalidation. Immediately before writing, compare version, amount, currency, discount, status, and required approver. If a material field changed, invalidate the response and create a new request. Approval of an old snapshot does not authorize a new quote.
Idempotency and replay. A unique key prevents the same decision from being applied twice. A retry repeats an operation that did not confirm its result; replay reconstructs a case from saved evidence. Both must respect current state and append a new audit event. Never resend every failed approval through one unscoped global button.
Operations. Assign an owner to the failure queue, provide a way to pause new requests, and document a manual path for keeping sales moving. Human approval is only the approved-execution level; it needs permissions, limits, logs, and recovery around it.
A one-week pilot
Choose one route, such as nonstandard discounts for one business unit. Do not combine quotes, credit, and extensions in the first test.
Before starting: record how decisions happen today, which fields are required, who has authority, and how many cases remain unresolved. Freeze the pilot matrix and prepare tests for duplicates, missing data, rejection, expiry, a later edit, and write-back failure.
During the week: review the queue daily and track the following without inventing a target:
- time from a valid request to a decision, separate from waiting for missing information
- requests by route, approver, and outcome
- exceptions caused by data, permissions, timeouts, concurrency, or connectors
- rejections and information requests by reason
- manual CRM or ERP rewrites and their cause
- approved decisions that were not successfully applied
- retries and replays by operation
At the end: compare the results with the baseline and inspect individual cases. A lower median does not compensate for poorly recorded decisions. Decide whether to repair source data, adjust a rule, improve the card, or move one component to custom development before expanding scope.
If the approval sits inside a channel-based follow-up process, connect it to the sales pattern across WhatsApp and Teams: the CRM preserves the truth, Teams handles the exception, and the external channel acts only after a valid decision.
Kiia can map the authority matrix, build one pilot route, and leave the evidence in the system that already governs the operation. The goal is to move a commercial decision forward without making it invisible.
Frequently asked questions
Can Teams be the system of record for a sales approval?
No. Teams can display the request and capture a response, but the quote, applied policy, decision, and execution result should persist in the CRM, ERP, or another controlled record.
Should every quote require an approval?
Not necessarily. Cases that meet an explicit policy can follow the standard route. Human review is more useful for exceptions involving discounts, credit, margin, payment terms, or authority.
What should Copilot do inside the workflow?
It can draft a summary from authorized fields. It should not decide limits, select the approver, change amounts, or write the final approval; those actions belong to deterministic rules and authorized people.
From insight to action
Want to turn this into an agent that works for your team?
Tell us which process you want to improve. In a free call, we will identify the first workflow worth building.