今天想跟你聊一個 Power BI 最近很值得觀察的新方向：Fabric Apps。

不過我不想一開始就跟你介紹功能，因為那樣很容易變成 Microsoft 官方文件整理，讀起來會有點硬，坦白說，也有點無聊。

我想先從一個比較實際的問題開始。

你有沒有遇過這種情況：一張 Power BI 儀表板做完後，使用者確實看得懂數字，也看得出來哪裡有異常。但看完之後，他還是要離開這份儀表板去做對應的決策與行動？

例如：看到客戶流失風險變高，他要去 CRM 更新狀態；看到預算超支，他要去 Teams 問主管要不要調整；看到庫存不足，他要去 ERP 或 Excel 裡面補一段備註。

儀表板本身沒有壞、資料也沒有錯、圖表甚至做得滿漂亮，但整個流程就是斷在那裡。

這空缺也是我覺得 Fabric Apps 值得討論的地方。

它真正有趣的地方，不只是讓畫面變得更像網頁，而是讓我們重新思考一件事：

Power BI 看到問題之後，下一步到底該怎麼被接起來？

今天這篇文章，我會從幾個角度跟你聊 Fabric Apps：

➔ 為什麼傳統 Power BI 很擅長看見問題，但不一定擅長處理問題

➔ 為什麼 Data Write-back 會是很多企業實務上一直想要的功能

➔ Fabric Apps 跟 Power BI Report、Power BI App 到底差在哪裡

➔ 如果真的要學 Fabric Apps，你大概要理解哪些新的工具和流程

➔ 以及，這個東西到底適不適合一般 Power BI 使用者現在就投入

先說結論：

如果你只是想做一張管理報表、看 KPI、看趨勢、切篩選器，那傳統 Power BI 仍然非常夠用。

但如果你的需求已經開始變成：「使用者能不能在看到資料之後，直接填備註、更新狀態、送出審核、寫回資料庫？」

那 Fabric Apps 就開始有討論價值了。

↓

BI 流程裡最常被忽略的，其實是最後一步

我在教學裡常常會用一張「資料流 6 步驟藍圖」來講 Power BI 的完整流程，大致上會是這樣：

1. 資料蒐集
2. 資料清理
3. 資料建模
4. 資料視覺化
5. 資料治理
6. AI 協作

這些步驟當然都很重要。

尤其對剛開始學 Power BI 的人來說，光是把資料清乾淨、關聯建好、DAX 寫對、報表排得讓人看得懂，就已經不是一件輕鬆的事。

但如果你真的在企業裡做過報表，就會慢慢發現一件事：

報表做完，不代表事情就被解決了。

真正有價值的資料分析，不會停在「我看懂這張報表了」。

如果從完整的 BI 流程來看，資料蒐集、資料清理、資料建模、資料視覺化，這些步驟其實都是在把原本混亂、分散、難以理解的資料，一步步整理成使用者看得懂、可以判斷的樣子。

但理解之後呢？

使用者看見問題後，能不能直接在同一個系統畫面裡留下判斷、更新狀態、送出下一步，甚至讓這些處理結果回到資料流程裡，成為下一輪分析的一部分？

這才是很多企業真正卡住的地方。

不是沒有報表、也不是沒有洞察。

而是洞察出現之後，後續行動常常又散落到 Excel、Teams、Email、ERP、CRM，或某個會議結束後才有人補的表格裡。

你說它沒有流程嗎？好像也不是。

只是這個流程沒有真的被接回資料裡。

所以你下一次再看報表時，看到的可能還是「哪裡有問題」，但不一定看得到「誰處理了、怎麼處理、處理後有沒有改善」。

這就是傳統 BI 流程裡很常被忽略的一段。

如果從這個角度看 Fabric Apps，事情就會清楚很多。

它值得被關注的地方，不只是讓報表變得更像網頁，而是它有機會回答一個過去 Power BI 比較不擅長處理的問題：

看見問題之後，使用者能不能直接 在同一個資料畫面 裡，把下一步也做完？

不過在進入 Fabric Apps 之前，我們要先把傳統 Power BI 的位置放清楚：

它到底已經幫我們解決了什麼，又有哪些事情原本就不是它最擅長處理的？

↓

傳統 Power BI 很強，但它主要強在「看見問題」

