小村軟體有限公司
聯絡我們
選單

用 Microsoft Forms 打造企業內部申請・請求受理窗口 ── 把郵件與口頭請求彙整到表單中

· · Power Automate, Microsoft Forms, Forms, SharePoint, Teams, Microsoft 365, 雲端流程, 申請表單, 業務自動化, 技術諮詢

「希望能幫忙建立伺服器帳號」透過郵件送達,「印表機好像有問題,幫忙看一下」是在走廊擦身而過時口頭拜託的,「這張請款單麻煩處理一下」則貼在桌上的便利貼上。資訊系統部門、總務、會計等在公司內部負責接收請求的部門,經常向我們諮詢想解決這種狀況的問題。

提出請求的一方認為「說過了對方就會處理」,而接收方則只能仰賴自己的記憶與收件匣。偏偏在忙碌的日子裡就是會漏掉一件,直到對方問「那件事後來怎麼樣了？」才發現。如果公司已經導入 Microsoft 365,這個問題可以透過「以 Microsoft Forms 作為受理窗口,再用 Power Automate 自動化通知與記錄」的「受理模式」大幅解決。本文將整理表單設計的實務作法、檔案上傳的限制、受理流程的基本形式,以及為什麼 Forms 單獨使用有其極限、把資料轉寫到清單才是標準做法的理由。至於核准・裁決本身的設計,由另一篇文章「用 Power Automate 打造簽核流程 ── 讓紙本與郵件的簽呈、申請電子化」擔綱,因此本文聚焦在「受理」上。

目標讀者與前提環境

  • 目標讀者:資訊系統、總務、會計等在公司內部負責接收請求或申請的承辦人員。本文假設讀者尚未接觸過 Power Automate。
  • 前提環境:已導入 Microsoft 365,且能使用 Microsoft Forms 與 SharePoint。建立流程需要能使用 Power Automate 的授權,但本文使用的 Forms、SharePoint、Outlook、Teams 連接器都屬於標準連接器的範圍,不會用到進階連接器(關於界線的整理請參考「Power Automate 的授權 ── Microsoft 365 能免費用到什麼程度、何時需要 Premium」)。
  • 所需權限:必須是表單所屬群組(團隊)的成員,並且能在轉寫目的地的 SharePoint 網站建立清單。不需要租用戶管理員權限,但記錄回覆者姓名的預設值,以及是否允許對外共用,則由管理員設定決定。1
  • 本文製作的內容:一個用於受理請求的表單、一個作為受理台帳的 SharePoint 清單,以及一個在受理時觸發的雲端流程。

1. 先講結論

  • 請求的受理窗口要同時設計「輸入的格式」與「記錄的存放位置」。現實中最精簡的組成是「用 Forms 受理 → 透過 Power Automate 轉寫至 SharePoint 清單 → 發出通知」。
  • 流程的基本形式,是觸發程序「收到新回覆時」與動作「取得回覆詳細資料」這兩個步驟。Forms 連接器就只有這 1 個觸發程序、1 個動作(加上取得表單詳細資料),需要記住的東西並不多。23
  • 公開範圍原則上僅限組織內部。只要啟用「記錄姓名」,回覆者的姓名與電子郵件地址就會自動記錄下來,不需要再讓對方填寫姓名或所屬單位。若設定為對組織外部開放,回覆就會變成匿名,不會記錄是誰提交的。4
  • 檔案上傳問題僅限「僅限組織內部」的表單使用。單一問題最多可上傳 10 個檔案,單一檔案上限可從 10MB、100MB、1GB 中選擇,檔案會儲存在 OneDrive for Business 中。5
  • 讓 Forms 專職於受理窗口,是讓它能長久維持下去的訣竅。它沒有送出後編輯或確認進度的功能,回覆清單也沒有狀態管理機制,因此台帳應該交給 SharePoint 清單來負責。6
  • 回覆數量的上限,以職場或學校帳戶而言最多為 5,000,000 筆,對企業內部使用來說幾乎等於無限制,但一旦超過 50,000 筆,摘要圖表與個別回覆的檢視功能就會無法使用。比起數量上限,「清單管理能力薄弱」這一點會先成為瓶頸。7
  • 若需要受理組織外部人員的申請並附加檔案、案件量龐大且要與核心系統整合、想把進度公開給申請人查看 ── 到了這個程度,就開始超出 Forms 的守備範圍。第 7 章的判斷表整理了這條界線。

