Lorsque votre flux Power Automate interroge une liste SharePoint et que le connecteur renvoie « The required field »Client » data type is not supported », le flux s’arrête net : les sorties dynamiques ne sont plus exposées, bloquant l’ensemble de la logique. Cet article explique en profondeur pourquoi cette erreur apparaît, comment la corriger, et surtout comment éviter qu’elle ne se reproduise.
Vue d’ensemble de l’erreur
L’action Get table (ou List rows present in a table) sert à charger la structure et le contenu d’une liste SharePoint. Elle analyse le schéma retourné par l’API REST v1 pour l’exposer sous forme de sorties dynamiques (cartes). Lorsque l’API détecte une colonne obligatoire d’un type qu’elle ne sait pas sérialiser, elle renvoie un code HTTP 400. Power Automate transforme alors la réponse en message d’avertissement :
Failed to retrieve dynamic outputs.
"The required field "Client" data type is not supported"
Status: 400 (BadRequest)Plusieurs symptômes dérivés sont généralement observés :
- Les étapes en aval ne disposent plus des tokens attendus.
- Le concepteur affiche le pictogramme d’alerte jaune sur l’action.
- Le flux s’exécute tant que le schéma est mis en cache, puis échoue après toute modification de la liste.
Pourquoi la colonne Client pose problème
SharePoint propose plus d’une douzaine de types de colonnes : texte, nombre, date, recherche, personne, hyperlien, métadonnées gérées, etc. Or, toutes ne sont pas prises en charge par le connecteur « SharePoint » de Power Automate dans le contexte précis de l’action Get table. Les cas d’incompatibilité les plus courants sont :
- Personne ou groupe (multi‑valeur) : la propriété est retournée sous forme de tableau complexe que le connecteur ne sait pas convertir.
- Recherche (Lookup) multi‑valeur : idem, l’énumération de valeurs s’accompagne d’un sous‑ensemble d’attributs difficile à aplatir.
- Métadonnées gérées (Taxonomie) multi‑valeur.
- Colonnes de type JSON personnalisé provenant de solutions SPFx ou d’injections côté client.
Si l’une de ces colonnes est marquée « Obligatoire », la requête échoue : SharePoint refuse de renvoyer des lignes dont un champ requis ne peut être rendu.
Tableau récapitulatif des pistes de résolution
| Piste | Détails |
|---|---|
1. Vérifier le type de la colonne Client | Ouvrez Paramètres de la liste ▸ Paramètres de la colonne ▸ Type de colonne. Si la colonne est Personne ou groupe avec valeurs multiples, Recherche multi‑valeur ou MMS, changez‑la pour un type pris en charge (par ex. Une ligne de texte). Sinon, créez une nouvelle colonne compatible et migrez les données à l’aide de la vue Grille modifiable ou d’un script PowerShell. |
| 2. Rendre la colonne non obligatoire | Dans la même page de paramètres, définissez Exiger que cette colonne contienne des informations : Non. Le connecteur pourra alors ignorer la colonne problématique. Attention : toute logique métier SharePoint s’appuyant sur l’obligation devra être reproduite côté flux. |
| 3. Mettre à jour le schéma dans Power Automate | Après la modification côté SharePoint, Enregistrez puis Fermez le flux. Rouvrez‑le, supprimez l’action Get table, recréez‑la, puis reconfigurez les étapes dépendantes. Cette étape force la régénération du schéma mis en cache. |
| 4. Utiliser une requête HTTP | Ajoutez l’action Send an HTTP request to SharePoint et interrogez directement l’endpoint REST :/sites/{site}/_api/web/lists/GetByTitle('Liste')/items?$select=Id,Title,Client/Title&$expand=ClientVous contrôlez alors le select & expand, puis transformez la réponse via Parse JSON. |
| 5. Contrôler les autorisations | Vérifiez que le compte du flux possède les droits Contribuer sur la liste et surtout sur la colonne Client. Un accès restreint peut générer un 400 similaire, bien qu’il s’agisse alors d’un problème de sécurité. |
| 6. Purger le cache du connecteur | Accédez à Data ▸ Connections, supprimez la connexion SharePoint concernée, recréez‑la, puis republiez le flux. Cette opération invalide définitivement les métadonnées obsolètes. |
Détaillons chaque solution
1. Changer le type de la colonne
Le changement de type est la solution la plus pérenne : la colonne devient immédiatement compatible avec l’ensemble des connecteurs Microsoft 365 (Power Automate, Power Apps, Copilot Studio). Voici la procédure pas à pas :
- Dans la liste, ouvrez le menu Paramètres (engrenage) puis Paramètres de la liste.
- Sous Colonnes, sélectionnez
Client. - Choisissez Une ligne de texte (si vous conservez uniquement le nom) ou Nombre/GUID selon la donnée stockée.
- Cliquez sur OK, puis revenez à la liste.
- Utilisez l’affichage Grille modifiable pour copier les valeurs depuis l’ancienne colonne vers la nouvelle.
- Rendez l’ancienne colonne facultative ou masquez‑la dans les formulaires.
2. Rendre la colonne facultative
Lorsqu’il n’est pas possible de changer le type (par exemple une colonne Personne indispensable pour SharePoint), la stratégie consiste à supprimer le caractère « Obligatoire ». Le flux peut alors récupérer les lignes même si la colonne n’est pas comprise. Les validateurs côté liste (Form settings, JSON formatting, column validation) peuvent toujours exiger la valeur lors de l’édition dans SharePoint, sans bloquer l’API REST.
3. Forcer la régénération du schéma dans Power Automate
Power Automate conserve un snapshot du schéma la première fois que vous ajoutez une action. Si vous modifiez la liste après coup, le flux continue d’utiliser l’ancien modèle. Les bons réflexes :
- Supprimer puis recréer l’action problématique.
- Republier le flux à chaque évolution de la liste (ajout, renommage ou suppression de colonne).
- Documenter dans la gouvernance d’équipe qu’un changement de schéma SharePoint doit déclencher un cycle de validation des flux.
4. Remplacer Get table par une requête HTTP ciblée
La requête HTTP est la solution « dernier recours » lorsque la colonne doit rester obligatoire et multi‑valeur. Vous construisez l’URL avec $select pour limiter le nombre de colonnes, et $expand pour récupérer les sous‑propriétés. Voici un modèle complet :
{
"method": "GET",
"uri": "/sites/Commercial/_api/web/lists/GetByTitle('Contrats')/items?" +
"$select=Id,Title,Client/Title,Client/EMail,DateSignature&" +
"$expand=Client"
}Après l’appel, insérez Parse JSON, collez un exemple de charge utile et laissez l’assistant générer le schéma. Vous récupérez ainsi vos sorties dynamiques sans dépendre de la compatibilité du connecteur.
5. Vérifier les autorisations
Un code HTTP 400 peut également masquer un problème d’autorisations :
- Assurez‑vous que le compte du flux est membre d’un groupe ayant Contribuer sur la liste.
- Si vous utilisez un Service Principal (app registration), accordez au moins Sites.ReadWrite.All au niveau du tenant ou du site.
- Contrôlez les permissions fines sur la colonne (fonctionnalité parfois activée via SharePoint Framework).
6. Purger la connexion SharePoint
Si toutes les autres approches échouent, il peut rester un cache obstiné dans la connexion elle‑même. Supprimer la connexion force un handshake OAuth complet et vide le cache des métadonnées internes.
Comment éviter l’erreur à l’avenir ?
La majorité des incidents « data type not supported » provient d’une absence de convention de nommage ou d’une gestion disparate des types dans vos listes SharePoint. Pour sécuriser vos flux :
Mettre en place des conventions de schéma
- Privilégiez les types simples (Single line of text, Number, Yes/No, Date/Time). Gardez les types complexes pour les besoins métier critiques.
- Évitez les colonnes multi‑valeur obligatoires si un flux doit consommer la liste.
- Documentez chaque colonne (description + propriétaire) afin que les administrateurs de flux sachent la modifier en toute sécurité.
Séparation des préoccupations
Créez une seconde liste ou une vue dérivée comportant uniquement les colonnes nécessaires au flux. L’action Get table pointera alors vers cette liste ; les utilisateurs finaux interagiront avec la liste complète.
Automatiser les tests de régression
- Mettez en place un flux de test planifié qui appelle simplement Get table et envoie un e‑mail si l’appel échoue.
- Intégrez les tests dans vos pipelines DevOps lorsqu’un SPFx ou une migration modifie une liste.
Questions fréquentes (FAQ)
Q1. Puis‑je ignorer la colonne dans la requête Get table ?
Non. Contrairement à l’action Get items de l’ancien connecteur, Get table récupère toujours la totalité des colonnes. Il n’existe pas de paramètre $select dans l’action standard.
Q2. L’erreur peut‑elle surgir sur un champ non obligatoire ?
Oui, mais c’est rare. SharePoint refuse parfois un type non pris en charge même lorsqu’il est facultatif si la liste contient des données incohérentes (par ex. valeur JSON dans un champ Texte).
Q3. La même colonne fonctionne dans Power Apps, pourquoi pas dans Power Automate ?
Le connecteur Power Apps utilise l’API v2 (bêta) qui gère mieux les types complexes. Power Automate, lui, reste sur l’API v1 pour des raisons de stabilité.
Q4. Un raccourci dans l’interface permet‑il d’afficher les sorties dynamiques cachées ?
Malheureusement non. Même en basculant en mode Code View, les champs non reconnus ne sont pas exposés.
Résumé et bonnes pratiques
Le message « The required field »Client » data type is not supported » est l’indicateur qu’une colonne obligatoire de votre liste SharePoint utilise un type que l’API REST n’arrive pas à convertir. Pour régler le problème, vous devez soit rendre la colonne compatible, soit la rendre facultative, soit contourner le connecteur via une requête HTTP. Une gouvernance stricte du schéma et des tests automatisés vous prémuniront contre la réapparition de cette erreur.
En appliquant les recommandations ci‑dessus à vos listes et à vos flux, vous éliminerez non seulement cette erreur mais aussi toute une classe de dysfonctionnements difficiles à diagnostiquer. Vous garantirez ainsi une chaîne Power Automate → SharePoint robuste, maintenable et évolutive.