Stop Approvals Getting Lost in Email with Microsoft Teams
Summary
- Email approvals have no central status, log, or mechanism to route outcomes, so requests get buried and requesters often never learn decisions.
- Microsoft Teams provides native approval options, but enterprise governance gaps include a fragmented audit trail across Dataverse and Purview, rigid RBAC, and Graph API integration complexity.
- Structured Adaptive Cards with Approve/Reject actions let approvers decide inside Teams and route the result back to dependent workflows.
- A compliant approval process must keep an immutable, queryable audit log outside the Teams chat, capturing every step with timestamps and actor identity.
- Jinba Flow builds this for regulated enterprises with granular RBAC, over 100 pre-built integrations, and end-to-end audit logging.
Email-based approvals have a consistent failure pattern. A request lands in an inbox, gets buried under other messages, and the approver either misses it or acts on it without any record the requester can see. The requester has no view into where the request sits. If it is rejected, the reason is often locked inside a reply thread they cannot find.
The problem is structural rather than behavioural. Email was not built to track decisions. It has no status field, no central log, and no mechanism to route an outcome back to a dependent process.
Microsoft Teams is where most organisations already work. Routing approval requests there, as structured cards that capture the decision and feed results back into a workflow, solves the visibility and traceability gap simultaneously. Jinba is purpose-built to run that process with end-to-end audit logging, granular RBAC, and compliance controls.
Why Email Approvals Break Down
The specific costs are material. A centrally tracked approval process requires a single location for request status, decision history, and rejection comments. Email provides none of these reliably.
Requesters are frequently left without any notification when their submission is approved or rejected. The approver receives a prompt; the requester receives no notification. When rejection comments exist, they are buried in a reply chain that may have been forwarded, filtered, or lost. Tracking a portfolio of decisions, such as purchase approvals across a month, requires manually searching an inbox rather than querying a log.
The operational result is that approvers lose requests, requesters cannot find outcomes, and no one has a timestamped record of who decided what and when.
The Native Microsoft Teams Approach
Microsoft provides two routes for Teams-based approvals: the no-code Approvals app and the programmatic Microsoft Graph API.
The Approvals app centralises tracking, management, and auditing within the Teams interface. According to Microsoft's own documentation, it "reduces time and effort" and provides accountability through a consolidated view. That is an improvement over email.
But the native approach carries governance gaps that matter at enterprise scale.
Fragmented audit trail. Approval records are stored in Dataverse, not in the Teams chat. The first approval triggers provisioning of the Approval solution in the default Dataverse environment. Teams-level events are separately captured in Microsoft Purview, but audit logging must be explicitly enabled, and it only captures events from the point of enablement. There is also a known attribution gap: membership changes made via Entra ID or the Graph API are attributed to an existing team Owner, not the actual actor, requiring manual cross-referencing of logs.
Rigid RBAC. Users are automatically assigned to the Approvals User role upon their first approval assignment, and only team Owners can create approval templates. Teams Admin portal access is required for broader configuration, and many users operate without it.
Graph API complexity. The Microsoft Graph API provides programmatic control but its documentation, while extensive, leaves integration gaps that implementation teams must resolve independently before a workflow is production-ready.
Introducing Jinba: Microsoft Teams Workflow Automation with Full Governance
Jinba is an enterprise AI workflow builder that routes approval requests to Microsoft Teams as structured Adaptive Cards, captures the decision in-channel, and feeds the result back into the workflow, with every step logged in a single, immutable audit trail.
Its two products work together: Jinba Flow for building and configuring workflows, and Jinba App for executing them. The platform carries SOC 2 compliance, HIPAA and GDPR support, end-to-end encryption, SSO, and on-premise or private-cloud deployment options. RBAC is implemented at the organisational level through spaces, roles, and approval assignments, giving Teams Admins granular control without depending on the Approvals app's fixed role model. Over 100 pre-built integrations, including Microsoft Teams, SharePoint, Salesforce, Slack, and OpenAI, are available out of the box.
The result is microsoft teams workflow automation that is audited from trigger to outcome, without the governance gaps of the native approach.
Building a Teams Approval Workflow with Jinba
Step 1: Create the Jinba Flow
In Jinba Flow, create a new workflow and define the trigger: a form submission, a SharePoint list update, or an API call from an internal system. Set the RBAC scope to determine which roles can initiate, approve, and audit requests.
Step 2: Configure the Microsoft Teams Action
From Jinba's pre-built integration library, add the Microsoft Teams action. Authenticate using a delegated token with the ChannelMessage.Send scope. This follows the principle of least privilege: application-only scopes such as Teamwork.Migrate.All are intended for data migration, not live messaging, and should not be used here.
Step 3: Post an Adaptive Card to the Channel
Jinba posts the approval request to the target channel using the Microsoft Graph API:
POST /teams/{team-id}/channels/{channel-id}/messages
A successful request returns 201 Created. The request body is a chatMessage object. The body.content property is mandatory and accepts HTML. The Adaptive Card is attached via the attachments array:
{
"attachments": [
{
"contentType": "application/vnd.microsoft.card.adaptive",
"content": "<serialized AdaptiveCard JSON>"
}
]
}
The Teams messaging overview documents additional supported card types, including application/vnd.microsoft.card.announcement and application/vnd.microsoft.card.fluidEmbedCard for Loop components, but Adaptive Cards are the correct format for interactive approval actions.
Step 4: Craft the Adaptive Card
The card must include $schema, type, version, and a body array containing the request details. Approve and Reject actions are attached as Action.Submit buttons:
{
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.4",
"body": [
{
"type": "TextBlock",
"text": "Purchase Approval Request",
"weight": "Bolder",
"size": "Medium"
},
{
"type": "TextBlock",
"text": "Requester: Jane Smith | Amount: $4,200 | Vendor: Acme Corp",
"wrap": true
}
],
"actions": [
{
"type": "Action.Submit",
"title": "Approve",
"data": { "decision": "approved" }
},
{
"type": "Action.Submit",
"title": "Reject",
"data": { "decision": "rejected" }
}
]
}
The card appears directly in the channel. The approver sees the request details and acts without leaving Teams.
Step 5: Handle the Response and Close the Loop
When the approver clicks Approve or Reject, Jinba receives the submitted action data and routes the outcome back into the workflow. From that point, subsequent steps can run automatically:
- Notify the original requester in Teams with the decision and any comments
- Update the relevant SharePoint list or Dataverse record
- Trigger downstream tasks such as purchase order creation or access provisioning
- Send the decision to the Microsoft Graph Approvals app API if the organisation requires it as a system of record
The requester no longer needs to follow up with the approver for an update. The workflow closes the loop as soon as the decision is recorded.
Step 6: Review the Audit Log
Every step of the process (trigger, card delivery, approver action, outcome routing, downstream notifications) is captured in Jinba's audit log with timestamps and actor identity.
This is the critical structural difference from both email and the native Approvals app. Microsoft's own messaging guidelines explicitly state that the Graph API should only be used to send messages that people will read, not to store records. The audit trail must live outside the chat. Jinba's immutable log fulfils that requirement without requiring organisations to cross-reference Microsoft Purview with Dataverse exports.
The log is queryable by workflow, requester, approver, decision, and date range. Teams Admins can access it for compliance reviews without touching the Microsoft Purview interface.
From Email Approvals to Auditable Clarity
The gap between email approvals and a governed Teams-based process is primarily an audit and visibility problem. Requests are lost because no system tracks them. Requesters remain uninformed because no mechanism closes the loop. Rejection reasons disappear because the storage location is unstructured.
Jinba resolves each of these by treating the approval as a workflow event rather than a message. The card posts to the channel, the decision routes back into the process, and the log captures everything under RBAC controls that match the organisation's actual access structure, not the fixed role model of the native Approvals app.
For organisations running purchase approvals, access requests, content sign-offs, or any repeating decision process inside Microsoft Teams, this is the architecture that makes microsoft teams workflow automation both operable and auditable.
To see how Jinba handles this end to end, start at jinba.io.
Frequently Asked Questions
What are the main problems with email-based approval workflows?
Email approvals have no central status, no decision log, and no way to route outcomes back to a dependent process. Requests get buried in inboxes, approvers miss them, and requesters are left without notifications or rejection reasons. The problem is structural: email was not built to track decisions.
How can an organisation send approval requests to Microsoft Teams?
Organisations can send approval requests to Microsoft Teams using the native Approvals app, the Microsoft Graph API, or a workflow automation platform like Jinba. The most controlled approach is to post an Adaptive Card with Approve and Reject actions to a Teams channel and capture the decision in the workflow.
What is the native Microsoft Teams Approvals app?
The Microsoft Teams Approvals app is a no-code tool that centralises approval tracking, management, and auditing inside Teams. It is an improvement over email, but it has governance gaps at enterprise scale, including fragmented audit data and a fixed role model.
What are the limitations of Microsoft Teams Approvals for enterprise use?
The native Approvals app has three main gaps: a fragmented audit trail across Dataverse and Microsoft Purview, rigid RBAC where only team Owners can create templates, and Graph API complexity that leaves integration gaps for production workflows.
How do organisations create an approval workflow in Microsoft Teams with Adaptive Cards?
First, define a trigger in the workflow platform. Then add a Microsoft Teams action using a delegated token with the ChannelMessage.Send scope. Post a chatMessage to the team channel with an Adaptive Card attachment containing Action.Submit buttons for Approve and Reject. The platform then receives the submitted action and routes the result back into the workflow.
What is the correct Microsoft Graph API scope for sending approval messages to Teams?
The correct delegated scope is ChannelMessage.Send. Application-only scopes such as Teamwork.Migrate.All are intended for data migration, not live messaging, and should not be used for approval cards.
How are approval decisions captured and routed back to the requester?
When an approver clicks Approve or Reject on an Adaptive Card, the platform receives the submitted action data. It can then notify the requester, update a SharePoint list or Dataverse record, trigger a purchase order, or send the decision to another system of record.
How does Jinba provide an immutable audit trail for Teams approvals?
Jinba records every step of the approval workflow (trigger, card delivery, approver action, outcome routing, and downstream notifications) with timestamps and actor identity in a single queryable log. This audit trail lives outside the Teams chat, which aligns with Microsoft's guidance that the Graph API should not be used to store records.
What RBAC controls does Jinba offer for approval workflows?
Jinba implements RBAC at the organisational level through spaces, roles, and approval assignments. Teams Admins can control who can initiate, approve, and audit requests without depending on the fixed role model of the native Teams Approvals app.
Can Jinba integrate with tools like SharePoint, Salesforce, and Slack?
Yes, Jinba includes over 100 pre-built integrations, including Microsoft Teams, SharePoint, Salesforce, Slack, and OpenAI. This lets approval workflows connect to the systems where request data and downstream actions already live.