2. 郵件與口頭請求的問題出在哪裡

用郵件與口頭方式接收請求的做法,問題出在承辦人員再怎麼努力也無法解決的結構性因素上。

  • 遺漏是結構性發生的。由於請求會透過收件匣、聊天、口頭、便利貼等不同管道送達,任何地方都不存在「全部案件的清單」。這等於是把「一件都不漏掉」這件事,賭在個人的記憶力上。
  • 格式參差不齊,導致往返溝通增加。若郵件內容只有「請幫忙設定 PC」,無法得知是哪一台 PC、希望的日期、原因,於是就會產生反覆詢問確認的往返。每次提出請求都要重新想起該寫哪些必要事項,對提出請求的一方來說也是一種負擔。
  • 狀態不透明,演變成「有說沒說」的爭執。申請人無法得知請求是否已被受理、是否已著手處理、何時會完成。只要承辦人員說一句「我沒聽說」,就會演變成各說各話。催促與確認本身的往返溝通,就會侵蝕雙方的時間。
  • 無法統計。由於不會留下每月有多少件請求、時間都花在哪裡的資料,因此無法用數字來佐證「人手不足」、「這個系統的詢問量太多」之類的說法。

只要建立「把請求的入口統一為一個、以固定格式接收必要事項、受理的瞬間就留下記錄與通知」的機制,這些問題就能一併朝解決的方向邁進。之所以使用 Forms 與 Power Automate,是因為只要已經導入 Microsoft 365,這套機制往往可以在不增加額外費用的範圍內建置完成(本文使用的 Forms、SharePoint、Outlook、Teams 各連接器都屬於標準連接器的範圍。授權的思考方式整理在「Power Automate 的授權 ── Microsoft 365 能免費用到什麼程度、何時需要 Premium」中)。

3. 表單設計的實務

問題以「讓對方選擇」為基本原則

表單設計的目標,是讓申請人能毫不猶豫地送出,同時讓接收方不需要反問就能取得足以行動的資訊。原則是「用選項接收,文字輸入降到最低限度」。

  • 請求類型設為選項。像「建立帳號 / PC・周邊設備 / 軟體安裝 / 其他」這樣,把之後用於統計與流程分支的軸線,透過選項固定下來。
  • 期限用日期問題來接收。這樣能消除「盡快」、「這週內」之類模糊表達造成的落差,流程端也能拿來用於提醒(關於營業日與截止日的處理方式,可參考「用 Power Automate 設計定期執行流程 ── 月底處理、營業日判定與提醒的實務」)。
  • 自由填寫的欄位,建議統整成「補充說明」這一個問題即可。這裡有一個實務上要注意的地方:單行文字(簡短回答)若輸入超過 255 個字元,已知會發生流程時而觸發、時而不觸發的問題。可能輸入長文的問題,一開始就設定為「較長的回答」(多行文字)。8

還有一點就是「不要讓對方寫太多」。受理表單的角色是不漏接任何一件請求,而不是當場吸收所有資訊。問題太多的表單,反而會讓使用者退回口頭或郵件的方式。需要詳細訪談的案件,前提是受理後由承辦人員另行聯絡,表單本身的顆粒度控制在幾分鐘內就能填完送出的程度。

用分支避免顯示「無關的問題」

若依請求類型不同、需要詢問的內容也不同,可以使用分支(branching)。分支能依選項的回答結果,切換接下來顯示的問題或章節,例如「若是建立帳號,就顯示目標系統與權限;若是設備故障,就顯示資產編號與症狀」,讓回覆者只看到與自己相關的問題。由於分支只能跳到後面的問題(無法跳回前面的問題),因此把共通的問題放在前半段、依類型分別的問題放在後半段並分成不同章節,是比較容易建構的架構。9

公開範圍與回覆者資訊 ── 僅限組織內部與匿名的差異

Forms 的公開範圍有 3 種。4

公開範圍 可回覆的人 回覆者的記錄
所有使用者皆可回覆 只要知道連結,組織外部人員也能回覆 匿名。不會記錄是誰提交的
僅限本組織內的使用者可回覆 只有以組織帳戶登入的人 透過「記錄姓名」自動記錄姓名・電子郵件地址
組織內特定使用者可回覆 只有指定的使用者・群組 同上

