那次呼叫不在執行紀錄裡

把觸發程序改成 當收到 HTTP 要求時，存檔之後，流程畫面會多出一個可以呼叫的 URL。

第一次從終端機送出請求，HTTP 回傳 202，郵件正常寄出，Teams 卡片也成功出現，接著把其中一個欄位名稱改掉再送一次後收到的是 400。

真正讓人停下來看的地方，是 Power Automate 的執行紀錄裡完全找不到第二次呼叫。

不是流程執行失敗，也不是某個步驟出錯，而是根本沒有產生這一次執行。

原本只是把手動觸發換成 HTTP 觸發，介面上看起來沒有多大差別，但流程在系統裡扮演的角色已經改變，原本只有人在需要時按一下，現在開始有其他系統可以依賴這個入口。

到了這一步，就不能只看流程裡有哪些 Action，還得開始處理三件以前不太需要面對的事情，呼叫端要送什麼、誰可以呼叫，以及這個入口改版之後會不會讓既有呼叫端失效。

目標還是沒變，變的是它不該依賴我記得

前兩天做的流程都還需要人手動啟動。

真正的限制不只是多按一個按鈕，而是整條流程能不能正常發生，仍然取決於有沒有人記得做這件事。只要遇到請假、忘記、交接不完整，當天的摘要可能就直接消失，而且流程本身不會主動告訴任何人今天少了一份。

所以今天調整的只有入口。

郵件還是那封郵件，Teams 卡片也還是那張卡片，流程真正執行的事情幾乎沒有增加。差別在於觸發條件不再綁定某個人在某個時間點記得操作。

但是入口一旦自動化，另一批問題也跟著進來了。

把流程變成可以被呼叫的端點

Power Automate 的觸發方式，大致可以從使用情境理解成三類。資料或事件發生變化時啟動，時間到了自動啟動，以及收到外部呼叫時啟動。

第三種情況就會用到 When an HTTP request is received。

它讓這條流程擁有一個 HTTP 入口，所以只要能發出 HTTPS 請求，就有機會成為流程的上游。可能是排程程式、既有系統的 webhook、自己寫的程式，也可能是另一條 Power Automate 流程。

很多跨系統整合，其實就是從這裡開始。

不過入口一打開，有幾個原本藏在手動按鈕後面的問題也會立刻浮出來。

第一個是 資料契約。

Request Body JSON Schema 一旦填下去，就代表呼叫端必須按照這個格式送資料。如果 schema 要求的是 reportDate，送進來的卻是 report_date，請求可能直接在觸發層被擋下來並回傳 400。

這也解釋了前面那筆消失的呼叫。

它甚至還沒有進入流程，所以執行紀錄自然不會留下失敗紀錄。

第二個是 授權。

Request 屬於 premium 能力，所以在真正設計之前，環境目前擁有什麼授權必須先確認。這和流程邏輯本身沒有關係，卻可能直接決定這個做法能不能使用。

第三個則是 誰有資格敲這扇門。

這個 HTTP 觸發程序可以設定不同的認證範圍。畫面上看到的差異只是幾個選項，但它們決定的是外部請求到底要帶什麼身分，以及拿到 URL 之後是否就足以呼叫流程。

其中 Anyone 最容易測試，但風險也最直觀。只要 URL 被其他人取得，就可能成為呼叫這條流程的入口。

這也是介面操作和用自然語言讓生成式 AI 建流程時，很容易忽略的一個差異。

在設計介面裡，認證方式會直接攤成幾個選項，至少會看到自己現在選了哪一個。但如果只是用 prompt 描述需求，沒有明確寫出認證模式，最後很可能直接採用當下的預設值。

問題不一定出在 AI 選錯，而是描述裡根本沒有把這個決定寫進去。

兩個出口之後，開始出現部分成功

今天的流程有兩個輸出，一封 Outlook 郵件，加上一張 Teams Adaptive Card。

這時候會出現前面幾天還沒有真正碰到的情況。

郵件寄成功，但 Teams 卡片失敗，這次流程到底算成功還是失敗。

這就是 Day 14 提過的 部分成功。當兩個 Action 都存在時，除了決定它們做什麼，還必須決定彼此之間有沒有相依關係。

這裡沒有一個所有情況都適用的接法。

真正要避免的是根本沒有做這個決定，直到某一天其中一個出口失敗，才第一次發現兩個 Action 原來被綁在一起。

今天可以做的一件事

最省事的一句是這個：