我先說清楚，這篇不是要說 Power BI 不好。

剛好相反。

Power BI 到現在仍然是我覺得非常強、也非常適合企業使用的分析工具。

如果你的需求是：

➔ 看 KPI 有沒有達標

➔ 看營收、成本、毛利率的變化

➔ 看哪個產品、區域、客戶出問題

➔ 看明細資料

➔ 用篩選器快速切換不同角度

➔ 讓主管和團隊有一個共同的數字基準

那 Power BI 很適合。

尤其對很多原本還在 Excel 裡面複製貼上、拉樞紐、手動更新圖表的人來說，Power BI 已經是一個很大的升級。

資料可以自動更新，模型可以重複使用，DAX 可以把商業邏輯固定下來，視覺化也可以讓使用者自己切角度看資料。

這些都很有價值。

但它的核心還是偏向「讀取資料、分析資料、呈現資料」。

也就是說，它很擅長回答：

➔ 發生了什麼？

➔ 哪裡有異常？

➔ 趨勢怎麼變？

➔ 問題可能來自哪裡？

這些問題都很重要。

只是，在真實工作裡，使用者通常不會停在這裡。

他看完報表後，下一句很常會是：

「那我現在要怎麼處理？」

這句話一出現，Power BI 的限制就開始浮出來了。

↓

真正的缺口，是看完報表後，使用者還是要跳出去做事

很多企業不是沒有報表。

甚至有些公司報表很多，多到你打開工作區後會有點不知道要先點哪一份。

但報表多，不代表流程順。

我看過一些很典型的情境。

例如：業務主管打開客戶分析儀表板，看到某些客戶最近訂單量下降，理論上他應該要追蹤這些客戶，確認是不是價格、交期、競品或服務出了問題。

接下來他要去哪裡填追蹤狀態？

可能是 CRM、也可能是 Excel、也可能是叫業務自己回報。

最後就會變成，Power BI 是一個地方，真正的處理紀錄又在另一個地方。

再例如，財務看到某個部門預算超支，主管想要在同一個畫面裡留下原因說明：

「這筆是專案提前採購，不是異常。」

但 Power BI 本身不是拿來讓你直接輸入註解的地方，所以這段備註可能最後又跑去 Excel、Email，或者某個會議記錄裡。

你如果做過企業報表，應該知道我在說什麼。

有些需求不是分析問題，是流程問題。

使用者不是只想看資料，他是想在看完資料之後，直接完成下一步。

例如：

➔ 填寫註解

➔ 更新處理狀態

➔ 指定負責人

➔ 補上追蹤日期

➔ 送出主管審核

➔ 把結果寫回資料庫

➔ 下次再把這些處理結果拿回來分析

也就是說，使用者真正想要的，不只是多一張圖表，而是讓自己在看完資料後做出的判斷，可以被留下來、追蹤下去，甚至重新回到資料裡。

這就會帶到一個實務上常見的問題：資料回寫（Data Write-back）。

↓

資料回寫不是炫技，而是讓洞察回到流程裡

資料回寫（Data Write-back）這個詞聽起來很技術，但你可以先把它想得很簡單：

使用者不只是看資料，而是可以把他的判斷、備註、狀態或決策結果，寫回某個資料庫，讓這些內容之後還能被追蹤、被分析、被納入下一輪流程。

例如：

➔ 業務看到高風險客戶後，在畫面裡更新「已聯繫客戶」。

➔ 主管看到預算差異後，在畫面裡填「已核准調整」。

➔ 採購看到庫存不足後，在畫面裡標記「下週補貨」。

➔ 客服看到客訴類型後，在畫面裡補上「主要抱怨原因」。

➔ 營運看到異常訂單後，在畫面裡填入「已處理，原因為出貨延遲」。

這些內容如果只是留在 Teams 或 Excel 裡，短期好像沒什麼問題。

但久了之後，你會發現它很難被分析。

你很難知道：

➔ 哪些異常真的被處理了？

➔ 哪些客戶追蹤後有改善？

➔ 哪些主管核准速度比較慢？

➔ 哪些補貨判斷後來是正確的？

➔ 哪些議題反覆出現，代表背後可能有系統性問題？

這就是資料回寫有價值的地方。

它不是為了讓報表變得更炫，也不是為了在 Power BI 裡面硬塞一個輸入框。