企業內部申請・請求的受理窗口,原則上應僅限組織內部。理由有三個。

  1. 不需要讓對方填寫「是誰提交的」。只要啟用「記錄姓名」,回覆者的姓名與電子郵件地址就會自動附加在回覆上。姓名、所屬單位、聯絡方式這種「每次都要寫一樣內容」的問題,可以整個省略。4
  2. 有些功能只有在僅限組織內部時才能使用,例如限制每人回覆一次、檔案上傳等。「每人限一次回覆」也只有在僅限組織內部時才能設定。4
  3. 能透過流程回覆給申請人。由於回覆詳細資料中會包含回覆者的電子郵件地址(Responders’ Email),因此可以直接寄送受理完成郵件(第 5 章)。匿名表單無法做到這一點。10

此外,作為整個組織的預設值是否記錄回覆者姓名,可由管理員透過 Microsoft 365 系統管理中心的 Forms 設定(「預設記錄姓名」)來控制。是否允許以租用戶為單位進行外部共用(向組織外部人員發出回覆邀請)本身,也是同一畫面中的設定。若公司訂有「內部問卷預設為匿名」之類的政策,也應事先確認這一點。1

即便如此,若仍有必要對外部開放,也一併整理一下屆時會失去哪些東西。

  • 不會記錄是誰提交的。對組織外部開放的表單,其回覆會變成匿名,回覆者不需要登入就能送出。11 冒名頂替與重複送出,在表單這一端都無法防止。「每人限一次回覆」的限制也只有僅限組織內部時才能使用,因此同一個人可以送出無數次。4
  • 無法接收附加檔案。檔案上傳問題僅限「僅限組織內部」的表單使用。5
  • 無法透過流程回覆給申請人。由於取不到回覆者的電子郵件地址(Responders’ Email),因此無法使用最有效的機制 ── 自動回覆受理完成郵件(若改用讓對方自行填寫電子郵件地址的做法,一旦收件地址打錯,郵件就會直接送不到)。
  • 本來就有可能不被允許。由於外部共用可透過租用戶的管理員設定加以禁止,因此可能發生「連結發出去了,對方卻無法回覆」的事故。請事先向管理員確認。1

對外部開放的安全範圍,大致到「件數不多、不需要附件也不需要驗證身分的問卷式受理」為止。若超出這個範圍,就依第 7 章的判斷表,改為採用 Web 表單的設計。

不要讓表單停留在個人名下 ── 為建立者離職預作準備

這是個容易被忽略、卻很重要的論點。個人建立的表單會與該人的帳戶綁定,一旦因離職等原因使帳戶從租用戶中刪除,與帳戶相關的資料會在刪除後 30 天消失。11 受理表單是業務的入口,因此不應成為承辦人員個人的所有物,應該以群組(團隊)的表單方式建立,或事先訂定好在異動・離職時移轉所有權的作業方式。8

流程端有一點需要注意。群組表單不會顯示在 Power Automate 觸發程序的表單 ID 清單中,因此需要複製表單編輯畫面網址中 FormId= 之後的值,手動輸入作為表單 ID。3 雖然多一道手續,但避免流程被綁在特定個人身上的價值更大。

4. 檔案上傳的規格與限制

像「附上估價單 PDF 提出採購申請」、「附上錯誤畫面截圖回報故障」這樣,請求伴隨附加檔案的案例並不少。必須正確掌握 Forms 檔案上傳問題的規格。5

  • 僅限「僅限組織內部」的表單使用。只有在公開範圍設為「僅限本組織內的使用者可回覆」或「組織內特定使用者可回覆」時才能新增,對組織外部開放的表單則無法使用。也就是說,Forms 無法用於「讓組織外部的往來廠商附加檔案提出申請」這類用途。
  • 單一問題最多可接收 10 個檔案,單一檔案的大小上限可從 10MB、100MB、1GB 中選擇。
  • 可以限制檔案類型。可從 Word、Excel、PowerPoint、PDF、圖片、影片、音訊中選擇允許的類型,因此能做到「估價單僅限 PDF」這樣的接收方式。
  • 儲存位置會依表單的擁有者而異。若是個人表單,回覆者上傳的檔案會累積在建立者 OneDrive for Business 的「應用程式 > Microsoft Forms > (表單名稱) > (問題名稱)」資料夾中;若是第 3 章建議採用的群組表單,則會累積在群組的 SharePoint 網站中。

