Comprendre l’architecture des connecteurs Microsoft Copilot

DESCRIPTION :

Par défaut, Microsoft Copilot ne voit que vos données Microsoft 365 : vos emails Exchange, vos fichiers SharePoint et OneDrive, vos conversations Teams, votre calendrier Outlook. C’est déjà beaucoup, mais en entreprise, vos données ne vivent pas uniquement dans l’écosystème Microsoft. Elles sont aussi dans Salesforce, Confluence, ServiceNow, Jira, des bases de données SQL, des partages de fichiers internes, des applications métier…

Les connecteurs Copilot sont les ponts qui permettent d’étendre la portée de Copilot au-delà de Microsoft 365, en rendant ces données externes accessibles dans les expériences Copilot et Microsoft Search. Depuis mars 2026, ces connecteurs (anciennement appelés « Microsoft Graph Connectors ») ont été considérablement enrichis avec l’arrivée des connecteurs fédérés basés sur le protocole MCP.

Cet article est volontairement théorique : on va comprendre comment ça fonctionne sous le capot avant de passer à la pratique dans les articles 7 et 8. Si vous êtes du genre à vouloir comprendre l’architecture avant de déployer, vous êtes au bon endroit.

Cet article est le sixième d’une série de 10 articles dédiés à Microsoft Copilot sur Infonovice.fr.

Voici le programme complet de la série :

Article 1 : Microsoft Copilot – Comprendre l’IA de Microsoft en 2026
Article 2 : Agent IA vs Assistant IA – Comprendre les nouveaux acteurs de l’IA en entreprise
Article 3 : Licences Microsoft Copilot en 2026 – Le guide complet pour s’y retrouver
Article 4 : Administrer Microsoft Copilot depuis le Microsoft 365 Admin Center
Article 5 : Sécurité et Protection des Données avec Microsoft Copilot
Article 6 (celui-ci) : Comprendre l’architecture des connecteurs Microsoft Copilot
Article 7 : Déployer des connecteurs Copilot préconfigurés – Guide pratique
Article 8 : Créer un connecteur Copilot custom et un serveur MCP
Article 9 : Créer et administrer des agents IA avec Copilot Studio et Agent Builder
Article 10 : Copilot Cowork, Researcher et les fonctionnalités avancées de Frontier
Article Bonus : Checklist de gouvernance Copilot pour l’admin d’un tenant M365

Bonne lecture !

Les deux types de connecteurs

Microsoft 365 Copilot supporte deux modèles de connecteurs fondamentalement différents dans leur architecture. Comprendre cette distinction est essentiel, car elle conditionne le stockage des données, la sécurité, les performances et les cas d’usage.

Les connecteurs synchronisés (Synced Connectors)

C’est le modèle historique, celui qui existe depuis l’époque des « Microsoft Graph Connectors » pour Microsoft Search.

Principe de fonctionnement : Un connecteur synchronisé va crawler (parcourir) une source de données externe, ingérer le contenu et l’indexer dans Microsoft Graph. Les données sont physiquement copiées et stockées dans votre tenant Microsoft 365.

Le flux est le suivant :

Le connecteur se connecte à la source de données (Confluence, Salesforce, base de données SQL, partage de fichiers…) en utilisant les credentials configurées par l’admin.
Il parcourt le contenu selon un planning défini (crawl schedule) : crawl complet initial, puis crawls incrémentaux réguliers.
Pour chaque élément trouvé, il crée un External Item dans Microsoft Graph, avec le contenu, les métadonnées et les ACL (permissions d’accès).
Microsoft Graph effectue une indexation sémantique de ces éléments, les rendant disponibles pour Copilot et Microsoft Search.
Quand un utilisateur interroge Copilot, celui-ci peut retrouver et synthétiser le contenu indexé, en respectant les ACL.

Caractéristiques clés :

Les données sont stockées dans votre tenant Microsoft 365 (dans l’index Microsoft Graph).
Les données sont disponibles même si la source est temporairement hors ligne.
L’indexation est tenant-wide : une seule connexion alimente tous les utilisateurs éligibles.
L’administrateur configure et gère la connexion (credentials admin, pas user).
Supporte les sources cloud (SaaS) et on-premises.
Les données peuvent être périmées entre deux crawls (latence de synchronisation).

