Connections troubleshooting

Auf dieser Seite wird erklärt, wie Sie Probleme beheben, die bei der Verwendung von Verbindungen auftreten können.

Clientanforderung fehlgeschlagen: Fehler beim Empfangen des Zugriffstokens

Beschreibung

Dieser Fehler wird durch ungültige Anmeldeinformationen oder Angaben des Kunden verursacht.

Lösung

Stellen Sie sicher, dass alle ausgefüllten/angegebenen Anmeldeinformationen gültig sind.

Die Verbindung konnte nicht erstellt werden. Schließen Sie diese Browserregisterkarte, und versuchen Sie es erneut.

Beschreibung

Dieser Fehler wird durch ungültige Scopes oder App-Berechtigungen verursacht.

Lösung

Überprüfen Sie, ob alle Scopes/Berechtigungen wie erwartet bereitgestellt werden.

Verbindung ist derzeit inaktiv, klicken Sie auf „Verbindung reparieren“.

Beschreibung

Es ist möglich, dass eine Verbindung aufgrund eines Ablaufs des OAuth-Tokens oder eines Aktualisierungsproblems abläuft.

Lösung

Wählen Sie Verbindung reparieren und wiederholen Sie den Ablauf für die Verbindungserstellung. Um eine Verbindung zu reparieren, wählen Sie die entsprechende Schaltfläche Mehr rechts neben der Benutzeroberfläche aus und wählen Sie Verbindung reparieren.

Fehlercode: 400 Meldung: Verbindung mit einem oder mehreren zugewiesenen Triggern kann nicht gelöscht werden.

Beschreibung

Wenn Sie versuchen, eine Verbindung zu löschen, wird möglicherweise die folgende Meldung angezeigt: Fehlercode: 400 Meldung: Verbindung mit einem oder mehreren zugewiesenen Triggern kann nicht gelöscht werden.

Lösung

Sie können die Instanz nicht löschen, wenn für sie ein Trigger aktiviert ist. Löschen Sie den Trigger, bevor Sie die Instanz löschen.

Der Benutzer hat keine Connections.View-Berechtigungen für den Verbindungsordner.

Beschreibung

Verbindungen im Integration Service scheinen erfolgreich zu sein (Status: Verbunden), aber Unattended-Aufträge schlagen mit der folgenden Fehlermeldung fehl: „Der Benutzer verfügt nicht über Connections.View-Berechtigungen für den Verbindungsordner.“

Lösung

Der Roboter benötigt Zugriff auf die im Prozess verwendete Verbindung.

Damit ein Roboter einen Auftrag mithilfe eines Connectors von Integration Service ausführen kann, ist Folgendes erforderlich:

• Die Verbindung und der Roboter, die den Auftrag ausführen sollen, müssen sich im selben Orchestrator-Ordner befinden.
• Dem Roboter muss eine Rolle zugewiesen werden, die über Berechtigungen zum Anzeigen von Ordnern für das Verbindungselement verfügt. Weitere Informationen finden Sie im Orchestrator-Benutzerhandbuch.

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. Stellen Sie sicher, dass:

   • 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.