它真正解決的是一件很務實的事：

使用者看完資料後做出的判斷，能不能不要散落在各種地方，而是重新回到資料流程裡？

如果能回來，下一次分析就不只是分析「發生什麼」。

你還可以分析「我們怎麼處理」、「處理得怎麼樣」、「哪些處理方式有效」。

這件事一旦接起來，BI 就不只是看板。

它開始比較像一個真的有閉環的工作流程。

不過，這裡也要先潑一點冷水：這個需求很合理，但傳統 Power BI 本來就不是為了大量輸入、更新和寫回資料而設計的。

↓

傳統 Power BI 為什麼不太適合做資料回寫？

Power BI 的核心設計比較像這樣：

1. 把資料整理好
2. 把模型建好
3. 把指標算好
4. 把資訊用視覺化方式呈現給使用者
5. 讓使用者可以篩選、鑽取、分析

這套流程非常適合「看資料」。

但如果你要大量讓使用者在報表裡輸入資料、更新狀態、送出審核、儲存處理結果，Power BI 就會開始有點卡。

因為它本來就不是一套交易型系統，也不是一套工作流程系統。

你當然可以透過其他工具補，例如：Power Apps、Power Automate、SharePoint List、Excel、Dataverse，甚至自己另外做一個網頁系統。

這些方法都有自己的使用場景。

但麻煩的是，當需求越來越複雜，你會開始感覺 Power BI 只是其中一塊，真正的流程被拆到很多地方。

短期、小量資料時不是不能運作，但是當要追蹤數個議題、數個角色、數個處理狀態時，就會很累。

有時候不是資料沒有做起來，是資料一路走到最後，被人手、訊息、備註、Excel、會議紀錄打散了。

所以當我們在討論 Fabric Apps 時，我覺得重點不應該放在「它是不是可以做出更漂亮的畫面」。

那只是表面。

真正值得看的，是它 有沒有機會把 Power BI 原本比較難處理的決策流程（Action ）接起來。

所以問題不是 Power BI 不好，而是當需求從「看資料」變成「操作資料」時，我們需要的已經不是另一張報表，而是一個更像內部工具的介面。

↓

Fabric Apps 可以先理解成「可操作的內部資料工具」

Fabric Apps 這個名字，如果你第一次看到，可能會有點混亂。

因為 Power BI 以前就有 Power BI App。

所以很多人第一反應可能會是：「這是新版 Power BI App 嗎？」

當然不是。

Power BI App 比較像是把已經做好的報表、儀表板等內容整理成一個入口，再發佈給不同受眾。

例如：在工作區裡有銷售報表、財務報表、主管儀表板，想要整理成一個更正式的入口給不同角色使用，Power BI App 很適合。

但 Fabric Apps 更像是：

用 Power BI 背後整理好的資料模型，再加上一個可以操作的網頁介面，做出一個更像內部系統的資料工具。

這裡有一個名詞叫 Semantic Model（語意模型）。

你可能對它感到很陌生，但它其實就是：Power BI 報表背後那整理好的資料模型。

裡面可能包含資料表、關聯、欄位、DAX 指標、商業邏輯，甚至權限設計。

傳統 Power BI 報表會讀取這套模型，然後把它變成儀表板或報表頁面。

Fabric Apps 則是有機會在這套模型旁邊，加上一個更像網頁或內部系統的操作介面。

這個介面可以讓使用者看資料，也可能讓使用者填寫資料、更新狀態、送出結果，並把這些內容寫回某個資料庫。

這裡要特別小心一件事。

Fabric Apps 不是讓你直接把資料寫回 Power BI Semantic Model。

更精準的說法是：

Semantic Model 負責提供可信任的分析資料與商業邏輯。

Fabric Apps 則可以在旁邊加上一層操作介面，讓使用者的輸入、備註、狀態或處理結果寫回資料庫，之後再被納入分析流程。

這樣比喻可能更白話：

Power BI 像是讓使用者打開一張很清楚的檢查表。

Fabric Apps 則有機會讓使用者看完檢查結果後，直接在同一個地方填處理紀錄、標記狀態，甚至送出下一步。

講到這裡，Fabric Apps 的定位就比較清楚了。

它不是來取代 Power BI Report；它比較像是在 Power BI 已經看得到洞察之後，往下一步延伸。

