Connections troubleshooting

Cette page explique comment résoudre les problèmes que vous pourriez rencontrer lors de l'utilisation de connexions.

Échec de la demande du client : Échec de la réception du jeton d'accès

Description

Cette erreur est causée par des informations d’identification ou des détails non valides fournis par le client.

Solution

Assurez-vous que toutes les informations d’identification renseignées/données sont valides.

Échec de la création de la connexion, fermez cet onglet de navigateur et réessayez

Description

Cette erreur est causée par des étendues ou des autorisations d’application non valides.

Solution

Vérifiez si toutes les étendues/autorisations sont fournies comme prévu.

La connexion est actuellement inactive, veuillez cliquer sur Réparer la connexion (Fix connection)

Description

Il est possible qu'une connexion expire en raison de l'expiration du jeton OAuth ou d'un problème d'actualisation.

Solution

Sélectionnez Réparer la connexion et rétablissez le flux de création de connexion. Pour réparer une connexion, sélectionnez le bouton Plus correspondant de votre connexion dans le côté droit de l’interface et sélectionnez Réparer la connexion.

Code d'erreur : 400 Message : Impossible de supprimer la connexion avec un ou plusieurs déclencheurs affectés

Description

Lorsque vous essayez de supprimer une connexion, vous pouvez rencontrer le message suivant : Code d'erreur : Message 400 : Impossible de supprimer la connexion avec un ou plusieurs déclencheurs attribués.

Solution

Vous ne pouvez pas supprimer l'instance lorsqu'un déclencheur est activé dessus. Supprimez le déclencheur avant de supprimer l'instance.

L’utilisateur ne dispose pas des autorisations Connections.View sur le dossier de connexion.

Description

Les connexions dans Integration Service semblent réussir (Status: Connected), mais les tâches Unattended échouent avec le message d'erreur suivant: « L'utilisateur ne dispose pas d'autorisations Connections.View dans le dossier de connexion. »

Solution

Le robot a besoin d'accéder à la connexion utilisée dans le processus.

Pour qu'un robot puisse exécuter une tâche en utilisant un connecteur d'Integration Service, les éléments suivants sont requis :

• La connexion et le robot destiné à exécuter la tâche doivent se situer dans le même dossier Orchestrator.
• Le robot doit se voir attribuer un rôle disposant d'autorisations d' affichage du dossier pour l'élément Connexions. Pour de plus amples informations, consultez le Guide de l'utilisateur d'Orchestrator.

Network restrictions

You may sometimes be unable to create connections to external applications. This is often caused by network or firewall restrictions, where the target application blocks requests from Automation Cloud because Integration Service IPs are not allowlisted.

Follow these steps to verify connectivity and resolve these issues.

1. Assurez-vous que :

   • You have the application endpoint (URL or IP) that Integration Service needs to access.
   • You have access to your enterprise firewall or network settings to allowlist IP ranges if required.

2. Verify endpoint accessibility.

   Use a simple network utility to check if your application endpoint is reachable from the internet.

   Using curl:

   curl -v https://<your-application-endpoint>

   If the request fails, the endpoint is not publicly accessible, or the IP is blocked.

3. Add Integration Service IPs to the allow list.

   Consult the list of UiPath Automation Cloud IP ranges in the official documentation, and add Integration Service IP ranges to your application or firewall allow list.

4. Retry connection creation.

   After confirming endpoint accessibility and allowlisting the IPs, attempt to create the connection again in Integration Service.

SSO-authenticated users

When logging in to UiPath Automation Cloud via SSO (e.g., Okta, Azure AD, Microsoft SSO, etc.) you may encounter issues creating connections to external applications that use the same SSO provider.

This issue occurs because Integration Service automatically uses your existing SSO session, which can cause the application to skip the login step or use the wrong account to create the connection.

Example scenario

The following example demonstrates how SSO session propagation can interfere with connection creation in Integration Service:

1. UiPath SSO Login - Alejandra logs in to UiPath Automation Cloud using her corporate Okta account [e-mail].
2. Target Application SSO - Alice wants to create a connection to Workday REST, which also uses Okta SSO as set up by the company admin.
3. Connection Creation - During the connection setup:
   • The browser automatically sends her existing Okta session token.
   • Workday assumes the SSO user is [e-mail] without prompting again for login.
4. The problem - If Alice intended to connect using a different Workday account, the connection may fail, or workflows may run under the wrong permissions.

Recommended workarounds

Use a private (incognito) browser session

Open the connection creation page in a private/incognito window. This prevents the browser from reusing the UiPath SSO session.

Workday will then prompt for explicit login credentials each time a connection must be created.

Switch to the intended account prior to connection creation

1. Log in to UiPath Automation Cloud via SSO.

   Access Integration Service as usual.

2. Log in to Workday separately.

   If the application automatically logged you in using your current SSO session, you may see a default account.

3. Log out of Workday and log in with the intended account for connection creation.

   This ensures the application has the correct user session.

4. Return to Integration Service to create the connection.

   Integration Service will now trigger the connection flow.

   The intended account session is used for authorization, preventing wrong permissions or skipped consent prompts.