把那條流程的手動觸發換成 HTTP 觸發。

換得掉，十秒就好。換完之後那個 URL 誰能用、送錯格式會怎樣、兩個出口哪個先，這三件事它不會問你。

第一段：入口換成 HTTP

我要在 Power Automate 建一條流程，請使用 Power Automate plugin 執行。
在你開始建立之前，先把【建立前的回報】做完，我確認之後你才動手。

【環境】
環境名稱：<填入你的環境顯示名稱>
流程名稱：Day19-HTTP觸發-值班摘要雙出口
建立後保持停用狀態，不要自行啟用。

【觸發程序】
使用「When an HTTP request is received」（當收到 HTTP 要求時）。
- 方法：POST
- Who can trigger the flow：Any user in my tenant
- Request Body JSON Schema 使用下面這一段，不要增減欄位：

{
  "type": "object",
  "properties": {
    "reportDate":     { "type": "string" },
    "failedJobCount": { "type": "integer" },
    "summary":        { "type": "string" }
  },
  "required": ["reportDate", "failedJobCount", "summary"]
}

【動作】
兩個動作，彼此獨立，請用並行分支，不要串成順序：
1. Office 365 Outlook 的 Send an email (V2)
   - 收件者：<填入一個固定信箱>
   - 主旨、內文的組法與 Day17 那條流程相同，
     值改為取自 HTTP 要求主體的對應欄位
2. Microsoft Teams 的「Post adaptive card in a chat or channel」
   - Team／Channel：我會在對話中回答，先問我
   - 卡片 JSON 與值的注入方式，與 Day18 那條流程相同

【不要做的事】
- 不要加入回應動作（Response），這一版先不回傳內容給呼叫端
- 不要加入我沒有列出的條件、變數、迴圈或錯誤處理
- 不要修改上面那段 schema

【建立前的回報】
1. 這個觸發程序的授權層級是否為 premium，以及它對我這個環境的意義
2. 建立之後那個 HTTP URL 何時才會出現，它是否包含任何形式的密鑰
3. 認證模式設為 Any user in my tenant 時，呼叫端的請求需要帶什麼，
   aud claim 應該是什麼值
4. 我沒有明講、但你必須自己決定才能建起來的每一項，逐項列出

【驗收】
建立完成後，把 HTTP URL 給我，並告訴我一個可以在終端機直接執行的
呼叫範例，含取得 token 的步驟。

第 3 項的答案要自己驗，不要只看它講的。公開雲的 audience 值是 https://service.flow.microsoft.com/，而官方特別註明結尾那個斜線是必須精確相符的。取到 token 之後貼到 jwt.io 看一眼 aud，對不上就調整取 token 時的 resource 參數。

你手上已經有 az CLI，因為裝 plugin 的時候就裝了。這是今天唯一不需要另外準備的東西。

第二段：故意送錯，看它去了哪裡

我要對這條流程做兩次呼叫，請先預測結果，再實際執行。

第一次：主體為
{"reportDate":"2026-10-03","failedJobCount":3,"summary":"三個批次未完成"}

第二次：主體為
{"report_date":"2026-10-03","failedJobCount":3,"summary":"三個批次未完成"}

請先回答：
1. 兩次呼叫分別會得到什麼 HTTP 狀態碼？
2. 第二次的請求，會不會在這條流程的執行紀錄中留下一筆？
   如果不會，我要在哪裡才看得到這次呼叫曾經發生過？
3. 如果第二次是由一支每天早上自動執行的程式發出的，
   而它沒有檢查回應碼，這件事要多久才會被發現？

三題答完再實際執行兩次，把實際狀態碼與執行紀錄跟你的預測對照。

第 2 題是今天最值得停下來的地方。這條流程「出錯沒人看到」的程度，比昨天那張壞掉的卡片更深一層。卡片至少留下一次執行紀錄，schema 擋掉的請求連紀錄都沒有，因為對 Power Automate 來說，那次呼叫根本沒有變成一次執行。

第 3 題沒有技術答案。它的答案是組織上的：取決於有沒有人每天早上會看那個頻道，並且在卡片沒出現的時候問一句。而那正是昨天把出口搬到頻道換來的東西。

兩天連起來看會很清楚。昨天用一群人的注意力補上了流程看不見的那一層，今天入口一自動化，那一層就變成唯一的一層。

第三段：把入口的決定寫下來

這條流程現在有一個對外的入口。請幫我把下面五項整理成一份簡表，
每一項都要寫出這條流程目前的實際設定，不要寫建議做法：

