不建議或支援從 Power Query 連線到 Microsoft Graph REST API 。 相反地，我們建議用戶探索基於 Graph 的分析資料擷取替代方案，例如 Microsoft Graph Data Connect。
你可能會發現某些 REST 呼叫 Microsoft Graph API 端點能透過 Web.Contents 或 OData.Feed 函式運作，但這些方法長期來看並不可靠。
本文說明了與 Power Query 連接 Microsoft Graph 連線的問題，並說明為何不建議使用。
Authentication
Power Query Web.ContentsOData.Feed 內建的組織帳戶認證流程與大多數 Graph 端點不相容。 具體來說，Power Query 的 Microsoft Entra ID 用戶端會請求該 user_impersonation 範圍，但這與 Graph 的安全模型不相容。 Graph 使用了一套豐富的權限，這些權限是我們通用的 Web 和 OData 連接器無法取得的。
基於安全考量，不建議直接從查詢中實作 Microsoft Entra ID 憑證擷取流程，或使用硬編碼或內嵌憑證。
OData 函式庫的不相容性
某些 Graph 端點及擴充功能可能需要使用 OData 函式庫與功能，但這些功能不被 Power Query 內建 OData.Feed 函式支援，因為 Graph 與 Power Query 可能使用兩個不同版本的 OData 函式庫。 這些問題通常會導致檢索服務文件時 $metadata 出現錯誤。 你可能會發現常見的指引，就是將選項傳 Implementation = "2.0" 給 OData.Feed 函式呼叫，以確保使用最新支援的 OData 函式庫。 雖然這種方法確實解決了某些 OData 不相容的問題，但隨著時間推移，Graph 和 Power Query 在不同時間採用 OData 函式庫的新版本時，仍可能遇到錯誤。
Performance
Microsoft Graph API 設計支援多種應用場景，但對於大多數分析場景所需的大規模資料檢索來說，表現不佳。 如果你嘗試從 Graph API 取得大量資料，可能會遇到效能問題。 關於情境適用性的詳細資訊可參考 圖譜文件。
使用自訂連接器
部分 Power Query 使用者已透過自訂連接器啟用 Graph 連接，功能限制於 Graph API 的某些部分。 此方法允許連接器開發者透過定義帶有 Graph 特定權限的 Microsoft Entra ID 用戶端來解決一般認證問題。 部分自訂連接器透過在連接器邏輯中使用 Web.Contents 並模擬 OData 支援來繞過 OData 挑戰。 然而，這種做法並不被建議，因為使用者經常會遇到上述的效能與可擴展性問題。 採取此路線的開發者應繼續考慮這些限制。