若要在流程中處理上傳的檔案,需要多一道手續。「取得回覆詳細資料」所回傳的上傳問題回答,是包含檔案名稱與 ID 的 JSON 字串,因此需要透過「JSON 的解析(Parse JSON)」給定結構描述後加以拆解,再用 first(body('Parse_JSON'))?['id'] 這樣的運算式取出檔案 ID,然後傳給取得檔案的動作。10

建立結構描述的方式,按照官方步驟從實際資料生成最為可靠。步驟為:①儲存流程並進行測試執行,從表單上傳一個檔案 → ②在執行紀錄中開啟「取得回覆詳細資料」,複製該上傳問題的輸出內容 → ③貼到「JSON 的解析」動作的「從範例產生」欄位中,共 3 個步驟。10

若想手動撰寫,只需要只宣告會用到的屬性的最小形式就足夠了(即使回傳了未宣告的屬性,JSON 的解析仍然能夠通過)。建立共用連結所需要的只有檔案 ID,因此實質上只需要以下內容。

{
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "id":   { "type": "string" },
            "name": { "type": "string" }
        },
        "required": [ "id" ]
    }
}

這裡最需要注意的一點是,回答會以陣列的形式回傳。官方運算式之所以寫成 first(body('Parse_JSON'))?['id'] 這種取出第一個元素的形式,原因就在這裡。10 另外,first(...) 是以檔案只有 1 個為前提的寫法。若問題允許上傳多個檔案,回答會以逐一檔案物件排列而成的陣列回傳,因此需要用 Apply to each 迴圈跑過解析結果,逐一取得每個檔案(若請求只需要 1 個附件就夠了,把問題端的上限設為 1 個檔案會比較簡單)。此外,取得檔案所使用的連接器,要配合前面提到的儲存位置。個人表單使用 OneDrive for Business 連接器;群組表單的儲存位置是群組的 SharePoint 網站,因此要用 SharePoint 連接器並指定該網站來取得。針對群組表單卻用 OneDrive 連接器去尋找檔案而找不到,是常見的組合錯誤陷阱。

若要把收到的檔案附加到核准請求中傳遞,需要將檔案內容以二進位的形式傳給附件欄位。12 不過,核准動作能附加在郵件中的檔案上限為 5MB,超過的附件會變成需要核准者在 Power Automate 入口網站的核准清單中確認。8 較大的檔案不要以附件方式傳遞,而是儲存在 SharePoint 中並傳遞連結,會更為可靠。

5. 用 Power Automate 讓受理流程運作起來

基本形式是 2 個步驟加上 3 個出口

即使收到回覆,Forms 在預設情況下也不會通知任何人(雖然有針對表單擁有者的通知設定,但收件人與內文都無法自訂10)。讓受理作為業務流程運作起來,是 Power Automate 的工作。流程的基本形式,是以觸發程序「收到新回覆時」指定表單,接著用「取得回覆詳細資料」把各個問題的回答取出作為動態內容,共 2 個步驟。2 接下來的出口有 3 個:「記錄到台帳」、「向申請人發出受理通知」、「向負責團隊發出通知」。

是否申請人透過 Forms 送出僅限組織內部,已登入收到新回覆時雲端流程啟動取得回覆詳細資料將回答轉為動態內容於 SharePoint 清單建立項目狀態,已受理寄送受理完成郵件給申請人附上回答內容副本發佈到負責團隊的 Teams 頻道是否為需要核准的類型?進入核准流程開始並等待核准指派負責人處理將結果寫回清單以狀態欄位更新處理進度

