Run As — identité du workflow
Configurez l'identité sous laquelle un workflow s'exécute, en déléguant éventuellement l'exécution à un compte de service doté d'identifiants OAuth liés.
Par défaut, chaque workflow s'exécute sous l'identité du propriétaire du workflow — l'utilisateur qui a enregistré en dernier une version promue. Run As permet à un administrateur d'organisation de fixer à la place un compte de service précis comme identité d'exécution. Les comptes de service sont des identités machine non humaines, dotées d'un ensemble déclaré de portées de capacités et, en option, d'un identifiant OAuth lié par produit d'intégration.
Pourquoi Run As ?
| Cas d'usage | Ce que cela résout |
|---|---|
| Automatisations planifiées qui appellent une intégration (Gmail, Jira, …) | Les jetons OAuth rattachés à un utilisateur réel expirent ; l'identifiant d'un compte de service persiste jusqu'à sa révocation explicite |
| Déploiements multi-environnements | Chaque environnement lie son propre compte de service avec l'accès correctement délimité, sans partager de sessions utilisateur |
| Clarté de l'audit | Les journaux d'exécution affichent service_account comme type d'acteur, ce qui vous permet de distinguer les exécutions automatisées de celles déclenchées par un humain |
| Workflows soumis à habilitation | Les comptes de service peuvent détenir une habilitation BLP, de sorte qu'un workflow peut opérer à un niveau de classification que le propriétaire ne détient pas personnellement — au niveau pour lequel il a été accrédité, revérifié à chaque exécution |
Identifiants personnels et identifiants de compte de service
Lorsqu'un bloc d'intégration résout un identifiant, le modèle d'accès dépend du type de compte :
| Type de compte | Accès aux espaces de travail |
|---|---|
| Compte connecté personnel (appartenant à l'utilisateur qui agit) | Utilisable dans chaque espace de travail auquel appartient le propriétaire — aucune attribution par espace de travail n'est requise |
| Identifiant du portefeuille d'un compte de service | Doit être explicitement lié à chaque espace de travail par un administrateur d'organisation avant de pouvoir être utilisé |
Si vous connectez un compte OAuth personnel (par exemple votre propre compte Google Workspace) et que le Run As du workflow est défini sur Propriétaire du workflow, ce compte est immédiatement disponible dans tout espace de travail dont vous êtes membre — chaque bloc du workflow suit l'exécution, il n'y a donc rien de plus à configurer sur le bloc lui-même.
Les comptes de service nécessitent l'étape supplémentaire du portefeuille décrite ci-dessous, qui donne aux administrateurs d'organisation un contrôle explicite sur les identifiants actifs dans chaque espace de travail.
Identifiants de compte de service (le portefeuille)
Avant qu'un compte de service puisse se substituer à une session utilisateur OAuth, vous devez lui lier le compte OAuth. Seuls les administrateurs d'organisation peuvent gérer le portefeuille.
Connectez le compte OAuth. Accédez à Paramètres → Compte → Comptes connectés et connectez un compte OAuth (par exemple Google Workspace). Cela crée un compte OAuth personnel dans la liste des comptes de l'organisation.
Ouvrez la fiche de détail du compte de service. Accédez à Paramètres → Organisation → Membres, ouvrez l'onglet Comptes de service et cliquez sur la ligne du compte de service à configurer.
Liez l'identifiant.
Dans la section Portefeuille d'identifiants, cliquez sur Lier, sélectionnez le compte OAuth connecté dans la liste déroulante et saisissez l'ID de produit (par exemple org:scrydon:google:gmail). Vous trouverez l'ID de produit sur la page de détail de l'intégration, dans le panneau Intégrations.
L'ID de produit est propre au fournisseur — lier org:scrydon:google:gmail rend ce compte OAuth disponible lorsque le workflow a besoin d'accéder à Gmail ; cela n'affecte pas les autres produits Google.
Répétez l'opération pour chaque produit dont le workflow a besoin. Un même compte de service peut détenir simultanément des identifiants pour plusieurs produits.
Le portefeuille n'a pas de limite de taille : le sélecteur Run As et la fiche du compte de service lisent tous les identifiants liés, quel que soit le nombre de comptes de service et de produits de l'organisation.
Configurer Run As sur un workflow
Les paramètres d'exécution de la fiche Déploiements du workflow définissent l'identité par défaut persistante pour toutes les exécutions automatisées et planifiées. Ce paramètre est propre à chaque environnement : chaque environnement du pipeline de déploiement (Development, Production, …) détient sa propre copie du workflow et sa propre liaison Run As ; la fiche liste donc une ligne par environnement déployé, chacune indiquant l'identité sous laquelle il s'exécute actuellement.
- Ouvrez le workflow dans l'éditeur.
- Cliquez sur Deploy (le bouton affiche Versions une fois tout déployé) pour ouvrir la fiche Déploiements.
- Sous Paramètres d'exécution, cliquez sur la ligne de l'environnement à modifier. Le panneau de détail nomme cet environnement dans son titre.
- Sélectionnez un compte de service dans la liste déroulante Run As ou choisissez Propriétaire du workflow (la valeur par défaut).
- Cliquez sur Enregistrer. Seul cet environnement change ; les autres conservent leur liaison.
Un environnement qui n'a jamais été déployé n'a pas encore de ligne — sa première promotion initialise la liaison à partir de l'environnement source (voir Comportement lors de la promotion), et la ligne apparaît ensuite.
L'habilitation que détient un compte au moment où vous l'enregistrez est consignée avec la liaison. Si quelqu'un relève ensuite l'habilitation de ce compte, les exécutions de ce workflow s'arrêtent avec une erreur nommant les deux niveaux, jusqu'à ce qu'une personne habilitée à accréditer le compte à sa nouvelle habilitation enregistre de nouveau le paramètre. Abaisser l'habilitation d'un compte ne bloque jamais une exécution.
La liste déroulante n'affiche que les comptes de service accrédités pour ce workflow — le rang d'habilitation BLP du compte de service doit être supérieur ou égal à la classification la plus élevée de toute base de connaissances ou de tout document auquel le workflow accède. Les options non accréditées sont affichées mais désactivées.
Seul un compte de service créé avec une habilitation de sécurité peut être choisi : Scrydon détient le secret de ce compte et s'en sert pour se connecter à chaque exécution. Un compte créé sans habilitation est listé mais désactivé, avec le motif affiché à côté de son nom.
Un compte de service doit également être membre de l'espace de travail du workflow avant de pouvoir être lié. Le menu Run As à côté du bouton Run ne liste que les comptes de service affectés à cet espace de travail, et son entrée Configurer les comptes de service… ouvre les paramètres des membres de l'espace de travail pour que vous puissiez en ajouter un.
Son environnement doit lui aussi correspondre. Un compte défini sur Tous les environnements s'exécute partout ; un compte limité à certains environnements ne s'exécute que dans ceux-ci. Un compte dont l'accès ne nomme que prd ne peut pas exécuter un workflow dans dev : chaque appel qu'il y ferait serait refusé. Le sélecteur, la boîte de dialogue Configurer l'exécution et le menu Run As listent tous un tel compte comme désactivé, avec un court motif à côté de son nom (« Limité à un autre environnement »). L'explication complète, y compris la raison pour laquelle lier un identifiant ne peut pas aider, figure dans l'indicateur Identity du bloc. Son indicateur d'identité affiche hors périmètre plutôt que prêt, car aucune identité qu'il détient n'est utilisable dans cet environnement. Pour l'utiliser, modifiez l'accès du compte sous Paramètres → Organisation → Membres → Comptes de service.
Vous pouvez remplacer le paramètre persistant pour une seule exécution manuelle sans modifier la configuration enregistrée du workflow :
- Dans l'éditeur de workflow, cliquez sur la flèche déroulante à côté du bouton Run.
- Sélectionnez Configurer l'exécution.
- Dans le champ Run As, sélectionnez un compte de service (ou Aucun — utiliser la valeur par défaut pour hériter du paramètre enregistré du workflow).
- Cliquez sur Run.
Le remplacement ne s'applique qu'à cette exécution. L'exécution suivante hérite de nouveau du paramètre enregistré du workflow.
Les remplacements par exécution nécessitent une session de navigateur active et sont soumis au même contrôle d'accréditation que le paramètre persistant — vous ne pouvez choisir qu'un compte de service dont vous êtes autorisé à accréditer l'habilitation.
Les déclencheurs webhook, planification et API n'acceptent jamais de remplacement : un jeton de déclencheur prouve la possession d'un secret, et non une personne ; il ne peut donc pas désigner une identité. Ces exécutions agissent toujours sous le Run As enregistré du workflow (le propriétaire lorsqu'aucun n'est défini). Pour démarrer une exécution en tant que compte de service précis depuis un système externe, appelez le déclencheur API du workflow en vous authentifiant avec les propres identifiants de ce compte de service — l'identité provient alors de l'identifiant, et non d'un champ de la requête.
Chaque bloc suit l'exécution
Un bloc ne nomme pas de compte. Il n'y a qu'une seule réponse à la question de savoir sous quelle identité il agit : celle sous laquelle l'exécution s'effectue. Cliquez sur Run et chaque bloc du workflow agit en votre nom. Passez à Run as ▾ (un compte de service) et chaque bloc agit en tant que ce compte de service. Promouvez le workflow vers un environnement doté de sa propre identité Run As, et chaque bloc agit sous l'identité de cet environnement lorsque le déclencheur de planification, webhook ou API le lance.
Il n'existe aucun remplacement par bloc ni aucun moyen de fixer un bloc sur un compte différent de celui sous lequel l'exécution s'effectue. Au lieu d'un champ Account, chaque bloc affiche un indicateur Identity en lecture seule — sous quelle identité il agira, et si cette identité dispose actuellement d'une connexion fonctionnelle pour le produit.
Les outils d'un bloc Agent suivent l'exécution exactement de la même manière. Chaque outil appelé par l'Agent agit sous l'identité de l'exécution, la même identité qu'utilise un bloc autonome de ce workflow. Avant le démarrage d'une exécution d'Agent, Scrydon vérifie que cette identité dispose d'une connexion fonctionnelle pour chaque outil d'extension que l'Agent peut appeler : votre propre connexion lorsque vous appuyez sur Run, l'identité liée du compte de service lorsque l'exécution est liée à l'un d'eux. Le contrôle pose exactement la même question que l'appel d'outil, de sorte qu'une exécution qui le réussit n'échoue pas ensuite sur un autre compte. Vos connexions personnelles ne sont jamais consultées pour une exécution sous compte de service, dans un sens comme dans l'autre : elles ne peuvent pas satisfaire le contrôle, et leur absence ne peut pas le faire échouer.
Les recherches dans la base de connaissances suivent aussi l'exécution. Une recherche, lancée par un bloc ou par un outil d'Agent, s'effectue sous l'identité de l'exécution et ne voit que ce que couvre la plus basse des deux habilitations : celle de cette identité et celle du propriétaire du workflow. Lorsque vous appuyez sur Run, c'est votre habilitation. Lorsque l'exécution est liée à un compte de service, c'est celle du compte, même si c'est vous qui avez lancé l'exécution. Le compte a aussi besoin de Knowledge (Read) et, lorsque la base de connaissances appartient à un espace de travail, d'en être membre.
La mémoire, les fichiers et les bases de connaissances suivent l'exécution de la même façon. Lorsque l'exécution est liée à un compte de service, ces opérations agissent sous l'identité du compte :
- la mémoire de conversation ;
- la lecture et l'écriture de fichiers dans le stockage ;
- la lecture et l'écriture des bases de connaissances memex ;
- la création et la lecture d'un document, et les questions posées à une base de connaissances.
Elles ne sont pas limitées par ce que vous pouvez faire vous-même.
- Permissions. Le compte a besoin de la portée correspondante :
chat:read/chat:writepour la mémoire,storage:read/storage:writepour les fichiers, etknowledge:read/knowledge:writepour les bases de connaissances. Il doit aussi être membre de l'espace de travail du workflow. - Un seul environnement. Le compte agit uniquement dans l'environnement où s'exécute le run. La mémoire et les bases de connaissances d'un autre environnement lui sont refusées, de même que les fichiers d'un autre espace de travail ou environnement. Les fichiers et bases de connaissances de toute l'organisation n'exigent que la portée.
- Habilitation. Les bases de connaissances sont lues au niveau de l'habilitation propre du compte, et une question n'obtient de réponse qu'à partir de ce que cette habilitation couvre. Une page écrite par le compte n'est jamais classifiée au-dessus de son habilitation.
- Propriété. La mémoire enregistrée par le compte appartient au compte.
Lorsque l'exécution n'est pas liée à un compte de service, toutes ces opérations agissent sous votre identité, comme auparavant.
Les connexions suivent l'exécution de la même façon. Lorsqu'un bloc ou un outil d'Agent appelle une extension, la connexion utilisée est choisie selon l'habilitation de l'identité sous laquelle l'exécution s'effectue : la vôtre lorsque vous appuyez sur Run, celle du compte de service lorsque l'exécution y est liée, même si c'est vous qui l'avez lancée. Une connexion classée au-dessus de cette habilitation n'est pas utilisée.
Les appels au modèle suivent eux aussi l'exécution. Lorsqu'une base de connaissances répond à une
question pendant l'exécution, le modèle qu'elle interroge est choisi selon l'habilitation de cette
même identité, exactement comme pour un bloc Agent. L'IA d'un process flow fonctionne de la même
façon : les recommandations, les brouillons générés, les questions de suivi, les conseils HITL et
les résumés qu'une étape fait de ses entrées sont produits pour l'identité pour laquelle l'étape
agit. C'est la personne qui traite l'étape, ou le compte Run As d'une étape que personne ne prend en
charge. Une connexion de modèle qui exige une habilitation plus élevée n'est pas utilisée. Un compte
de service a besoin de la portée capabilities:write pour cela, comme pour un bloc Agent. Sans
elle, l'appel est refusé, et il n'est jamais fait en votre nom à la place.
Deux types de travaux d'arrière-plan n'agissent pour personne : le résumé de clôture d'une instance, et l'extraction qui s'exécute lorsqu'un document est ingéré. Ils n'utilisent que des connexions de modèle qui n'exigent aucune habilitation.
Un compte de service sans habilitation ne peut rien faire de tout cela. Ses appels aux extensions, à la mémoire, aux fichiers et aux bases de connaissances sont tous refusés, et aucun ne se rabat sur votre habilitation. Attribuez une habilitation au compte avant d'y lier une exécution.
Se connecter pour exécuter
Appuyez sur Run et, si un bloc du workflow a besoin d'une connexion que votre compte n'a pas encore, une boîte de dialogue Connect to run s'ouvre en listant exactement ces produits. Connectez-les un par un — chacun est une redirection OAuth classique qui vous ramène à l'éditeur — et l'exécution démarre d'elle-même dès que la liste est vide. Vous n'avez jamais à quitter l'exécution pour aller chercher une page de paramètres.
Exécuter en tant que compte de service
Le consentement est différent lorsque ce n'est pas à vous qu'on demande de l'accorder. Personne ne peut autoriser une connexion OAuth au nom d'un compte de service depuis l'éditeur : Run as ▾ un compte de service dont l'identité est manquante n'ouvre donc pas de flux de connexion — cela désactive Run et indique plutôt le correctif :
- Un administrateur d'organisation voit Link identity, qui ouvre directement le panneau d'identité du compte de service.
- Toute autre personne voit Copy request (à transmettre à un administrateur) et Run as you instead, qui rebascule l'exécution sur votre propre identité.
Il n'existe pas d'option « exécuter quand même ». Une exécution sous compte de service dont l'identité est manquante ne démarre pas, et rien ne se rabat silencieusement sur un autre compte.
Workflows installés par une extension
Un workflow qu'une extension installe appartient à l'extension, pas à une personne. Lorsqu'un tel workflow crée une instance de process flow (le workflow d'ingestion de Drone Response le fait pour chaque nouvelle piste), les étapes propres à l'instance, comme une étape Agent qui rédige une évaluation, n'ont personne au nom de qui agir.
Ces étapes reprennent le Run As du workflow qui a créé l'instance. Définissez-le une fois, sur le workflow installé (Déployer → Paramètres d'exécution). Une instance copie ce paramètre, ainsi que l'habilitation pour laquelle il a été accrédité, au moment de sa création :
- Les instances créées après l'enregistrement du paramètre s'exécutent sous ce compte.
- Les instances créées avant conservent ce qu'elles ont copié. Réenregistrer le paramètre ne les atteint pas.
- Sans paramètre, l'étape Agent s'arrête avec « This run has no person to act as… » au lieu d'appeler Base Platform. Rien ne bascule vers une autre identité.
Mettre à jour ou réinstaller l'extension conserve le Run As du workflow installé.
Les étapes propres au workflow installé s'exécutent elles aussi sous ce compte, et un compte de service agit avec exactement les scopes qui lui ont été attribués. Accordez-lui ce qu'utilisent les deux workflows : Tools (Write) pour les étapes d'outil, comme Function, Table write et Create process instance ou task, et AI Capabilities (Write) pour les étapes Agent.
Une étape Agent que personne ne prend en charge lit aussi les documents qu'elle déclare en entrée (par exemple la classification de l'opérateur dont part une étape d'évaluation) sous ce compte. Cette lecture exige Knowledge (Read), et le compte doit être membre de l'espace de travail de l'instance. Elle voit exactement les pages que couvre l'habilitation propre du compte, jamais au-delà du plafond de classification de l'étape. Sans l'un ou l'autre, l'étape s'exécute quand même mais signale ses entrées comme illisibles.
Comportement lors de la promotion
Lorsque vous promouvez un workflow vers un nouvel environnement :
- Première promotion dans cet environnement — Run As est initialisé à partir du paramètre du workflow source. Si vous n'êtes pas accrédité pour le compte de service source, la cible est créée avec Propriétaire du workflow et un avertissement s'affiche dans la vue Promote.
- L'accréditation est vérifiée pour l'environnement vers lequel vous promouvez, et non pour celui depuis lequel vous promouvez. Un compte limité à
prdest proposé lorsque vous promouvez vers Production, même s'il est refusé en Development. - Promotions suivantes — la liaison Run As de l'environnement cible est conservée telle quelle. La promotion ne l'écrase jamais.
Chaque bloc se résout automatiquement par rapport à la liaison Run As de l'environnement cible au moment de l'exécution — comme un bloc ne stocke jamais de compte, rien n'a besoin d'être réécrit lors de la promotion.
- Une identité manquante déclenche un avertissement, pas un blocage. La promotion vérifie que le produit de chaque bloc est disponible dans l'environnement cible, et non que l'identité Run As y dispose d'un compte pour ce produit — l'administrateur qui lie cette identité n'est souvent pas la personne qui effectue la promotion. La vue Promote affiche un avertissement de disponibilité pour l'environnement cible et le bouton indique Promote with warning. L'exécution elle-même échoue en mode fermé : la première exécution dans l'environnement cible s'arrête au bloc dont l'identité est manquante, et rien ne se rabat sur un autre compte.
- Les anciens comptes fixés sont toujours vérifiés. Un bloc enregistré avant que les blocs ne suivent l'exécution peut encore fixer un compte précis. La promotion vérifie ce compte par rapport aux identifiants d'exécution de l'espace de travail cible et refuse s'il n'y est pas affecté. La vue Promote liste ces blocs comme legacy pin ; basculez le bloc en run-as pour qu'il suive plutôt l'identité de l'exécution.
- Une promotion refusée indique où corriger le problème. La vue Promote nomme l'espace de travail et l'environnement cibles et, pour un refus lié aux identifiants, renvoie vers les identifiants d'exécution de cet espace de travail. Les retours arrière depuis l'historique des versions signalent les refus de la même manière.
Attribution des exécutions
Le tableau Runs de l'onglet Monitor affiche une colonne Run As pour chaque exécution. Valeurs possibles :
| Affichage | Signification |
|---|---|
Badge service_account + nom | Le workflow s'est exécuté sous ce compte de service |
| Avatar de l'utilisateur | Le workflow s'est exécuté sous l'identité du propriétaire ou de l'exécutant |
| — | Exécution antérieure à la fonctionnalité (aucune métadonnée d'acteur) |
Les journaux d'audit consignent le type d'acteur (user ou service_account) et l'ID du compte de service à chaque exécution, afin que les équipes de conformité puissent identifier les exécutions non humaines.
Dépannage
Le workflow échoue avec RUN_AS_CREDENTIAL_MISSING — le portefeuille du compte de service ne contient aucun identifiant pour le produit d'intégration que le workflow a tenté d'utiliser. Ouvrez la fiche de détail du compte de service, ajoutez l'identifiant lié manquant, puis relancez.
Si le sélecteur renvoie RUN_AS_PRODUCT_UNCOVERED, le compte de service n'a aucune entrée de portefeuille pour un produit dont l'un des blocs du workflow a besoin — chaque bloc suit déjà l'exécution, il n'y a donc aucun paramètre de bloc à modifier. Liez l'identifiant dans Paramètres → Organisation → Membres → Comptes de service avant l'exécution.
Le bloc Agent échoue avec AGENT_TOOL_CATALOG_UNAVAILABLE — un outil d'extension du bloc Agent ne peut pas s'exécuter sous l'identité de l'exécution : l'exécution est donc refusée avant l'appel au modèle. Le message nomme chaque outil et le correctif :
- « Link a <product> identity to this workflow's Run As service account… » — le compte de service n'a aucune identité sur la connexion de ce produit pour cet environnement. Un administrateur d'organisation en lie une sous Paramètres → Organisation → Membres → Comptes de service. Connecter votre propre compte n'aide pas : une exécution sous compte de service ne l'utilise jamais.
- « This workflow's Run As service account is not allowed to act in this workspace and environment… » — le compte s'est connecté, mais sa politique d'accès ne couvre pas l'endroit où ce workflow s'exécute, si bien qu'aucun produit n'a jamais été vérifié. Le motif entre crochets indique quelle moitié est en cause :
environment_mismatchsignifie que le compte est limité à un autre environnement (un compte limité àprdne peut pas exécuter un workflow dansdev), etworkspace_access_requiredsignifie que sa liste d'espaces de travail exclut cet espace de travail. Lier un identifiant n'aide pas. Un administrateur d'organisation modifie l'accès du compte aux espaces de travail et aux environnements sous Paramètres → Organisation → Membres → Comptes de service, ou vous choisissez une autre identité Run As. - « Scrydon could not sign in as this workflow's Run As service account… » — aucun jeton n'a pu être émis pour le compte de service, si bien qu'aucun produit n'a jamais été vérifié. Vérifiez que le compte est activé et qu'il a été créé avec une habilitation de sécurité : ce n'est qu'à cette condition que Scrydon détient le secret avec lequel il se connecte. Un compte dont le secret a été renouvelé avant le 2026-09-21 se trouve également dans cet état : renouvelez-le une fois de plus sous Paramètres → Organisation → Comptes de service pour le réparer, puis transmettez le nouveau secret à tout ce qui utilise le compte, comme un pipeline CI/CD.
- « Base Platform could not confirm the Run As service account's <product> identity… » — le compte s'est connecté, mais le contrôle pour ce produit n'a pas obtenu de réponse. Réessayez dans un instant.
- « Connect <product> before running the Agent. » — l'exécution s'effectue en votre nom, et vous n'avez aucune connexion pour ce produit. Utilisez Connect sur l'indicateur Identity de l'outil.
L'exécution échoue avec « This workflow's Run As service account now holds a wider clearance… » — l'habilitation du compte a été relevée après sa liaison à ce workflow, si bien que personne n'a accrédité cette portée élargie. Une personne habilitée à accréditer le compte à son habilitation actuelle enregistre de nouveau le paramètre Run As du workflow dans Deploy (ou Versions, une fois déployé) → Paramètres d'exécution ; cela le ré-accrédite et les exécutions reprennent. Rabaisser l'habilitation du compte résout également le problème.
Une base de connaissances refuse de répondre lors d'une exécution sous compte de service (llm_synthesis_refused) —
les appels au modèle derrière la réponse sont faits au nom du compte de service, et API Platform en
a refusé un. La réponse porte le statut d'API Platform. Son platformCode indique pourquoi :
FORBIDDENsignifie généralement que le compte n'a pas la portéecapabilities:write. Accordez-la dans Paramètres → Organisation → Comptes de service.POLICY_BLOCKEDsignifie qu'une politique DLP ou de modération a bloqué la requête.reasonnomme la politique.CAPABILITY_NOT_CONFIGUREDsignifie qu'aucune connexion de modèle n'est disponible à l'habilitation du compte.
Réessayer n'aide pas. llm_synthesis_unavailable (503) signifie seulement une panne, qu'une
nouvelle tentative peut surmonter.
L'IA d'un process flow indique que le service d'IA a refusé la requête (llm_refused) — les
recommandations, la génération, les questions de suivi et les conseils HITL signalent le refus
d'API Platform avec son statut (403 ou 422), platformCode et reason. Le panneau affiche le
refus et ne propose pas Réessayer, car une nouvelle tentative est refusée de la même façon.
Corrigez ce que nomme platformCode :
FORBIDDEN: l'identité pour laquelle l'étape agit n'a pas la portée ou l'habilitation nécessaire. Un compte Run As a besoin de AI Capabilities (Write).POLICY_BLOCKED: une politique DLP ou de modération a bloqué la requête.
Il en va de même lorsque la lecture de connaissances derrière les recommandations a été refusée.
Le sélecteur affiche « not accredited » — le rang d'habilitation BLP du compte de service est inférieur à celui de la base de connaissances ou du document auquel le workflow accède. Augmentez l'habilitation du compte de service dans Paramètres → Organisation → Comptes de service ou réduisez la classification du document.
Le sélecteur indique que le compte n'est pas autorisé dans cet environnement — l'accès du compte aux espaces de travail et aux environnements ne couvre pas l'environnement dans lequel ce workflow s'exécute. Modifiez l'accès du compte ou choisissez une autre identité. Lier des identifiants n'aide pas : Scrydon refuse le compte avant même de rechercher un identifiant.
Une étape Agent d'un process flow échoue avec « This run has no person to act as… » — l'instance a été créée par un workflow qu'une extension a installé, et ce workflow n'a pas de Run As. Définissez-en un sur le workflow installé (Déployer → Paramètres d'exécution). Il s'applique aux instances créées après l'enregistrement. Voir Workflows installés par une extension.
Une étape échoue avec « The caller is not authorized for this platform operation » — l'exécution se fait sous un compte de service qui ne détient pas le scope dont cette étape a besoin. Les étapes d'outil exigent Tools (Write) et les étapes Agent AI Capabilities (Write). Un administrateur d'organisation les ajoute sous Paramètres → Organisation → Membres → Comptes de service, puis relance l'exécution.
Une étape Agent d'un process flow signale ses entrées comme illisibles — personne ne prend l'étape en charge, elle lit donc ses entrées déclarées, ainsi que le contexte qu'elle tire de la base de connaissances de l'instance, sous le compte Run As, et ce compte ne peut pas les lire. Accordez au compte Knowledge (Read), ajoutez-le à l'espace de travail de l'instance et vérifiez que son habilitation couvre les documents. Un compte dont l'habilitation relève d'un schéma de classification que votre organisation n'utilise plus ne lit rien.
Une étape de process flow non prise en charge s'exécute sans son briefing Company Context — l'étape lit aussi son briefing Company Context sous le compte Run As. Le compte a besoin de Knowledge (Read), d'être membre de l'espace de travail de l'instance et d'une habilitation, dans le schéma de classification actif de votre organisation, égale ou supérieure au plafond de contexte de l'action. Sans l'une de ces conditions, l'action s'exécute quand même, sans le briefing, et le panneau Invite & Contexte indique le briefing comme indisponible.
Une recherche dans une exécution sous compte de service est refusée, ou trouve moins que prévu — la recherche s'effectue sous le compte de service, pas sous la personne qui a lancé l'exécution. Le compte a besoin de Knowledge (Read), d'être membre de l'espace de travail de la base de connaissances et d'une habilitation dans le schéma de classification actif de votre organisation ; sans cette habilitation, la recherche est refusée. Elle ne trouve ensuite que les documents couverts par la plus basse des habilitations du compte et du propriétaire du workflow.
L'enregistrement renvoie 403 — votre propre niveau d'habilitation est inférieur au rang BLP du compte de service. Vous ne pouvez lier qu'un compte de service dont l'habilitation est inférieure ou égale à la vôtre. Si personne ne vous a attribué d'habilitation, vous détenez le niveau de base des membres de votre organisation (INTERNAL, sauf si votre organisation l'a modifié) : vous pouvez donc lier un compte à ce niveau ou en dessous. Contactez votre administrateur d'organisation pour ajuster l'habilitation du compte de service ou la vôtre.
Le remplacement par exécution renvoie 403 — votre compte n'est pas accrédité pour exécuter ce workflow sous le compte de service choisi (même règle d'habilitation que ci-dessus).
Jeton OAuth expiré — un administrateur d'organisation doit reconnecter le compte d'extension sous Paramètres → Plateforme → Extensions et le lier de nouveau dans le portefeuille d'identifiants du compte de service.