不過，光知道它是什麼還不夠；真正要理解 Fabric Apps 的差異，要看它把一個原本斷掉的流程，怎麼接成一個完整循環。

↓

一個可能的 Fabric Apps 流程：分析、判斷、填寫、寫回、再分析

我們用一個比較具體的例子來看。

假設公司有一份「客戶流失風險」儀表板。

傳統 Power BI Report 可以做到：

➔ 顯示哪些客戶最近訂單下降

➔ 顯示哪些客戶互動頻率變低

➔ 顯示不同業務負責的客戶風險狀態

➔ 顯示客戶歷史購買、客訴、回購週期

➔ 讓主管用篩選器切不同區域、業務、產品線

這些很好。

但問題是，主管看到高風險客戶之後，下一步要去哪裡？

如果他要請業務處理，可能會去 Teams 標註業務。

如果業務處理完，要回報狀態，可能又回到 Excel 或 CRM。

如果主管下週想知道哪些客戶已經處理，哪些還沒處理，又要再去撈另一份資料。

整個流程就變成：

➔ Power BI 負責看見問題。

➔ 其他工具負責處理問題。

➔ 最後處理結果能不能回來分析，看運氣。

如果換成 Fabric Apps 的思維，這個流程可能會變成另一種樣子：

➔ 使用者在同一個畫面看到高風險客戶。

➔ 點進去看風險原因與歷史紀錄。

➔ 選擇處理狀態，例如「已聯繫」、「待追蹤」、「已流失」。

➔ 填寫備註、指定下一次追蹤日期，把這些資料寫回資料庫。

➔ 下一次分析時，再把這些處理結果納入 Power BI 或其他模型裡。

這就形成一個循環：

➔ 看見問題

➔ 判斷原因

➔ 採取行動（資料回寫）

➔ 留下結果

➔ 回到資料

➔ 繼續分析

我覺得這才是 Fabric Apps 真正比較有想像空間的地方。

它讓使用者有機會在洞察出現的那一刻，不用跳出去找下一個工具，而是在同一個資料介面裡把下一步接起來。

這件事如果真的做得好，對企業來說會非常有價值。

因為很多公司最麻煩的地方，不是沒有資料。

是資料和行動中間隔了太多工具、太多人工、太多「等等我再補」。

而你知道的，很多事情只要一進到「等等我再補」，最後通常就是沒有補。

只是，一旦你要做的是這種「可以操作、可以寫回、可以再分析」的流程，就不能再用傳統做報表的方式來看待它。

↓

Fabric Apps 的開發流程，跟 Power BI 不會是同一種玩法

不過，講到這裡也要冷靜一下。

Fabric Apps 聽起來很有想像空間，但它不代表 Power BI 使用者明天打開 Desktop，就可以像新增一張圖表一樣開始做。

它的開發流程跟傳統開發 Power BI 不太一樣。

傳統 Power BI 的流程，很多人應該都很熟：

1. Power BI Desktop 開發報表
2. 發佈到 Power BI Service
3. 設定重新整理和權限
4. 如果有多份報表，就用 Power BI App 統整後發佈給不同受眾

這是一條很典型的 BI 報表開發流程。

你主要在思考的是：

➔ 資料怎麼整理？

➔ 模型怎麼設計？

➔ DAX 怎麼寫？

➔ 圖表怎麼呈現？

➔ 使用者怎麼篩選？

➔ 報表怎麼發佈？

但 Fabric Apps 更接近另一種流程，它比較像：

1. 先確認使用者要完成什麼任務。
2. 準備好 Power BI 背後的資料模型。
3. 建立一個 App 專案。
4. 設計可以操作的畫面。
5. 串接資料來源和寫回資料庫。
6. 處理登入、權限和部署。
7. 之後持續維護這個內部工具。

你會發現，這已經不是「做報表」而已，它開始有一點像 小型應用程式開發。

這也是為什麼我覺得，Fabric Apps 對很多 Power BI 使用者來說，第一個門檻不是某個功能按鈕在哪裡。

真正的門檻是：

你的思考方式要從「我要做哪幾頁報表」，慢慢轉成「使用者在這個工具裡要完成什麼工作」。

這個轉換很重要。

因為如果你還是用做報表的方式想 Fabric Apps，很容易做出一個長得比較像網頁、但本質上還是圖表拼盤的東西。