Les connecteurs fédérés (Federated Connectors)

C’est le nouveau modèle, annoncé en preview début 2026 et en GA (General Availability) depuis le 20 avril 2026. Les connecteurs fédérés représentent un changement architectural majeur.

Principe de fonctionnement : Un connecteur fédéré ne copie aucune donnée dans Microsoft Graph. À la place, quand Copilot a besoin d’une information, il interroge la source externe en temps réel via le protocole MCP (Model Context Protocol). Les données restent dans leur système d’origine.

Le flux est le suivant :

L’utilisateur pose une question à Copilot qui pourrait nécessiter des données externes.
Copilot identifie qu’un connecteur fédéré pertinent est disponible.
Copilot envoie une requête au serveur MCP du connecteur, en utilisant l’identité et les credentials de l’utilisateur (pas de l’admin).
Le serveur MCP interroge la source de données externe et renvoie les résultats pertinents.
Copilot intègre ces résultats dans sa réponse, avec des citations renvoyant directement vers le contenu dans le système source.

Caractéristiques clés :

Aucune donnée n’est stockée dans votre tenant Microsoft 365.
Les données sont toujours à jour (temps réel, pas de latence de crawl).
Les connecteurs sont fédérés au niveau utilisateur : chaque utilisateur s’authentifie avec ses propres credentials auprès du service externe.
OAuth 2.0 obligatoire pour l’authentification.
Lecture seule : les connecteurs fédérés ne peuvent pas écrire dans le système source.
Activés par défaut dans le tenant (l’admin a une fenêtre de 7 jours pour les revoir avant qu’ils ne soient accessibles aux utilisateurs).

NB : Un point crucial à noter pour la conformité : les données provenant des connecteurs fédérés ne sont pas couvertes par le contrat Microsoft Products and Services Data Protection Addendum (DPA), car ces connecteurs ne stockent ni n’indexent de données client dans les services Microsoft. L’accès aux données se fait en temps réel avec l’identité de l’utilisateur. Avant d’activer un connecteur fédéré, vérifiez les accords contractuels avec le fournisseur tiers concerné (résidence des données, conditions d’utilisation, conformité).

Le tableau comparatif

Caractéristique	Connecteur synchronisé	Connecteur fédéré
Stockage des données	Dans Microsoft Graph (votre tenant)	Dans le système source (rien dans Graph)
Fraîcheur des données	Selon fréquence de crawl (latence possible)	Temps réel
Authentification	Credentials admin (tenant-wide)	Credentials utilisateur (OAuth 2.0)
Périmètre	Tenant-wide (une connexion pour tous)	Par utilisateur
Indexation sémantique	✅ Oui	❌ Non
Sources on-premises	✅ Oui (via Graph Connector Agent)	❌ Non (cloud/SaaS uniquement)
Écriture dans la source	❌ Non (lecture seule)	❌ Non (lecture seule)
Couvert par le DPA Microsoft	✅ Oui (données dans votre tenant)	❌ Non (données restent chez le tiers)
Disponible dans	Copilot Chat, Search, Agents	Researcher, Copilot Chat, Agent Mode Excel
Administration	M365 AC > Copilot > Connectors	M365 AC > Copilot > Connectors (filtre type: MCP)
Statut (avril 2026)	GA	GA (depuis le 20 avril 2026)

NB : Les deux types de connecteurs peuvent coexister dans votre tenant et apparaissent ensemble dans la liste des connecteurs du M365 Admin Center. Vous pouvez les distinguer grâce au filtre « Connector type: MCP » qui identifie les connecteurs fédérés.

Le protocole MCP (Model Context Protocol)

Le Model Context Protocol est au cœur de l’architecture des connecteurs fédérés. Il mérite qu’on s’y attarde, car c’est un standard qui dépasse largement le cadre de Microsoft.

Qu’est-ce que MCP ?

MCP est un protocole ouvert (open standard) qui définit comment un modèle d’IA peut interroger des sources de données externes de manière sécurisée et standardisée. Il a été conçu pour résoudre un problème simple : comment permettre à un LLM d’accéder à des données privées ou dynamiques sans les copier dans son système ?

Si vous connaissez les API REST, pensez à MCP comme une surcouche standardisée qui permet à n’importe quel LLM (GPT, Claude, Gemini,…) de dialoguer avec n’importe quelle source de données de manière uniforme.

