OffboardIT by Stitchflow

作為離職流程軟體，它的招牌能力是觸及身分驗證服務到不了的應用程式。許多系統沒有管理 API，或把開通功能鎖在企業方案後面，SCIM 根本碰不到。Stitchflow 改用瀏覽器代理操作這些主控台。它在本地執行專用的 Chromium 實例，把憑證存進作業系統的鑰匙圈，並使用常駐設定檔，因此自動化操作的就是真人平常會用的同一個主控台。這就是「涵蓋全部應用程式」與「只涵蓋輕鬆的一半」的差別。

Stitchflow 是服務，不是你自行設定的軟體。團隊會盤點你的環境，記錄每一條規則與例外，建好流程，之後隨著應用程式變動持續維護。主控台改版或 API 異動時，由供應商更新整合。對採購方來說，這省掉了自建自動化腳本的通病：寫腳本的人一走，整套就慢慢爛掉。

每次執行都會留下紀錄。服務會為每筆動作加上時間戳，並把離職摘要發布到 Slack 或 Jira，說明處理了哪些人、涵蓋哪些應用程式。這在合規審查時很關鍵，因為重點不是有沒有撤權，而是你能不能證明。有紀錄的摘要可以取代多數團隊慣用的截圖加試算表。

你從團隊原本就在用的工具啟動離職流程。Jira 的一張工單或 Slack 的一則訊息就能觸發，結果也回到同一個地方。服務台人員不必取得每個主控台的管理權限就能完成任務，一線客服也因此不必往上呈報就能處理完整段流程。

離職同時也是支出問題。人走後留下的席次每個月照樣計費。Stitchflow 在同一段流程裡回收授權，所以關閉帳號的流程同時也停掉費用。公司把這項能力與支出分析放在一起談，對財務團隊來說，回收的席次往往是最容易說明這筆服務費值得的地方。

Stitchflow 透過深度 API 整合連接 60 多個應用程式，能讀也能寫，不只是產出報表。服務理解每個應用程式裡角色、群組、最後登入與授權狀態的意義，因此撤權會做對的事，不是只切換一個開關。讀取是預設權限，只有在流程需要時才開放寫入。