Troubleshooting IO

1. 1

   Note what the user saw

   The exact message, the page, the time, and whether a reload was involved.

2. 2

   Check the flow is the one that runs

   Is it Active? Is it the default for its flow type, or does the link carry its flow_id? Is it the flow type you expect?

3. 3

   Follow the path in the designer

   Trace the run from the start node, output by output. Read where each output really goes, not where you expect it to go.

4. 4

   Look for unconnected outputs

   Every output of every node needs a connection, Failure and nested-flow outcomes included.

5. 5

   Read the error

   Log {{flow.error.message}} on the failure path (see Find the error) and reproduce the problem.

Backend - HTTP Request has only Success (2xx) and Failure. On Failure it still stores the response in its variable, but the shape depends on the response:

• {{flow.error.message}} holds Request failed with status code <N>. Log it together with {{result.data}}.
• 401: the token is missing, expired, or not for this service. The client needs the service in its Default audiences. See Access clients and the API's Connect section.
• 403: the token lacks the operation's scope. Add it to the client's Default scopes (Scopes).
• The token request itself fails with HTTP 500: the client's scopes, joined with spaces, are longer than 1024 characters. Split them across clients.
• Each API page lists its own error codes, for example Identity Store: when a call fails.

Thales service nodes route known errors to their own outputs (such as NotFound, Conflict, BadRequest) and write details under their variable, for example {{ids.idsError.status}} and {{ids.idsError.message}}. 401 and 403 always go to Failure.

• `Failure` with an empty error variable usually means authentication or configuration, not data: an empty or wrong client secret (check its Load From Vault), a missing scope, or a missing audience.
• A result reads as `undefined`: read it through the node's variable, {{ids.idsGetIdentityByAttributeResult.response.id}}. The bare {{idsGetIdentityByAttributeResult…}} never resolves.
• Password Store, Action Challenge, TOTP and Recovery Codes nodes fail when no Identity Store lookup ran first. They need the user's identity ID and don't look the user up themselves.
• Use the output names your tenant's node shows in the designer. Many service nodes have no output called Success.

Add a Backend - Log node on the failure path, before the error page. It writes to the platform logs, never to the user:

{ "log": "[Sign-in] lookup FAILED | user={{login.username}} error={{flow.error.message}} response={{idsUser.data}}",
  "log_level": "WARNING" }

• {{flow.error.message}} holds the error of the last node that failed. {{flow.error}} adds the stack.
• Never log passwords, tokens, vault values or {{flow}}. Log that a value is present, not the value.
• The step-by-step trace of a run is logged at Debug level. On environments that keep only Info and above, you see what each node did, but not the path between them.
• One failed request can write the same error several times. Count requests, not log lines.
• Enable nodes tracking (flow settings) records every executed step in the platform. Turn it on for a flow you are investigating, and ask support for the records if you need them.
• Test an inactive copy with a Debug link while you investigate, so the live journey keeps running.

Collect these, so support can find the run quickly:

• The environment, the flow name and its flow ID (Copy ID in the flow list).
• The time of the failure, with time zone, and the flow session ID if you logged {{flow.flow_session}}.
• The node title and output where the run stopped, and the exact error message.
• What you already checked from this page.

Never send passwords, client secrets, tokens or vault values. Remove personal data from exports and screenshots before you share them.