概念圖與實際畫面之間的落差最容易讓人迷惘,因此以下也寫下依這張圖實際操作時的點擊步驟。請事先建立好轉寫目的地的 SharePoint 清單。

  1. 開啟 Power Automate 入口網站,從左側選單的「建立」選擇「自動化雲端流程」。輸入流程名稱。
  2. 在觸發程序的搜尋欄輸入「Forms」,選擇「收到新回覆時」。2
  3. 在觸發程序的「表單識別碼」中選擇表單。群組表單不會顯示在清單中,因此要貼上表單編輯畫面網址中 FormId= 之後的內容(第 3 章)。3
  4. 「新增步驟」→搜尋欄輸入「Forms」→動作「取得回覆詳細資料」。這裡同樣指定同一個表單,「回覆識別碼」則填入觸發程序的動態內容「回覆識別碼」(有時會自動填入)。2
  5. 「新增步驟」→「SharePoint」→「建立項目」。選擇網站位址與清單名稱,把「取得回覆詳細資料」的動態內容(各問題的回答)指派給各個欄位。狀態欄位則先填入 已受理 這類固定值。
  6. 「新增步驟」→「Office 365 Outlook」→「傳送電子郵件 (V2)」。在「收件者」填入動態內容的 Responders’ Email,內文則寫入回答內容的副本與大概所需的天數。10
  7. 「新增步驟」→「Microsoft Teams」→「在聊天或頻道中張貼訊息」。選擇負責團隊的團隊與頻道,附上類型、期限、申請人以及清單項目的連結。
  8. 點選右上角的「儲存」→「測試」啟動手動測試,實際從表單送出一筆資料。展開各步驟的輸入輸出,確認數值是否如預期填入。

加入通往核准的分支是之後的事。建議先只靠上面的 1～8 步驟,確認能做到「送出一筆資料,就會登上台帳、寄出郵件給申請人、發出團隊通知」為止,再逐步疊加條件分支,會比較安全。

轉寫至 SharePoint 清單 ── 建立受理台帳

受理的請求,會在流程的一開始逐行轉寫到 SharePoint 清單中。重點在於,清單除了回答的副本之外,還要有表單所沒有的「管理用欄位」。

欄位 內容 由誰更新
請求內容欄位(類型・期限・詳細等) 原封不動轉寫 Forms 的回答 流程(受理時)
申請人 從 Responders’ Email 記錄 流程(受理時)
狀態 已受理/處理中/完成/退回 負責團隊
負責人 指派的負責人 負責團隊
處理備註 經過・確認事項 負責團隊

向申請人追加詢問的內容或經過,不要分散在郵件裡,統一集中到這個清單(或與清單項目綁定的 Teams 討論串)中,「有說沒說」的記錄就能集中在同一個地方。若建立一個「狀態=未完成」的檢視畫面,就能直接作為早會使用的處理清單。轉寫到 Excel 也有現成的範本可用10,但對於需要由多人持續更新狀態的台帳來說,具備檢視畫面、欄位型別、版本歷程記錄的清單更為合適。從 Excel 台帳遷移到清單的思考方式,整理在「把 Excel 台帳替換成 SharePoint 清單 ── 透過共用、歷程記錄與流程整合,告別「台帳損壞」問題」中。

受理通知 ── 在最初的 1 分鐘內回覆「已收到」

這裡是與郵件請求相比,感受落差最大的地方。流程會發出兩種通知。

  • 寄給申請人的受理完成郵件。若是僅限組織內部的表單,可以直接用 Outlook 連接器,寄給回覆詳細資料中包含的回覆者電子郵件地址(Responders’ Email)。10 內文中插入回答內容的副本,以及「將於 3 個工作天內由負責人聯絡」這類大致的時程說明。申請人想催促的原因,大多是「連有沒有收到都不知道」,因此光是這一封郵件,就能大幅減少詢問。Forms 本身也有針對回覆者的確認郵件設定,但能把內文調整成符合業務需求的,是透過流程寄送的方式。10
  • 給負責團隊的 Teams 通知。若寄給個人信箱,又會再度變成綁在特定個人身上,因此發佈到負責團隊的頻道。只要附上類型、期限、申請人以及清單項目的連結,頻道就能直接作為「新進請求的收件匣」使用。

銜接到核准

像「軟體採購需要主管核准」這樣的類型,可以從受理流程銜接到核准動作(開始並等待核准)。系統也提供了把 Forms 回答內容帶入核准請求的範本,能一口氣建構到依核准結果回覆結果郵件給申請人的程度。10 核准的類型、逾時與催促、核准記錄的留存方式等設計論點,已在「用 Power Automate 打造簽核流程 ── 讓紙本與郵件的簽呈、申請電子化」中詳細說明,請參考該文。受理流程開始穩定運作後,也應及早設定流程的共同擁有者,以及發生錯誤時的通知(錯誤處理的設計請參考「Power Automate 的錯誤處理與重試設計 ── 防止「原本正常運作的流程忽然停止」」)。

6. Forms 單獨使用的極限 ── 所以轉寫到清單才是標準做法