那就有點可惜了。

也因為玩法變了，學習路線自然也會跟著變；這時候你要補的，就不只是另一個 Power BI 功能，而是一整套比較接近應用程式開發的基本觀念。

↓

如果真的要學 Fabric Apps，大概要補哪些能力？

這裡我會先講得比較白話。

如果你未來真的想摸 Fabric Apps，你可能會開始看到一些以前 Power BI 使用者比較少碰的名詞。

例如：TypeScript、API、GraphQL、Authentication、Hosting。

我知道，光看到這一串，有些人可能已經想關掉文章了（笑）。

所以我們先不要把它想得太可怕。

你可以先這樣理解：

➔ Fabric workspace：放置和管理 Fabric 內容的工作區

➔ Semantic Model：Power BI 背後整理好的資料模型

➔ App 專案：不是一份報表，而是一個應用程式專案

➔ TypeScript：用來寫網頁和應用邏輯的程式語言

➔ API / GraphQL：畫面跟資料之間溝通的方式

➔ Authentication：使用者登入和權限控管

➔ Database：儲存使用者填寫、更新、寫回結果的地方

➔ Deployment：把工具上線，讓使用者真的能用

你不一定要一開始就精通這些東西，但你至少要知道，Fabric Apps 已經不是單純 Power BI Report 的延伸操作。

它比較像是站在 Power BI 和軟體開發中間。

所以我不會建議 Power BI 新手一開始就衝 Fabric Apps。

如果你連 Power Query、資料模型、DAX、篩選器互動、權限概念都還沒熟，直接跳到 Fabric Apps，很容易變成每個名詞都看過，但每個都不真的懂。

不過如果你已經做過不少報表，也開始遇到「報表看得到問題，但使用者能不能直接在這裡處理問題」這類需求，那 Fabric Apps 就值得你先理解概念。

但學習 Fabric Apps 也需要衡量背後需要付出的時間、精力和維運成本。

↓

成本也會不一樣，因為你已經不是只在做報表

既然 Fabric Apps 要處理的問題比較像工作流程，那它的成本也不能用傳統 Power BI 的角度去看。

如果只是做一份普通的管理儀表板，Fabric Apps 不一定比較快。

因為你不只是做圖表，你還要想使用者流程、建立 App 專案、處理畫面互動、串接資料、寫回資料庫、測試部署。

這些都要時間。

所以如果需求只是「我要看本月營收」、「我要看庫存狀況」、「我要看各區業績」，用 Power BI Report 就好，不用為了追新功能硬上 Fabric Apps。

但如果你的需求本來就已經很像內部系統，例如：需要填寫、審核、更新狀態、寫回資料庫，那 Fabric Apps 可能比從零做一套前後端系統更有機會降低成本。

Power BI 的投入主要在資料整理、資料模型、DAX、視覺化和報表互動。

Fabric Apps 還會多出使用者流程設計、前端畫面、資料寫回、登入權限、部署維運。

這就有點像你原本只是要裝潢一個展示間，後來發現你其實要蓋一間可以營業的小店。

展示間只要讓人看懂商品。

小店還要有人流、結帳、庫存、動線、維修、消防，嗯，突然就很多事。

一般 Power BI 使用者可以先理解概念，不一定要馬上實作。

如果你本來就懂一點前端、資料庫或工程開發，那你會更容易進入 Fabric Apps 的思考方式。

但如果你只熟 Desktop 裡的拖拉操作，剛開始一定會覺得不習慣。

這很正常。

Power BI 維護的是報表、模型、資料重新整理和權限。

Fabric Apps 維護的比較像一個小型內部工具，除了模型之外，還有畫面、程式碼、資料庫、寫回邏輯、登入權限、部署流程和後續改版。

這表示 Fabric Apps 給你更多彈性，但這個彈性不是免費的。

你得到更像系統的體驗，也會承擔更像系統的維運責任。

Power BI 的好處是快、穩、好理解，也很適合標準化的分析需求。

Fabric Apps 的彈性更高，可以做出更接近內部系統的體驗，但它也更需要工程化的思維。

所以我的判斷會是：

小需求，用 Power BI Report。

需要整理和分發多份報表，用 Power BI App。

如果需求已經變成看資料、填資料、更新狀態、寫回資料庫，甚至接到流程，那才值得開始評估 Fabric Apps。

