之前我們建立了一個可以想SharePoint清單進行寫入的PowerApps小程式，現在我們在Flow中去建立這樣的審批流：
1.SharePoint Online清單中新添加了請假申請
2.向申請者的直接彙報上司發送郵件
3.上司在郵件中通過或拒絕請假
4.更新SharePoint Online清單中的請假審批狀态并通知申請人
注：PowerApps現有的請假系統做的較為完善，分為員工登陸和經理登陸等等，但是如果沒有對PowerApps基本的了解很難去自定義到自己公司的情況，是以這裡我們介紹這個較為簡單的方式，下一章節會提升整個請假系統的流程以及界面美化（本人并不擅長排版LOL）
我們先進入Flow：
先多說五句，如果你的整個項目設計過程中涉及到Flow，注意一下幾點：
1.是否有現成的模闆可以使用
2.并不是所有的SaaS軟體都可以讓Flow連結起來
3.每個部分的連接配接器–connector是否可以調用我需要的資訊（整個基本都沒問題）
4.進階的流會涉及到使用Microsoft Graph，當然這個本文不涉及
5.從Flow中來規劃你的整個項目
比如我們這個請假系統的項目，需要用到：
SharePoint作為資料源和觸發器
PowerApps作為互動界面
調用Office 365裡的使用者資訊
通過郵件來審批和通知使用者
是以我們選擇下圖中的這一項，剛好滿足要求
我們選擇的這一個，也是審批流中的一項。審批流也是最常用最經典的一個工作流，工作流這個說法還要追溯到SharePoint 伺服器上去，這裡就啰嗦一句曆史。
點選繼續我們就會看到整個流的架構：
有點類似一個流程圖，但是更準确地說像一個決策樹（機器學習中會用到一種算法，去比随機森林更容易看懂）
這裡還少一些我們需要的東西，比如直接彙報人，點選兩個闆塊直接的箭頭中的加号，然後選擇添加操作，添加Office 365 使用者，選擇“擷取經理”
然後在使用者欄輸入created by Email，這個是申請者的郵箱，你可能會注意到我上一章的内容截圖裡，有兩個員工名稱：
這并不沖突，因為比如這個員工今天臨時請假沒法在系統裡送出，就可以讓同僚代為送出，那麼員工姓名就可以選擇真正休假的人
當然如果是這種情況，我們的審批流就需要改一改了，就不能填寫created by email，而是要選擇:
當然這還要添加一個點，就是這個是否是為自己送出的，可以在PowerApps中添加一個是/否的選項，當然在flow中也要響應修改，我們不讨論這個情況，就先按最簡單的來。
進入正式的條件判斷–yes和no的處理：
如果是yes，我們的順序是
1.向申請者發送郵件，告知申請被準許
2.更新SharePoint Online的清單中狀态，從已送出改為準許
3.向替補員工發郵件告知他/她需要在這段時間内替補
整個流程很簡單，需要注意的就是合理準确的調用動态内容，比如同樣是員工姓名，但是字尾會有（department）,(displayname)等，如果選錯了那麼會鬧出笑話
如果被經理拒絕了：
1.告知申請者請假申請被拒絕
2.在SharePoint 清單中更新狀态欄
那麼右邊這個我們一直沒介紹的到底是什麼？
這個就是一個類似程式設計裡，比如Java舉例，一個try catch的動作。如果這個申請者沒有直屬經理，就會傳回給他/她一封郵件說這個流沒法正常運作
結果就如下圖：
現在我們看一下這個請假申請在生産環境中的表現：
1.員工送出申請
他的直屬彙報人：（Teams裡的截圖，當然在EAC裡也能看，隻不過這裡更加直覺）
2.經理收到郵件并準許或拒絕
3.SharePoint清單中的狀态發生變化：
4.替補員工收到郵件：
到這裡這個工作流就可以正常在企業内運作了。
後面一章會介紹如何優化改進整個流的體驗