Pourquoi Microsoft a adopté MCP

Le choix de Microsoft d’adopter MCP plutôt que de créer un protocole propriétaire est un signal stratégique fort :

Interopérabilité : MCP est supporté par d’autres acteurs (Anthropic, qui est à l’origine du protocole, mais aussi d’autres plateformes). Les serveurs MCP que vous développez pour Copilot pourraient fonctionner avec d’autres clients MCP.
Pas de vendor lock-in : Les organisations ne sont pas enfermées dans un modèle d’intégration propriétaire Microsoft.
Écosystème ouvert : Les éditeurs tiers (HubSpot, Canva, Notion, etc.) peuvent publier un seul serveur MCP compatible avec plusieurs plateformes IA, réduisant leurs coûts de développement.

Comment fonctionne un serveur MCP ?

De manière simplifiée :

Le client MCP (ici, Microsoft 365 Copilot) envoie une requête à un serveur MCP.
Le serveur MCP reçoit la requête, s’authentifie auprès de la source de données avec les credentials de l’utilisateur (OAuth 2.0), interroge la source, et renvoie les résultats au format attendu.
Le client MCP intègre les résultats dans le contexte du LLM pour générer une réponse.

Le serveur MCP est responsable de la traduction entre le protocole MCP et l’API native du service externe. C’est lui qui « parle » la langue du service (API REST Salesforce, API GraphQL GitHub, API Notion…) et traduit les résultats en format MCP compréhensible par Copilot.

NB : Si vous êtes développeur et que vous souhaitez créer votre propre serveur MCP pour connecter une application métier interne à Copilot, nous verrons comment faire dans l’article 8 de cette série.

Microsoft Graph : Le hub central des connecteurs synchronisés

Pour bien comprendre les connecteurs synchronisés, il faut comprendre comment Microsoft Graph indexe et expose les données externes.

L’indexation sémantique

Quand un connecteur synchronisé ingère du contenu dans Microsoft Graph, ce contenu n’est pas simplement stocké comme un fichier brut. Il passe par une indexation sémantique qui va bien au-delà de la recherche par mots-clés classique.

L’indexation sémantique permet à Copilot de :

Comprendre le sens du contenu, pas juste les mots qu’il contient.
Faire des liens entre des contenus qui utilisent des termes différents pour parler du même sujet.
Retrouver des informations pertinentes même quand la question est formulée différemment du contenu source.
Classer la pertinence des résultats en fonction du contexte de la question.

C’est cette indexation sémantique qui fait la force des connecteurs synchronisés par rapport aux connecteurs fédérés : les données indexées dans Graph sont plus facilement « trouvables » par Copilot car elles ont été prétraitées et enrichies.

NB : Les connecteurs fédérés ne bénéficient pas de l’indexation sémantique. Les résultats dépendent de la qualité de la recherche effectuée par le serveur MCP dans le système source.

Les labels sémantiques

Quand vous configurez un connecteur synchronisé (qu’il soit préconfigured ou custom), vous devez définir un schéma qui décrit la structure des données ingérées. Ce schéma utilise des labels sémantiques qui aident Microsoft Graph à comprendre la nature de chaque champ :

iconUrl : l’URL de l’icône représentant le type de contenu.
title : le titre de l’élément (affiché dans les résultats de recherche et les citations Copilot).
url : le lien vers l’élément dans le système source.
content : le contenu textuel principal de l’élément. C’est le champ le plus important pour la qualité du « grounding » (l’ancrage des réponses Copilot dans les données réelles).

Bonne pratique : La propriété content est la clé de la qualité des réponses Copilot basées sur des données externes. Plus le contenu ingéré dans ce champ est riche et pertinent, plus les réponses Copilot seront précises. Microsoft recommande d’y inclure du texte riche (rich text) plutôt que du texte brut.

Les External Items

Chaque élément de contenu ingéré par un connecteur synchronisé est stocké dans Microsoft Graph sous la forme d’un External Item (élément externe). Un External Item contient :

Les propriétés définies dans le schéma du connecteur (titre, contenu, métadonnées, dates…).
L’ACL (Access Control List) qui définit qui peut voir cet élément.
Le content : le corps du texte indexé.