若想只靠 Forms 完成整個受理流程,會遇到以下的高牆。

  • 送出後的狀態不透明。預設情況下,回覆者無法在事後修改已送出的內容。雖然有部分環境已推出讓建立者可以允許回覆者本人儲存・編輯回答的設定,但那終究只是修正回答內容的手段。作為表單設定所提供的,是受理的開始・結束日期時間、每人限一次回覆等6,並沒有可以確認「自己的請求目前處於什麼狀態(已受理・處理中・完成)」的畫面,比較符合實際情況的想法是:不存在支援「送出之後」的功能。在未允許編輯的環境下,若修正是透過「再送一次」進行,那麼哪一筆才是最新的,就得由接收方自行判斷。
  • 回覆清單的管理功能薄弱。Forms 的回覆畫面是用來統計與檢視的,無法擁有狀態欄位或負責人,也無法做到「只顯示尚未處理的項目」。受理管理所需要的是能持續「更新」清單的功能,但這超出了 Forms 的守備範圍。
  • 比起件數上限,更早發揮限制作用的是功能面。職場・學校帳戶的表單,每個表單最多可接收 5,000,000 筆回覆,問題數上限為 200 題,單一問題的文字回答上限為 4,000 個字元(此外還有一項限制,是單次回覆中文字回答的總計上限為 200,000 個字元,不過這是單一回覆者在一次送出內就會達到的上限類型,而不是隨著回覆累積才會達到的上限)。在實務上會先發揮作用的不是件數,而是功能限制:一旦超過 50,000 筆,摘要圖表、個別回覆檢視、列印等功能就會無法使用,只能透過 CSV 匯出取得資料。7 企業內部受理幾乎不會達到件數上限,但對於長期運行的表單而言,「把資料一直堆積在 Forms 裡」這種設計本身就會造成影響。官方的建議是回覆增加後就先匯出再清除回覆11,不論如何,都需要另外準備存放歷程記錄的地方。

也就是說,Forms 作為「發放輸入格式的工具」非常優秀,但並不是「管理受理之後的工具」。Forms 負責受理窗口,台帳與狀態管理交給 SharePoint 清單,通知與整合交給 Power Automate,這樣依各自擅長領域分工,才是標準做法。

7. 該用 Forms 受理到什麼程度 ── 判斷表

受理窗口的工具配置有其階段性。以下整理成表格供參考。

情況 判斷
來自公司內部的請求・申請,欄位大約在 10 題以內。附件僅來自內部使用者 Forms + 流程 + 轉寫至清單已經足夠。本文採用的架構
欄位較多的定型化申請,填寫者僅限於特定部門且熟悉清單操作 直接用 SharePoint 清單的表單受理。不需要轉寫,輸入與資料的型別也能保持一致
只想把每次的核准電子化(不需要受理台帳) 用 Teams 的核准應用程式就夠了。也不需要建立流程
想接收組織外部(往來廠商・客戶)的申請。不需要附件 可以用 Forms 的匿名表單受理,但回覆者的記錄・防冒名對策・輸入檢查都比較薄弱。件數不多的話可行
想接收組織外部附帶附件的申請,需要輸入檢查・編號・核發受理編號 由於 Forms 的附件僅限組織內部,無法做到。5 屬於併用 OneDrive/SharePoint 檔案要求功能,或是委外開發 Web 表單的領域
件數龐大,想從受理串接到登錄至核心系統・進度公開・SLA 管理 屬於服務台/工作流程的專用系統或委外開發領域。應把 Forms 定位為初期的過渡性受理窗口

判斷的大致感覺是:「只要申請人還在公司內部,就能靠 Forms 撐下去;一旦牽涉到組織外部,就要改變設計」。關於把與組織外部之間的紙本・傳真・郵件附件往來連同受理窗口一起重新檢視的話題,可參考「把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務」與「用 Power Automate 自動處理郵件收到的訂購單・請款單 PDF ── 儲存・分類・通知・讀取的設計」。

8. 總結

郵件與口頭請求之所以令人痛苦,是因為請求的全貌無處可見、格式不統一、狀態不透明。用 Microsoft Forms 把入口統一為一個,透過僅限組織內部加上記錄姓名把「是誰提交的」自動化,再用 Power Automate 在受理的瞬間回傳台帳記錄與受理通知。光是這個模式,就能大幅消除「那件事後來怎麼樣了？」這樣的往返。

