一位同仁在手機上送出每日工作填報，畫面卻只回傳一段 JSON。資料沒有壞，壞的是系統把「查無資料」當成了「流程失敗」。
真正消耗時間的，卻是查不到員工時流程中斷、欄位改名後十個地方一起失效，以及手機上看得到卻填不下去。
這不是一篇炫耀節點的文章。我想把 GAS、n8n、Notion 的工具串接，翻譯成主管看得懂的責任分層。
GAS、n8n、Notion 三層架構怎麼分工？
GAS 負責使用者介面，n8n 負責流程與系統串接，Notion 負責資料保存。三層用清楚資料契約連接，故障時才知道該查哪裡。
「三層架構」不是把三個工具排成一條線，而是把顯示、判斷與儲存責任拆開，避免任何一層同時控制所有規則。
- GAS：呈現表單、檢查基本輸入、顯示回應。
- n8n：查詢、判斷、通知、例外與跨系統流程。
- Notion：員工、權限、填報與狀態資料。
很多人以為低程式碼工具接上就容易維護，其實剛好相反。串接越快，欄位與責任越要提早定義。
如果你是主管（或要接手維護的老闆），畫面空白時，你知道是前端沒顯示、流程沒回應，還是資料庫查不到嗎？
Notion Checkbox 怎麼做功能權限控管？
在員工資料庫為每項功能建立權限欄位，登入後由流程讀取狀態，只顯示獲准功能；同時保留後端驗證，不能只靠前端隱藏。
Checkbox 的好處是主管能在資料庫調整權限，不必每次改程式。但欄位只能表示是否允許，仍要另外記錄誰核准、何時變更。
最重要的安全提醒：隱藏按鈕不是授權。n8n 接到請求後仍須再次確認使用者與功能權限，避免有人直接呼叫網址繞過畫面。
權限表每月抽查離職、調職與臨時代理，並避免多人共用同一帳號。方便不該建立一個沒人負責的入口。
n8n 查不到資料時，流程為什麼會停住？
查無結果若沒有明確分支，下游節點可能收不到輸入。應把「零筆資料」設成可預期狀態，回傳空結果與說明，再決定新增或人工處理。
在部分節點可用 Always Output Data 讓流程繼續，但不要只開設定就算完成。下游必須辨認這是一筆空結果，不是正常資料。
n8n 官方執行紀錄文件說明如何查看執行狀態與重試。主管驗收時要確認失敗資料仍可找到，不會只剩使用者看到 JSON 錯誤。
建議測五種輸入：正常員工、不存在員工、停用帳號、欄位缺漏與 Notion 暫時無回應；每種都要定義前端訊息與接手人。
欄位改名為什麼會造成連鎖錯誤？
同一個名稱若散落在資料庫、流程、程式與通知模板，改一處就會失去對應。解法是建立資料字典、固定內部鍵值並管理變更清單。
曾有通知把「七天後」顯示成「七天前」，因為程式直接拆解中文欄位。後來改用 labelMap，內部鍵值和使用者看到的名稱分開管理。
欄位變更依序檢查資料庫、n8n、GAS、HTML、備援表與通知，並用舊資料回歸測試。這份清單應由一位流程負責人簽核。
老闆要看的隱形成本是：改一個字要動幾個地方、幾個人知道關係、漏改一次會影響多少填報。這比工具月費更接近維護真相。
手機填報怎麼驗收，系統才真的有人用？
用實際手機完成一次完整任務，檢查字級、輸入高度、欄位數、折疊與快速索引。驗收指標是能否順利完成，不是桌機縮小後看得到。
每行減少欄位、放大數字、完成區塊可折疊，都是降低第一線操作成本。也要測弱網路、重複點擊與填到一半返回。
這套架構仍要遵守「組織 → 流程 → 表單 → 系統」的順序。可接著看主管如何設計可維護的 n8n 工作流與舊 ERP、Excel 資料孤島怎麼拆。
下次增加功能前，先問：這是現場真正需要的步驟，還是我們只因為工具做得到就加上去？
欄位改名時，怎麼不再靠人腦記十個地方？
把給機器用的內部鍵值與給人看的欄位名稱分開，並用一份資料字典記錄來源、型別、擁有者與下游影響。改名稱前，先改這張字典。
Notion 的屬性有可持續使用的 property ID；名稱會變，識別碼不該跟著被當成文字拆解。Notion 官方屬性文件也說明，讀寫時可以用 ID 取代名稱。
實務上我會先列出「誰提供、誰讀取、誰顯示、誰通知」四種使用點，再依 Notion → n8n → GAS → HTML 的順序測。不是因為這個順序神奇，而是資料從哪裡來，就先從哪裡驗。
你真正要消除的不是欄位改名，而是只有原作者知道哪些地方會一起壞的風險。