Les External Items apparaissent dans les résultats de recherche Microsoft Search et sont utilisés par Copilot pour le grounding de ses réponses. Quand Copilot cite une source externe dans sa réponse, il affiche un aperçu de l’External Item avec un lien vers le contenu original dans le système source.

Le urlToItemResolver

C’est un détail technique qui a un impact important sur l’expérience utilisateur. Le urlToItemResolver est un mécanisme qui permet à Copilot d’identifier quand un utilisateur partage un lien vers un élément externe (par exemple, un lien Confluence collé dans un chat Teams) et de le résoudre automatiquement vers l’External Item correspondant dans Graph.

Sans urlToItemResolver, Copilot traite le lien comme un lien web ordinaire. Avec urlToItemResolver, Copilot peut afficher un aperçu riche, utiliser les données indexées pour contextualiser, et offrir une expérience plus fluide.

Les connecteurs préconfigurés : La galerie

Microsoft et ses partenaires proposent plus de 100 connecteurs préconfigurés dans la galerie de connecteurs, accessible depuis le M365 Admin Center (Copilot > Connectors).

Connecteurs Microsoft-built (synchronisés)

Ce sont des connecteurs développés et maintenus par Microsoft. Ils couvrent les sources de données les plus courantes en entreprise :

Azure Data Lake Storage, Azure DevOps Wiki, Azure SQL
Confluence Cloud et On-premises
File Share (partages de fichiers Windows)
Jira Cloud
MediaWiki
Salesforce
ServiceNow (Knowledge, Catalog, Tickets)
Oracle SQL, IBM DB2, MySQL, PostgreSQL
Enterprise Websites (sites web internes)
Et bien d’autres…

Connecteurs partenaires (synchronisés)

Des éditeurs tiers proposent également des connecteurs synchronisés, développés et maintenus par l’éditeur partenaire. Exemples : BA Insight, Raytion, Acaviz, etc.

Connecteurs fédérés Microsoft-published

Depuis le 20 avril 2026, des connecteurs fédérés publiés par Microsoft apparaissent dans la galerie avec le type « MCP ». Les premiers connecteurs disponibles au GA incluent :

Canva
HubSpot
Google Calendar
Notion
Linear
Intercom

D’autres connecteurs fédérés seront ajoutés progressivement. Microsoft a annoncé que de nouveaux connecteurs apparaîtront avec un préavis dans le Message Center.

NB : Les connecteurs fédérés sont activés par défaut dans votre tenant. Quand un nouveau connecteur apparaît, l’admin a une fenêtre de 7 jours pendant laquelle le connecteur n’est visible que par les admins, avant d’être accessible aux utilisateurs. Profitez de cette fenêtre pour évaluer chaque connecteur, le désactiver s’il ne correspond pas à vos politiques, ou configurer un staged rollout vers des groupes Entra ID spécifiques.

Les connecteurs « people data »

Un type de connecteur à part mérite d’être mentionné : les connecteurs pour les données de personnes (Copilot connectors for people data).

Ces connecteurs spéciaux sont conçus pour enrichir les profils utilisateurs dans Microsoft 365 en synchronisant des données depuis des systèmes RH (HCM – Human Capital Management). Ils ne fournissent pas du contenu documentaire, mais des informations sur les personnes : compétences, fonction, département, localisation, manager, etc.

L’impact sur Copilot est direct : quand un utilisateur demande « Qui est l’expert en sécurité réseau dans mon département ? », Copilot peut s’appuyer sur les données people enrichies pour fournir une réponse pertinente avec les cartes de profil mises à jour.

Ces connecteurs améliorent la cohérence des identités dans Microsoft 365 et la pertinence des réponses Copilot basées sur le contexte organisationnel.

Le Microsoft Graph Connector Agent (sources on-premises)

Toutes les sources de données ne sont pas dans le cloud. Beaucoup d’entreprises ont des systèmes critiques hébergés en local : des bases de données SQL Server, des partages de fichiers réseau, des Confluence Server, des Jira Data Center, des sites web internes…

Pour ingérer ces données on-premises dans Microsoft Graph, Microsoft fournit le Microsoft Graph Connector Agent : un logiciel à installer sur un serveur de votre réseau local qui fait le pont entre vos sources internes et les API Copilot connectors dans le cloud.