設計上的重點在於:以選項為中心、不讓對方寫太多的表單;理解僅限組織內部與匿名的差異;掌握檔案上傳的限制(僅限組織內部・最多 10 個檔案・單一檔案最大 1GB);以及不要對 Forms 抱有台帳的期待。Forms 負責受理窗口,清單作為台帳,流程負責通知與整合。只要守住這樣的角色分工,即使承辦人員更換,受理機制也能長久持續運作下去。而當來自組織外部的受理與附件、件數與整合需求逐漸膨脹時,就是該考慮開發 Web 表單或導入專用系統的時機了。

下一步 ── 建立第一個表單時的檢查清單

若一開始就想把所有請求彙整到一個表單裡,問題會越來越多,最後導致誰都不想用。請先只針對一種類型試行。

  • 只選一種類型作為對象請求(件數多、格式參差不齊的比較適合)
  • 問題數控制在 5～10 題。請求類型・期限・補充說明這三項務必納入
  • 自由填寫欄位設為「較長的回答」(為避免單行文字的 255 字元問題。第 3 章)
  • 公開範圍設為「僅限組織內部」,並開啟「記錄姓名」
  • 以群組(團隊)的表單而非個人表單建立
  • 先建立好轉寫目的地的 SharePoint 清單,務必具備狀態・負責人・處理備註這 3 個欄位
  • 依「取得回覆詳細資料 → 建立項目 → 受理完成郵件 → 張貼到 Teams」的順序組建流程,並透過測試執行跑通 1 筆資料
  • 在受理完成郵件中寫明「什麼時候會發生什麼事」
  • 為流程新增至少 1 位共同擁有者(以便建立者休假時也能修正)
  • 運行 2 週後,把曾發生反問的項目補進表單問題中

做到這裡之後,再逐一增加請求類型。要增加的不是表單的問題,而是類型的選項與分支。

相關文章

相關諮詢領域

合同會社小村軟體提供從活用 Microsoft 365 打造企業內部業務受理・台帳・通知機制的諮詢,到 Forms 無法涵蓋的對外 Web 表單・業務系統開發等服務。

參考連結

</content>

  1. Microsoft Learn, Administrator settings for Microsoft Forms。關於管理員可透過 Microsoft 365 系統管理中心控制,是否作為組織的預設值記錄回覆者姓名(「預設記錄姓名」,預設為開啟),以及是否允許外部共用(向組織外部發出回覆邀請・共同編輯等)的說明。 ↩ ↩2 ↩3

  2. Microsoft Learn, Overview of flows with Microsoft Forms。關於 Forms 連接器擁有觸發程序「收到新回覆時」與動作「取得回覆詳細資料」,以及回覆內容可作為動態內容在流程中使用的說明。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Microsoft Forms (Connector reference)。關於 Forms 連接器僅限組織帳戶使用、群組表單不會顯示在觸發程序清單中而需要手動輸入表單編輯畫面網址「FormId=」之後的內容,以及觸發程序・動作清單的說明。 ↩ ↩2 ↩3

  4. Microsoft Support, Choose who can fill out a form or quiz。關於 3 種公開範圍(所有使用者/僅限組織內部/組織內特定使用者)之間的差異、僅限組織內部時可透過「記錄姓名」記錄回覆者的姓名與電子郵件地址、「每人限一次回覆」也只有在僅限組織內部時才能設定,以及匿名表單不會記錄回覆者的說明。 ↩ ↩2 ↩3 ↩4 ↩5

  5. Microsoft Support, Add questions that allow for file uploads in Microsoft Forms。關於檔案上傳問題僅能在僅限組織內部(僅限組織內部/組織內特定使用者)的設定下使用、單一問題最多 10 個檔案、單一檔案上限可從 10MB、100MB、1GB 中選擇、可限制 Word/Excel/PowerPoint/PDF/圖片/影片/音訊等類型,以及檔案會儲存在 OneDrive for Business 的「應用程式 > Microsoft Forms」之下的說明。 ↩ ↩2 ↩3 ↩4

  6. Microsoft Support, Adjust your form or quiz settings in Microsoft Forms。關於表單設定中列出了接受回覆(Accept responses)、開始・結束日期時間、每人限一次回覆、自訂感謝訊息等項目的說明。 ↩ ↩2

  7. Microsoft Support, Form, question, response, and character limits in Microsoft Forms。關於職場・學校帳戶的表單最多可接收 5,000,000 筆回覆(GCC High/DoD 為 50,000 筆)、每個表單 200 題問題・單一問題文字回答 4,000 個字元・單次回覆的文字回答總計上限 200,000 個字元,以及超過 50,000 筆後摘要圖表・個別回覆檢視・列印等功能將無法使用,僅能透過 CSV 匯出取得的說明。 ↩ ↩2

  8. Microsoft Learn, Troubleshoot known issues with forms in flows。關於單行文字若輸入超過 255 個字元,流程可能無法正常運作,應改用多行文字;核准動作的郵件附件上限為 5MB,超過時核准者需在入口網站確認;以及為承辦人員離職預作準備而移轉表單所有權的說明。 ↩ ↩2 ↩3

  9. Microsoft Support, Use branching logic in Microsoft Forms。關於依回答切換顯示問題・章節的分支設定方式,以及分支目的地只能指定後方問題的說明。 ↩

  10. Microsoft Learn, Common ways to use a form in a flow。關於 Forms 端擁有針對表單擁有者的通知・針對回覆者的確認郵件設定、透過動態內容「Responders’ Email」寄送郵件給回覆者的流程、把回覆內容帶入的核准範本、轉寫至 Excel,以及透過 JSON 的解析拆解上傳檔案的回答、以 first(body(‘Parse_JSON’))?[‘id’] 鎖定檔案並建立共用連結的步驟說明。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  11. Microsoft Learn, Set up Microsoft Forms。關於組織外部使用者會以匿名方式送出回覆、帳戶從租用戶刪除後相關資料會在 30 天後刪除,以及當回覆逼近上限時建議先匯出至 Excel 再清除回覆的說明。 ↩ ↩2 ↩3

  12. Microsoft Learn, Create approval flows with attachments。關於在核准請求中附加檔案時,需要指定附件名稱與二進位編碼的檔案內容的說明。 ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

