Dùng Power Automate cho quy trình approval nội bộ nên bắt đầu từ đâu?
Trong nhiều doanh nghiệp, quy trình phê duyệt vẫn được xử lý bằng email, chat hoặc file Excel.
Nhân viên gửi yêu cầu.
Manager trả lời “Approved”.
Finance kiểm tra lại.
Admin cập nhật trạng thái.
Sau vài tuần, rất khó biết yêu cầu nào đang chờ, ai đã phê duyệt và đâu là phiên bản cuối cùng.
Microsoft Power Automate giúp doanh nghiệp biến những bước thủ công này thành workflow có cấu trúc hơn.
Microsoft hiện hỗ trợ Approval trong Power Automate cho nhiều tình huống như nghỉ phép, tài liệu cần ký duyệt, expense report, invoice, work order hoặc sales quotation. Approver có thể phản hồi từ email, Microsoft Teams hoặc Power Automate Approvals.
Tuy nhiên, lỗi thường gặp là doanh nghiệp bắt đầu bằng một flow quá phức tạp.
Một workflow approval tốt nên bắt đầu bằng câu hỏi đơn giản:
Ai gửi yêu cầu? Ai duyệt? Dữ liệu nằm ở đâu? Sau khi duyệt thì điều gì xảy ra?
Nếu bốn câu hỏi này chưa rõ, chưa nên bắt đầu xây automation.
Một approval workflow cơ bản gồm những gì?
Một flow phê duyệt có thể được hiểu qua sáu phần:
Trigger → Data → Approval → Decision → Action → Audit
Trigger là sự kiện bắt đầu.
For example:
Một item mới được tạo trong Microsoft Lists.
Một form được submit.
Một file được upload vào SharePoint.
Một request thay đổi trạng thái.
Sau đó Power Automate lấy dữ liệu cần thiết và gửi approval tới đúng người.
Approver chọn Approve hoặc Reject.
Flow kiểm tra kết quả rồi thực hiện hành động tiếp theo.
For example:
Approve → cập nhật status thành Approved.
Reject → cập nhật status thành Rejected.
Cuối cùng hệ thống gửi thông báo và lưu lại kết quả.
Microsoft cũng sử dụng chính mô hình này trong các ví dụ chính thức: một item mới trong SharePoint/List kích hoạt flow, sau đó dùng Start and wait for an approval, kiểm tra response bằng Condition và cập nhật item tương ứng.
Nên bắt đầu từ workflow nào?
Không nên chọn quy trình khó nhất của doanh nghiệp để làm flow đầu tiên. Workflow đầu tiên nên có ba đặc điểm:
Có bước phê duyệt rõ.
Được lặp lại thường xuyên.
Không có quá nhiều ngoại lệ.
Ví dụ phù hợp:
Yêu cầu mua hàng.
Đăng ký OT.
Yêu cầu thiết bị.
Đề nghị thanh toán.
Request cấp quyền.
Xin nghỉ phép.
Duyệt tài liệu.
Những quy trình này thường có logic tương đối rõ và dễ đo hiệu quả.
Ví dụ: Quy trình đề nghị mua thiết bị
Giả sử nhân viên cần mua một màn hình mới.
Một workflow đơn giản có thể là:
Nhân viên gửi request.
Manager duyệt.
Nếu số tiền vượt ngưỡng, Finance duyệt thêm.
Nếu được duyệt, Admin nhận thông báo để thực hiện mua hàng.
Nếu bị từ chối, requester nhận lý do.
Đây là một use case rất phù hợp để triển khai Power Automate vì có trigger, approver, condition và action rõ ràng.
Bước 1: Xác định nguồn dữ liệu trước
Approval không nên tồn tại một mình.
Doanh nghiệp cần một nơi lưu request.
Có thể dùng:
Microsoft Lists.
SharePoint List.
Power Apps + Dataverse.
Forms kết hợp Lists.
Với SME, Microsoft Lists hoặc SharePoint List thường là điểm bắt đầu đơn giản.
Ví dụ Request List có thể gồm:
Request ID.
Requester.
Department.
Request Type.
Amount.
Business Reason.
Manager.
Status.
Approval Date.
Approver Comment.
Microsoft cho phép một item mới trong Lists hoặc SharePoint trở thành trigger để bắt đầu approval flow.
Điều quan trọng là dữ liệu cần đủ để approver ra quyết định.
Nếu approval email chỉ nói:
“Please approve request #123”
nhưng người duyệt phải mở thêm ba hệ thống để hiểu yêu cầu, flow chưa thật sự tạo ra nhiều giá trị.
Bước 2: Chọn trigger rõ ràng
Trigger nên phản ánh một sự kiện cụ thể.
For example:
When an item is created.
When an item is created or modified.
When a form response is submitted.
When a file is created.
Không nên tạo trigger quá rộng nếu không cần.
Ví dụ flow chạy mỗi lần item thay đổi có thể vô tình tự kích hoạt lại khi chính flow cập nhật Status.
Điều này có thể gây loop hoặc chạy thừa.
Một cách an toàn hơn là sử dụng trigger condition hoặc thiết kế Status rõ ràng.
For example:
Draft → Submitted → Pending Approval → Approved / Rejected.
Flow chỉ bắt đầu khi Status chuyển sang Submitted.
Bước 3: Chọn đúng loại approval
Power Automate hiện hỗ trợ nhiều kiểu approval.
Microsoft cung cấp các lựa chọn như:
Approve/Reject – Everyone must approve.
Approve/Reject – First to respond.
Custom Responses – Wait for all responses.
Custom Responses – Wait for one response.
Sequential approval.
Không nên chọn theo cảm tính.
Nếu chỉ cần một Manager duyệt, dùng approval đơn giản.
Nếu có ba approver nhưng chỉ cần một người trong nhóm đồng ý, có thể dùng First to respond hoặc Microsoft 365 Group phù hợp. Microsoft cho phép gửi approval tới Microsoft 365 Group, và trong trường hợp group approval, phản hồi của một thành viên có thể đại diện cho group.
Nếu Finance chỉ được duyệt sau khi Department Head đã duyệt, sequential approval phù hợp hơn.
Bước 4: Dùng “Start and wait for an approval” khi workflow đơn giản
Với phần lớn flow cơ bản, Microsoft khuyến nghị Start and wait for an approval vì action này vừa tạo yêu cầu vừa chờ phản hồi trước khi flow tiếp tục.
For example:
Trigger: Request được submit.
Action: Start and wait for an approval.
Approver: Manager.
Condition: Outcome = Approve?
Nếu Yes → Update item = Approved.
Nếu No → Update item = Rejected.
Đây là cấu trúc dễ hiểu và dễ bảo trì.
Không cần tách thành nhiều flow nếu quy trình chỉ kéo dài vài giờ hoặc vài ngày.
Khi nào nên dùng “Create an approval” thay vì chờ trực tiếp?
Nếu approval có thể kéo dài rất lâu hoặc workflow cần linh hoạt hơn, doanh nghiệp có thể tách phần tạo approval và phần xử lý response.
Microsoft lưu ý rằng với long-running approvals có khả năng vượt quá 30 ngày, nên lưu approval trong Dataverse và dùng hai flow: một flow tạo request, flow còn lại xử lý kết quả sau đó.
Đây thường là mô hình phù hợp hơn cho:
Approval hợp đồng dài ngày.
Procurement lớn.
Capital expenditure.
Project approval nhiều cấp.
Không nên dùng kiến trúc này cho một request đơn giản nếu không cần.
Bước 5: Đừng chỉ xử lý Approve và quên exception
Approval workflow thực tế luôn có ngoại lệ.
For example:
Approver nghỉ phép.
Approver account bị disable.
Manager chưa được khai báo.
Request thiếu dữ liệu.
Approval quá hạn.
Amount vượt ngưỡng.
Flow lỗi khi gửi email.
Do đó, ngoài nhánh Approve/Reject, cần xác định exception.
For example:
Nếu Manager field trống → gửi cho Admin kiểm tra.
Nếu Amount > 50 triệu → thêm Finance Director.
Nếu approval chưa phản hồi sau 3 ngày → gửi reminder hoặc escalation.
Nếu flow fail → thông báo flow owner.
Đây là điểm phân biệt một demo flow và một production workflow.
Owner của approval flow là ai?
Không nên để flow quan trọng chỉ thuộc về account của một nhân viên.
Ví dụ người tạo flow nghỉ việc.
Connection hết hiệu lực.
Flow tiếp tục tồn tại nhưng không ai biết ai chịu trách nhiệm.
Doanh nghiệp nên xác định rõ:
Business Owner.
Technical Owner.
Backup Owner.
Business Owner chịu trách nhiệm về logic quy trình.
Technical Owner quản lý flow, connector, error và deployment.
Microsoft cũng có guidance riêng về governance, security, naming convention và monitoring cho Power Automate.
Naming convention nên được chuẩn hóa
Nếu một tenant có các flow như:
Flow 1.
Approval New.
Test2.
Final Approval.
thì sau vài tháng sẽ rất khó quản lý.
Một naming convention đơn giản có thể là:
APPROVAL – Procurement – Purchase Request
APPROVAL – HR – Overtime
APPROVAL – IT – Access Request
Khi nhìn tên flow, IT biết ngay chức năng.
Có nên dùng Teams Approvals?
Có, nếu người dùng chủ yếu làm việc trong Teams.
Microsoft Teams có ứng dụng Approvals riêng, cho phép người dùng tạo, quản lý và phản hồi approval ngay trong Teams. Các approval này sử dụng Power Automate infrastructure, và approver có thể xử lý request từ một nơi tập trung.
Tuy nhiên, Teams Approvals phù hợp nhất khi workflow tương đối đơn giản.
Nếu doanh nghiệp cần:
Custom business logic.
Update SharePoint.
Check amount.
Multiple conditions.
Escalation.
Logging.
thì Power Automate flow vẫn phù hợp hơn.
Có thể dùng Teams như giao diện approval, còn logic nằm trong flow.
Cần lưu trạng thái ở đâu?
Không nên chỉ dựa vào email approval.
System of record nên có status rõ ràng.
Ví dụ List:
Submitted.
Pending Approval.
Approved.
Rejected.
Processing.
Completed.
Canceled.
Approval outcome từ Power Automate sau đó cập nhật vào item.
Như vậy Operations có thể tạo view:
Pending.
Approved today.
Rejected.
Overdue.
Không cần tìm email cũ.
Approval comment rất quan trọng
Đặc biệt với Reject. Một request bị từ chối mà không có lý do sẽ tạo thêm trao đổi.
Doanh nghiệp nên yêu cầu approver nhập comment khi Reject nếu workflow phù hợp.
For example:
“Rejected – thiếu quotation thứ hai.”
“Rejected – budget vượt hạn mức.”
Comment có thể được ghi lại vào List hoặc gửi cho requester.
Điều này giúp quy trình minh bạch hơn.
Không nên hard-code approver nếu tổ chức thay đổi thường xuyên
Một lỗi rất phổ biến:
Flow gửi thẳng tới managerA@company.com.
Sau sáu tháng Manager A chuyển vị trí.
Flow vẫn gửi sai người.
Cách tốt hơn là lấy approver từ dữ liệu.
For example:
Manager field trong Microsoft Entra / Microsoft 365 profile.
Approver column trong Lists.
Department Approval Matrix.
SharePoint Configuration List.
Như vậy thay đổi approver không yêu cầu sửa flow.
Approval Matrix hữu ích khi nào?
Khi doanh nghiệp có nhiều rule.
For example:
Sales dưới 10 triệu → Sales Manager.
Sales trên 10 triệu → Sales Director.
IT dưới 20 triệu → IT Manager.
IT trên 20 triệu → Finance Director.
Không nên viết hàng chục Condition trực tiếp trong flow.
Có thể tạo một Approval Matrix trong Lists để flow lookup.
Điều này giúp Business Owner thay đổi rule dễ hơn mà không phải chỉnh automation.
Logging và audit cần được tính từ đầu
Approval là business decision.
Do đó nên giữ:
Requester.
Submitted time.
Approver.
Approval time.
Outcome.
Comments.
Final status.
Microsoft Approvals lưu response metadata và lịch sử approval, nhưng với business workflow, doanh nghiệp vẫn nên lưu những trường cần thiết trong system of record để reporting dễ hơn.
Đo hiệu quả workflow như thế nào?
Không nên chỉ đo số flow runs.
Nên đo business outcome.
For example:
Thời gian approval trung bình trước automation: 2 ngày.
Sau automation: 6 giờ.
Tỷ lệ request bị thiếu thông tin giảm bao nhiêu?
Bao nhiêu approval quá hạn?
Department nào có bottleneck?
Flow fail rate là bao nhiêu?
Bao nhiêu bước email/chat được loại bỏ?
Những KPI này giúp doanh nghiệp biết automation có thực sự tạo giá trị hay không.
Checklist triển khai Power Automate Approval
Trước khi đưa flow vào production, nên kiểm tra:
Business Owner đã được xác định
Trigger rõ và không gây loop
Request data đủ cho approver quyết định
System of record đã xác định
Approval type phù hợp
Approver không bị hard-code nếu không cần
Approve và Reject đều có action rõ
Reject comment được xử lý
Có logic escalation nếu quá hạn
Có xử lý approver vắng mặt
Có exception khi dữ liệu thiếu
Status được cập nhật vào source
Requester nhận notification
Audit information được lưu
Flow có Business Owner và Technical Owner
Connection không phụ thuộc vào một cá nhân duy nhất
Naming convention được áp dụng
Flow đã test bằng nhiều tình huống
Có monitoring khi flow fail
Governance được review định kỳ
Conclude
Power Automate Approval hiệu quả nhất khi doanh nghiệp bắt đầu từ một quy trình đơn giản, lặp lại và có người chịu trách nhiệm rõ ràng.
Microsoft hiện hỗ trợ nhiều kiểu approval, từ First to respond, Everyone must approve đến sequential approval, và approver có thể xử lý request qua email, Microsoft Teams hoặc Power Automate.
Một workflow cơ bản có thể được thiết kế theo:
Trigger → Request data → Approval → Condition → Action → Notification → Audit
Điều quan trọng là không dừng ở việc “gửi email xin duyệt”.
Một flow production cần xử lý thêm:
Owner.
Exception.
Escalation.
Status.
Audit.
Monitoring.
Governance.
Nếu doanh nghiệp mới bắt đầu, hãy chọn một use case đơn giản như purchase request, OT hoặc equipment request, pilot với một phòng ban rồi mới mở rộng.
Related articles
- Microsoft Entra ID đóng vai trò gì trong Microsoft 365?
- Hiểu tenant Microsoft 365 qua cấu trúc quản trị và ownership
- Copilot Chat phù hợp với người chưa có Microsoft Copilot license?
- Readiness Assessment trước triển khai Microsoft 365 nên kiểm tra gì?
- Microsoft Lists, Forms, Bookings và Loop khác nhau thế nào?
