Workflow Automation
Automating file approvals in Microsoft Teams
I am Priya Shah. File approvals in Teams work best when you admit the file lives in a SharePoint document library, the approval lives in a flow or built-in approval process, Teams is the notification surface, and a Published style column flips only after approval succeeds. This is the pattern I deploy for policy PDFs and similar controlled documents. Light touch on sensitivity labels at the end, not a security product pitch. I am not a Microsoft partner.
If you came here hoping for a get-rich automation fantasy or a fake countdown to compliance doom, wrong essay. This is plumbing.
Start in the document library, not in chat
Upload the draft policy PDF to a library with content types or columns you control. Minimum columns I like: Title, Status, Owner, ReviewBy, Published (yes or no), and Approver. Status might be Draft, In review, Approved, Rejected. Published stays No until the happy path finishes.
Why not approve from a random channel upload? Because channel folders inherit team chat habits. People overwrite without ceremony. Libraries with required columns force a little discipline before the flow even runs.
Name the file stably. TravelPolicy.pdf beats TravelPolicy_March_FINAL_v3.pdf. Versions handle history. The approval flow should target the item ID, not a brittle filename pattern.
The approval flow shape
Trigger on Status changing to In review, or on a manual button the author clicks. Create an approval that assigns the Approver column user, include link to the document, include a short summary from the Author. Wait for response.
If approved, set Status to Approved, set Published to Yes, maybe set a PublishedDate. If rejected, set Status to Rejected, Published stays No, write rejection comments into a Comments column, notify the owner.
Only flip Published after approval. Authors sometimes want Published true while review is pending so "people can find it." That defeats the column. Downstream views should filter Published equals Yes for the official reader audience. Drafts stay visible to owners and approvers through a different view.
I keep the flow identity least privileged: permission to update that library and to send approvals, not tenant admin.
Teams as the notification surface
Approvers live in Teams. Send the approval notification into Teams so they can act without hunting email. Post a channel update when a policy is published, with the library link, not a second uploaded copy.
Channel choice matters. A governance channel for publish notices is better than spamming a social channel. If the policy applies to one department, notify that department team. Wide blast trains people to ignore you.
Do not use an incoming webhook as the approval mechanism. Approvals need authenticated actors and an audit trail. Webhooks announce. They do not approve.
Concrete example: HR loads TravelPolicy.pdf as Draft. Owner sets Approver to Maya. Owner sets Status to In review. Maya gets an approval in Teams, opens the PDF, approves. Flow sets Approved and Published Yes. The HR governance channel gets one message: Travel Policy published, link attached. Staff views show the new PDF because they filter on Published.
Reader experience after publish
Build a view named Official policies: Published equals Yes, sorted by Title. Pin that view link in a Teams tab using SharePoint library view if you want, or a page that embeds the view. Readers should not wade through drafts.
When a new version needs review, set Published to No on the item or use major or minor versioning thoughtfully. Some orgs keep the last approved major version visible while a minor draft is in progress. That is advanced library configuration. Agree on it before the first crisis. Document the rule in the library description.
If someone asks for email plus Teams plus SMS for the same approval, push back. One primary approval channel. Extra pings are optional reminders, not parallel decisions.
Rejection and revision loops
Rejected documents should be easy to find for owners. A view Status equals Rejected saves time. The owner edits, sets Status back to In review, and a new approval starts. Store each approval outcome in comments or a related history list if you need stronger audit.
Avoid deleting rejected files to "clean up." History matters when someone asks what was refused last quarter.
Timeouts: if Maya does not respond in five business days, escalate to a backup approver or notify the owner. Silent pending approvals are how unofficial PDFs circulate in side channels.
Sensitivity labels, lightly
Sensitivity labels can mark a document as Internal or Confidential and travel with the file depending on your tenant setup. For policy PDFs, a label that matches the audience is often enough: internal staff policies labeled accordingly. I mention labels as a classification hint that works alongside your Published column, not as a substitute for approval.
Do not confuse a label with an approval stamp. A confidential draft can still be wrong. Approval answers correctness and authorization to publish. Labels answer handling expectations. Use both when your organization already standardized labels. If you do not have a label program, do not invent one inside a single flow.
Failure modes I watch for
- Published flipped by a manual edit bypassing the flow
- Approver column empty and the flow stalls
- Channel notification linking to a sharing link that guests should not have
- Second copy uploaded to chat after publish, restarting drift
- Flow running as a person who left the company
Mitigations: lock Published edits to the flow account if your platform allows, validate Approver before starting, use library permissions instead of wide anonymous links, educate authors that chat copies are not official, run the flow on a service identity with an owner alias.
Test with a dummy PolicyTest.pdf end to end in a pilot library. Then promote the pattern. Patterns beat one-off flows that only HR understands.
That is the approval story I trust. Library columns tell the truth. Flow enforces the gate. Teams notifies humans. Published flips last. Labels optional and humble. The policy PDF becomes findable without becoming chaotic, which is all most teams actually needed.
Expanding the policy PDF example because details are where flows die. TravelPolicy.pdf sits in Corporate Policies library. Content type Controlled Document requires Owner and Approver. Default Status is Draft. Author finishes edits, checks Version comment "adjusted meal caps," sets Status to In review. Flow reads Approver, starts approval with title "Approve TravelPolicy," body containing link and version number. Maya approves in Teams with comment "looks good for FY26." Flow writes Status Approved, Published Yes, PublishedDate today, appends approval comment to History. A Teams post in Policy Notices says "Travel Policy is published" with library deep link. A reader view filters Published equals Yes and shows TravelPolicy without drafts for DressCode still in review.
Next quarter HR uploads a revised binary as a new version of the same item, sets Published to No and Status to In review again. Readers either still see the last major approved version depending on your versioning settings, or temporarily lose the official view until re-approval. Decide that behavior deliberately. I prefer major versions for published states and minor for in-review edits when the library supports it, but only if authors understand check-in. If they do not, keep a simpler model: one visible official file, Published flag, and accept a short gap during review.
Parallel approvals: sometimes Legal and HR both must sign off. Use sequential approvals when order matters, parallel when it does not. Do not flip Published until all required approvals succeed. Partial approval with Published Yes is how half-reviewed policies escape.
Emergency edits happen. Build an emergency path that requires a break-glass group, posts a loud Teams notice, and still records who overrode. Do not pretend emergencies never happen. Do not make emergency the everyday path.
Reporting helps governance without nagging. A weekly digest listing items with Status In review older than seven days keeps queues moving. A monthly list of Published documents with ReviewBy in the past prompts refresh without fake urgency language. Just facts and links.
Training authors takes one short session: where to upload, which columns to fill, what Published means, why chat uploads are not official. Record it. Pin it. When someone bypasses the process, point to the recording instead of rewriting the flow in anger.
If your tenant already uses retention or records management, coordinate so approval does not fight a lock. I have seen a flow fail because an item became a record mid-review. Sequence the lifecycle: approve and publish, then declare record if required.
Ship the pattern in one library first. Clone only after two successful policy cycles. That patience is the difference between a trusted approval lane and a graveyard of half-migrated flows nobody owns.