Microsoft Forms 的檔案上傳問題,組織外部人員也能使用嗎？
不能。檔案上傳問題只有在表單公開範圍設為「僅限本組織內的使用者可回覆」(或組織內特定使用者)時才能新增,若設定為允許組織外部人員回覆,這個問題本身就無法使用。上傳的檔案會儲存在組織的 OneDrive for Business 中,單一問題最多可接收 10 個檔案,單一檔案的上限可從 10MB、100MB、1GB 中選擇。若需要接收組織外部人員的附加檔案,可併用 OneDrive/SharePoint 的檔案要求功能,或考慮開發 Web 表單。
Microsoft Forms 的表單最多可以接收多少筆回覆？
職場或學校帳戶的表單最多可接收 5,000,000 筆回覆(GCC High/DoD 環境為 50,000 筆)。在企業內部申請・請求受理的場景中,幾乎不會因為這個上限本身而遇到困擾,但一旦超過 50,000 筆,摘要圖表顯示與個別回覆檢視等功能就會無法使用,只能透過 CSV 匯出取得資料。此外,由於回覆清單並沒有狀態管理功能,因此不論件數多寡,將受理的請求透過 Power Automate 轉寫至 SharePoint 清單作為台帳管理,才是標準做法。
可以自動記錄表單回覆者是誰嗎？
只要將公開範圍設為僅限組織內部,就能自動記錄。將公開範圍設為「僅限本組織內的使用者可回覆」並啟用「記錄姓名」後,回覆者的姓名與電子郵件地址會與回覆內容一併自動記錄,不需要特意讓對方輸入姓名或所屬單位。「限制每人回覆一次」的選項也只有在僅限組織內部時才能使用。反之,若設為「所有使用者皆可回覆」,回覆就會變成匿名,不會記錄是誰送出的。企業內部申請・請求的受理窗口,原則上應設為僅限組織內部。
申請受理窗口應該用 Forms 還是 SharePoint 清單來製作？
若優先考量填寫者的便利性,選擇 Forms;若優先考量作為台帳的管理,則選擇 SharePoint 清單。Forms 方便從手機填寫,問題分支與必填設定也很簡單,但存在送出後無法編輯、無法確認進度,以及回覆清單管理功能較弱等受理管理面的弱點。實務上採用「用 Forms 受理、再透過 Power Automate 轉寫至 SharePoint 清單」的架構,就能同時兼顧填寫的便利性與台帳管理。若是欄位較多的定型化申請,且所有填寫者都能操作清單,直接用清單的表單受理也是一種選擇。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