1. 誰可以呼叫它，依據是什麼設定
2. 它接受什麼格式，不符合時發生什麼事
3. 呼叫端會不會知道流程後續是否成功
4. 兩個出口其中一個失敗時，整體狀態是什麼，另一個會不會受影響
5. 這個 URL 如果外流，最壞的情況是什麼

第 5 題請以目前的認證模式回答，不要假設我會改成更嚴格的設定。

這張表存起來。它是這條流程第一份對外文件，而明天就會有人照著它來呼叫。

認證模式的功能官方註明正在推出中，可能尚未在所有區域提供。這一天的行為以 2026/09 查核為準，實際選項請以你環境當日的畫面為主。

留到明天的問題

入口開好了，可是現在唯一會呼叫它的還是我，用終端機，手動貼一段 JSON。

真正該打進來的那一端在地端。而那台機器上的資料庫，雲端本來就連不到。

今天做的事只是把門打開。明天要處理的是：門外那個人怎麼走進來，以及他手上那批資料進得來嗎。

目標還是沒變，變的是它不該依賴我記得

前兩天的流程都要有人按。這件事的問題不在麻煩，在於這條流程的可靠度上限，等於我每天早上記得按它的機率。

今天要改的是入口。改完之後流程的能力一樣沒有增加，但它不再需要我在場。拿掉這次改動會怎樣？我請假那天就沒有摘要，而且沒有任何人會收到「今天沒有摘要」這個訊息。

代價會立刻出現，而且不只一個。

那個可以當成 API 的觸發節點

觸發程序大致分三類：事件型（有東西變動）、排程型（時間到）、呼叫型（有人來敲門）。第三類只有一個，就是「當收到 HTTP 要求時」，而它做的事是把這條流程變成一個 HTTP 端點。

換句話說，任何能發出 HTTPS 請求的東西都可以成為這條流程的起點：排程器、既有系統的 webhook、一支自己寫的程式，或另一條流程。整合就是在這一格發生的。

代價是三件同時出現的事。

**契約。**Request Body JSON Schema 一填，這條流程就有了對外的資料格式。schema 不符的請求會在觸發層被擋掉並回 400，而那不是一次失敗的執行，是一次沒有發生的執行。開頭那個消失的呼叫，來歷就在這裡。

**授權。**Request 屬於 premium 連接器，用它之前先確認環境的授權涵蓋範圍，這一格跟技術無關，但它會決定你能不能走到今天這一步。

**入口的看門人。**這個觸發程序有三種認證模式，而且預設值已經不是最寬鬆的那一種。

第三種最好測，而它的意思是：那個 URL 外流，等同於那條流程外流。

今天介面與 plugin 的差異就落在這一格。在介面裡它是一個下拉選單，三個選項攤在眼前，你至少知道自己選了什麼；在 prompt 裡，你不指定它就用預設值，而你不會收到任何提醒。下拉選單是一份選項清單，prompt 沒有清單。

兩個出口，一個新問題

今天的出口是前兩天的總和：一封信加一張卡片。這會冒出一個前面沒遇過的問題，信寄出去了、卡片失敗了，這一次算成功嗎？

這是 Day 14 提過的部分成功，現在它有了具體位置。兩個動作有兩種接法，而選哪一種是一個要寫下來的決定。

沒有哪一種是對的。有問題的是沒有選過。

今天可以做的一件事

最省事的一句是這個：

把那條流程的手動觸發換成 HTTP 觸發。

換得掉，十秒就好。換完之後那個 URL 誰能用、送錯格式會怎樣、兩個出口哪個先，這三件事它不會問你。

第一段：入口換成 HTTP

我要在 Power Automate 建一條流程，請使用 Power Automate plugin 執行。
在你開始建立之前，先把【建立前的回報】做完，我確認之後你才動手。

【環境】
環境名稱：<填入你的環境顯示名稱>
流程名稱：Day19-HTTP觸發-值班摘要雙出口
建立後保持停用狀態，不要自行啟用。

【觸發程序】
使用「When an HTTP request is received」（當收到 HTTP 要求時）。
- 方法：POST
- Who can trigger the flow：Any user in my tenant
- Request Body JSON Schema 使用下面這一段，不要增減欄位：

{
  "type": "object",
  "properties": {
    "reportDate":     { "type": "string" },
    "failedJobCount": { "type": "integer" },
    "summary":        { "type": "string" }
  },
  "required": ["reportDate", "failedJobCount", "summary"]
}

