Anonymous Conversational Agent fails at Wait for Message with External App authentication

I’m testing Anonymous Access for Conversational Agents in an Automation Cloud Community tenant.

What works:

- Confidential External App

- OAuth client_credentials token flow

- Cloud Run token endpoint

- CORS fixed and working

- Conversation creation succeeds

- User message reaches the conversation

What fails:

The Maestro flow consistently fails on Wait for Message.

Error:

403

Failed to end open exchanges in the Conversational Service.

{“error”:“Access denied. User does not have access to this conversation.”}

I created a minimal repro agent:

Conversation Trigger

→ Wait for Message

→ Send Message

The minimal agent reproduces the same issue.

Trace ID:

0860fc12a856c1620decc4f1efa9331b

Agent Release ID:

2050666

Conversation ID:

26198365-4af4-4812-93fa-76cc10b29684

Interesting observation:

Conversation Trigger completes successfully.

Wait for Message fails.

The user message arrives afterwards and is recorded successfully in the conversation.

Has anyone successfully used Wait for Message with Anonymous Access and an External App in a Community tenant?

Hi @Hutch ,
The flow design looks correct. Focus on the External App permissions/conversation identity; if those are correct, this is likely something UiPath needs to investigate using your trace details.

Thanks

Thanks @Jasmin_Bar gone over it with a fine tooth comb & it seems it’s correct, as a community user how do I get it investigated?

As this is a Community tenant, I’d suggest reporting it under the Automation Cloud / bug area of the UiPath Community Forum. Include your minimal repro, exact 403 error, Trace ID, Agent Release ID, and Conversation ID so the UiPath team/community moderators have enough information to investigate or escalate it.

Your minimal Conversation Trigger → Wait for Message → Send Message reproduction is particularly useful because it isolates the issue from the rest of the implementation.

@Hutch It looks more like a permission issue than a flow issue.

Since the Conversation Trigger is working and the message is reaching the conversation, your authentication setup seems to be okay. The problem starts only at Wait for Message, where it says the user does not have access to the conversation.

Can you check whether the External App has the required Conversational Agents scope and access to the folder where the agent is published? Also, make sure the same externalUserId is being used throughout the conversation.

Thanks for the detailed suggestions, @Jasmin_Bar and @Dhruba_Jyoti_Kalita. :+1:

I would also suggest checking the External App permissions/scopes and verifying that the same externalUserId and Conversation ID are being passed throughout the flow.

Since the issue occurs specifically at Wait for Message while the Conversation Trigger works successfully, comparing the permissions and conversation context between these two activities may help identify the root cause.

Hope this helps with troubleshooting.

Hi @MayureshOfficial_45 I only have the option to pass in the Conversation ID to the Wait For Message node, I don’t seem to be able to reference the ExternalUserID in the conversation flow.

Folder and External App permissions are setup based on Agents - Anonymous access setup

Hi @Hutch, thanks for clarifying.

That makes sense. If the Wait for Message node only accepts the Conversation ID and there is no option to explicitly pass/reference the ExternalUserID, it could be worth checking whether the anonymous user context is being preserved when the flow reaches Wait for Message.

Since the Conversation Trigger completes and the user message is successfully recorded, while Wait for Message returns 403 User does not have access to this conversation, the issue seems to occur specifically when the Maestro flow tries to access/end the open exchange.

Could you also check whether the Conversation ID used by Wait for Message is exactly the same one created by the Conversation Trigger, and whether the External App has all the required folder/agent permissions from the Anonymous Access setup?

If the configuration is already correct, this may need to be investigated by UiPath Support as a potential Conversational Service/Anonymous Access issue.

Thanks @MayureshOfficial_45,

It’s looking a bit more like this will need support to look at this, do you know how I raise that?

You’re welcome, @Hutch!
I agree that this looks like something that may need to be investigated by UiPath, especially since the minimal repro shows the same 403 error.

Since you’re using a Community tenant, I’d suggest keeping the Forum thread updated with the Trace ID, Agent Release ID, Conversation ID, and the minimal repro steps you’ve already shared. This should give the UiPath team enough context to investigate the issue or guide you on the appropriate escalation path.

Hope you get a resolution soon. Please keep us posted if you receive any update from UiPath. :+1:

@Hutch The 403 at Wait for Message happens because client credentials authenticate as the application service principal rather than a real user.

During the initial conversation trigger an anonymous exchange session is established, so the first message goes through. But when Maestro reaches Wait for Message to check the open exchange, the Conversational Service checks the caller identity. Since the follow up request comes in under the raw external app service principal without the anonymous exchange context, access gets denied.

As a community user, the best way to get engineering to review this is to post it under the Product Bugs section and tag the product team, sharing your trace ID and the minimal repro flow. You can also submit it through the Insider portal if you are part of the preview program.