Architecture

Le Graph Connector Agent fonctionne comme un proxy sécurisé :

Il est installé sur un serveur Windows dans votre réseau local (Windows 10/11 ou Windows Server 2016/2019).
Il se connecte à vos sources de données internes via le réseau local.
Il transmet les données de manière sécurisée vers les API Copilot connectors dans le cloud Microsoft.
Le crawl et l’indexation sont déclenchés depuis le M365 Admin Center, mais l’exécution se fait via l’agent local.

Prérequis techniques

OS : Windows 10, Windows 11, Windows Server 2016 ou 2019.
Runtime : .NET Core Desktop Runtime 8.0 (x64).
Matériel : 8 cœurs CPU, 3 GHz minimum. 16 Go de RAM. 5 Go d’espace disque par million d’éléments à indexer.
Réseau : L’agent a besoin d’un accès sortant vers les API Microsoft (HTTPS). Pas besoin d’ouvrir des ports entrants.
Execution Policy : La politique d’exécution PowerShell doit autoriser les scripts signés à distance (RemoteSigned).

Sources supportées via l’agent

Les connecteurs on-premises Microsoft-built qui nécessitent le Graph Connector Agent incluent :

File Share (partages de fichiers SMB)
Confluence On-premises / Data Center
Jira Data Center
Enterprise Websites (sites web internes non accessibles depuis Internet)
SQL Server, Oracle SQL, IBM DB2 (bases de données on-premises)
Bitbucket Server

NB : Le Graph Connector Agent est régulièrement mis à jour par Microsoft. La version actuelle (3.1.21.0, avril 2026) fait 576 Mo. Microsoft recommande de toujours utiliser la dernière version pour bénéficier des correctifs de sécurité et des nouvelles fonctionnalités. Les mises à jour précédentes incluaient un patch de sécurité critique pour les communications inter-endpoints — gardez votre agent à jour.

Les connecteurs dans Copilot Studio (pour les agents)

Les connecteurs ne servent pas uniquement dans l’expérience Copilot Chat ou Microsoft Search. Ils jouent un rôle central dans les agents créés avec Copilot Studio.

Dans Copilot Studio, un connecteur peut être utilisé de deux manières :

Comme source de connaissances (Knowledge)

Vous pouvez ajouter un connecteur synchronisé comme source de connaissances de votre agent. L’agent pourra alors chercher et synthétiser des informations depuis les données indexées par le connecteur. C’est l’équivalent de donner à votre agent l’accès à une bibliothèque de documents externe.

Comme outil d’action (Action)

Les connecteurs Power Platform (différents des connecteurs Copilot, mais complémentaires) peuvent être ajoutés comme outils (actions) dans un agent Copilot Studio. L’agent peut alors exécuter des actions dans des systèmes externes : créer un ticket ServiceNow, mettre à jour un enregistrement Salesforce, envoyer une notification Slack, etc.

NB : Les connecteurs Power Platform (utilisés comme actions dans Copilot Studio) sont différents des connecteurs Copilot (utilisés pour le grounding de données). Les premiers permettent d’agir dans des systèmes externes, les seconds permettent d’y chercher des informations. Ce sont deux mécanismes distincts qui peuvent coexister dans un même agent.

La gestion des connecteurs par l’admin

Gestion des connecteurs synchronisés

Les connecteurs synchronisés sont gérés depuis M365 Admin Center > Copilot > Connectors. L’AI Administrator peut :

Voir la galerie complète des connecteurs disponibles.
Déployer un nouveau connecteur synchronisé (avec création d’App Registration dans Entra).
Voir l’état des connexions actives (statut du crawl, nombre d’éléments indexés, erreurs).
Modifier les paramètres d’une connexion existante (fréquence de crawl, schéma, ACL).
Déclencher un crawl complet manuellement.

Gestion des connecteurs fédérés

Les connecteurs fédérés sont également gérés depuis M365 Admin Center > Copilot > Connectors, mais avec des actions différentes :

Voir tous les connecteurs fédérés publiés par Microsoft dans l’onglet « Your Connections » (filtrer par type: MCP).
Activer ou désactiver chaque connecteur au niveau tenant.
Configurer un staged rollout (déploiement progressif) vers des groupes Entra ID spécifiques.
Bulk-disable tous les connecteurs fédérés via PowerShell (module Connector.Cmd v2.1+), puis réactiver sélectivement les connecteurs souhaités dans l’Admin Center.