但就算你覺得成本可以接受，還有一個很現實的問題：

你的公司環境和授權，真的支撐得起這種導入方式嗎？

↓

授權和使用條件，也不能只用 Power BI Pro 的角度看

如果要實務評估 Fabric Apps，授權和環境條件一定要知道。

傳統 Power BI 通常會牽涉 Power BI Pro、PPU、Premium capacity 或 Fabric capacity。

但 Fabric Apps 更接近 Microsoft Fabric 生態系裡的應用開發能力。

所以它不只是「我有 Power BI Desktop」或「我有 Power BI Pro 授權」就結束了。

你還會需要考慮：

➔ Fabric workspace

➔ Fabric capacity

➔ Tenant setting 是否開放

➔ Semantic Model 的存取權限

➔ 資料庫或 App 相關權限

➔ 組織是否允許使用 Preview 功能

➔ 使用者是否有足夠權限存取模型與 App

這裡我會建議先不要把它想成一般 Power BI 使用者明天就能全面導入的功能。

比較務實的做法是，把它當成進階 BI 團隊、資料團隊或有工程支援的組織可以開始評估的方向。

尤其現在很多 Fabric 能力仍在快速變動，真的要導入前，還是要回到你公司目前的 Microsoft 授權、租戶設定、安全政策和維運能力來看。

所以 Fabric Apps 不是 Power BI Desktop 裡多一個按鈕，它比較像是 Fabric 平台裡的一種應用開發能力。

真正要問的不是「Fabric Apps 好不好」，而是「我現在站在哪個階段，需不需要開始關注它」。

↓

誰該現在關注 Fabric Apps？誰可以先不用急？

如果你是 Power BI 新手，我會建議先不用急。

你現在更重要的是把 Power Query、資料模型、DAX、儀表板設計和基本權限觀念學好。

這些基本功還是核心。

如果你是一般 Power BI 報表開發者，可以先理解概念。

你不一定要馬上打開工具實作，但你要知道 Power BI 未來可能不只停在「做報表給人看」，而是會越來越靠近「讓資料進入工作流程」。

這個趨勢其實滿重要的。

因為它會影響你未來怎麼理解自己的能力邊界。

以前你可能覺得，會清資料、建模型、寫 DAX、做視覺化，就已經很完整。

這當然還是重要。

但如果使用者越來越期待報表接到流程、能更新狀態、能寫回資料、能像內部工具一樣操作，那你就需要開始理解報表之外的東西。

如果這些需求一直出現，Fabric Apps 就不是新玩具，它比較像是一個訊號。

這個訊號在提醒我們：Power BI 的下一階段，可能不只是做更多報表，而是讓報表背後的資料模型，有機會接到真正的工作流程。

↓

Power BI 的下一步，可能是把洞察接到行動

我覺得 Fabric Apps 現在還不適合被過度神化。

它還有很多地方需要觀察，包含功能成熟度、開發流程、授權條件、維運方式，以及企業實際採用時會遇到的限制。

但它代表的方向，我覺得值得重視。

過去 Power BI 很強的地方，是把資料變成洞察。

它讓我們不用再每天手動整理 Excel，不用每次開會前才匆忙更新圖表，也不用每個部門各自拿一份不同版本的數字。

這些價值不會因為 Fabric Apps 出現就消失。

大部分一般分析需求，Power BI 還是很夠用。

需要整理和分發多份內容時，Power BI App 也還是有它的角色。

Fabric Apps 真正值得被拿出來討論的時候，是當需求開始往註解、狀態更新、主管核准、Write-back、工作流程前進。

所以如果你現在正在學 Power BI，我不會建議你因為看到新功能就焦慮。

先把資料模型、DAX、視覺化和使用者需求理解打穩，這些還是核心。

但如果你已經做過不少報表，也開始遇到使用者問你：

「這裡可不可以直接填備註？」

「這裡可不可以更新狀態？」

「這裡可不可以讓主管核准？」

「這裡可不可以寫回資料庫？」

那你就可以開始關注 Fabric Apps 了。

因為這些問題的背後，其實不是報表功能不夠。

而是使用者已經不只想看資料，他們想用資料做事。

而這，才是 Fabric Apps 真正值得投入的時候。

哪邊還能獲得更多資源呢？