【動作】
兩個動作，彼此獨立，請用並行分支，不要串成順序：
1. Office 365 Outlook 的 Send an email (V2)
   - 收件者：<填入一個固定信箱>
   - 主旨、內文的組法與 Day17 那條流程相同，
     值改為取自 HTTP 要求主體的對應欄位
2. Microsoft Teams 的「Post adaptive card in a chat or channel」
   - Team／Channel：我會在對話中回答，先問我
   - 卡片 JSON 與值的注入方式，與 Day18 那條流程相同

【不要做的事】
- 不要加入回應動作（Response），這一版先不回傳內容給呼叫端
- 不要加入我沒有列出的條件、變數、迴圈或錯誤處理
- 不要修改上面那段 schema

【建立前的回報】
1. 這個觸發程序的授權層級是否為 premium，以及它對我這個環境的意義
2. 建立之後那個 HTTP URL 何時才會出現，它是否包含任何形式的密鑰
3. 認證模式設為 Any user in my tenant 時，呼叫端的請求需要帶什麼，
   aud claim 應該是什麼值
4. 我沒有明講、但你必須自己決定才能建起來的每一項，逐項列出

【驗收】
建立完成後，把 HTTP URL 給我，並告訴我一個可以在終端機直接執行的
呼叫範例，含取得 token 的步驟。

第 3 項的答案要自己驗，不要只看它講的。公開雲的 audience 值是 https://service.flow.microsoft.com/，而官方特別註明結尾那個斜線是必須精確相符的。取到 token 之後貼到 jwt.io 看一眼 aud，對不上就調整取 token 時的 resource 參數。

你手上已經有 az CLI，因為裝 plugin 的時候就裝了。這是今天唯一不需要另外準備的東西。

第二段：故意送錯，看它去了哪裡

我要對這條流程做兩次呼叫，請先預測結果，再實際執行。

第一次：主體為
{"reportDate":"2026-10-03","failedJobCount":3,"summary":"三個批次未完成"}

第二次：主體為
{"report_date":"2026-10-03","failedJobCount":3,"summary":"三個批次未完成"}

請先回答：
1. 兩次呼叫分別會得到什麼 HTTP 狀態碼？
2. 第二次的請求，會不會在這條流程的執行紀錄中留下一筆？
   如果不會，我要在哪裡才看得到這次呼叫曾經發生過？
3. 如果第二次是由一支每天早上自動執行的程式發出的，
   而它沒有檢查回應碼，這件事要多久才會被發現？

三題答完再實際執行兩次，把實際狀態碼與執行紀錄跟你的預測對照。

第 2 題是今天最值得停下來的地方。這條流程「出錯沒人看到」的程度，比昨天那張壞掉的卡片更深一層。卡片至少留下一次執行紀錄，schema 擋掉的請求連紀錄都沒有，因為對 Power Automate 來說，那次呼叫根本沒有變成一次執行。

第 3 題沒有技術答案。它的答案是組織上的：取決於有沒有人每天早上會看那個頻道，並且在卡片沒出現的時候問一句。而那正是昨天把出口搬到頻道換來的東西。

兩天連起來看會很清楚。昨天用一群人的注意力補上了流程看不見的那一層，今天入口一自動化，那一層就變成唯一的一層。

第三段：把入口的決定寫下來

這條流程現在有一個對外的入口。請幫我把下面五項整理成一份簡表，
每一項都要寫出這條流程目前的實際設定，不要寫建議做法：

1. 誰可以呼叫它，依據是什麼設定
2. 它接受什麼格式，不符合時發生什麼事
3. 呼叫端會不會知道流程後續是否成功
4. 兩個出口其中一個失敗時，整體狀態是什麼，另一個會不會受影響
5. 這個 URL 如果外流，最壞的情況是什麼

第 5 題請以目前的認證模式回答，不要假設我會改成更嚴格的設定。

這張表存起來。它是這條流程第一份對外文件，而明天就會有人照著它來呼叫。

認證模式的功能官方註明正在推出中，可能尚未在所有區域提供。這一天的行為以 2026/09 查核為準，實際選項請以你環境當日的畫面為主。

留到明天的問題

入口開好了，可是現在唯一會呼叫它的還是我，用終端機，手動貼一段 JSON。

真正該打進來的那一端在地端。而那台機器上的資料庫，雲端本來就連不到。

今天做的事只是把門打開。明天要處理的是：門外那個人怎麼走進來，以及他手上那批資料進得來嗎。