Commandes PowerShell pour la gestion en masse :

# Installer le module Connector.Cmd (v2.1 ou supérieur)
Install-Module -Name Connector.Cmd

# Lancer la gestion du toggle fédéré (interactif, authentification admin requise)
Set-FederatedConnectorToggle

Le cmdlet affiche l’état actuel du toggle global et vous propose de choisir entre Enable (activer tous les connecteurs fédérés) et Disable (désactiver tous les connecteurs fédérés). Après avoir désactivé globalement, vous pouvez réactiver individuellement les connecteurs souhaités depuis l’Admin Center.

NB : Le toggle global s’applique automatiquement aux futurs connecteurs fédérés. Si vous le désactivez, les nouveaux connecteurs publiés par Microsoft apparaîtront dans un état désactivé. Si vous le laissez activé, les nouveaux connecteurs suivront le comportement par défaut (activés avec la fenêtre de 7 jours admin-only).

Notification MC1188234 : Connecteurs user-level

La notification MC1188234 annonce une évolution importante : la possibilité de gérer et déployer des connecteurs au niveau utilisateur directement depuis le M365 Admin Center. Jusqu’à présent, les connecteurs synchronisés étaient exclusivement des objets tenant-wide (une seule connexion pour tout le monde). Cette évolution permettra un déploiement plus granulaire, adapté aux besoins de départements ou d’équipes spécifiques.

Conclusion

On a couvert l’essentiel de l’architecture des connecteurs dans cet article. Voici les points à retenir :

Il existe deux types de connecteurs fondamentalement différents : les synchronisés (données copiées dans Graph, indexation sémantique, tenant-wide, latence de crawl) et les fédérés (données en temps réel via MCP, au niveau utilisateur, OAuth 2.0 obligatoire, aucun stockage dans Graph).
Le protocole MCP (Model Context Protocol) est un standard ouvert adopté par Microsoft pour les connecteurs fédérés. C’est un choix stratégique d’interopérabilité.
L’indexation sémantique et les labels sémantiques sont les mécanismes qui rendent les données des connecteurs synchronisés exploitables par Copilot. La qualité du champ content est déterminante.
Le Graph Connector Agent permet d’indexer des sources on-premises dans Microsoft Graph via un agent installé sur un serveur local.
Les connecteurs fédérés sont activés par défaut et en GA depuis le 20 avril 2026. Utilisez la fenêtre de 7 jours admin-only et le staged rollout pour garder le contrôle.
Les données des connecteurs fédérés ne sont pas couvertes par le DPA Microsoft : vérifiez vos accords avec les fournisseurs tiers.
Les connecteurs jouent aussi un rôle clé dans les agents Copilot Studio (comme sources de connaissances ou outils d’action).

Dans le prochain article, on passe à la pratique : déployer un connecteur préconfigured depuis la galerie, étape par étape, en vérifiant son apparition dans Entra ID et en testant le résultat dans Copilot Chat.

Liens utiles :

Copilot connectors overview : https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/overview-copilot-connector
Federated connectors overview : https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/federated-connectors-overview
Manage federated connectors : https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/manage-federated-connectors
Graph Connector Agent : https://learn.microsoft.com/en-us/microsoftsearch/graph-connector-agent
Model Context Protocol (spec) : https://spec.modelcontextprotocol.io/
Galerie de connecteurs : https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/connectors-gallery

Article rédigé en Avril 2026. L’écosystème des connecteurs Copilot évolue rapidement, notamment avec la GA des connecteurs fédérés et l’ajout régulier de nouveaux connecteurs dans la galerie.

Article précédent : [Sécurité et Protection des Données avec Microsoft Copilot] Article suivant : [Déployer des connecteurs Copilot préconfigurés : Guide pratique]

Mots-clés suggérés pour WordPress : Copilot, Connecteurs, Microsoft Graph, MCP, Model Context Protocol, Synced, Federated, Indexation sémantique, Graph Connector Agent, On-premises, External Items, API, SharePoint, Confluence, Salesforce, ServiceNow, Copilot Studio, Power Platform