I went through a long and confusing support case (#2503261420003356) trying to debug web service requests in a Business Central cloud sandbox using the Attach and Debug Next functionality. Neither I nor Microsoft Support could initially identify why the debugger wasn't triggering.

Eventually—thanks to the Dynamics 365 Yammer community (https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=3278156612993024)—I learned that you must explicitly specify the userId of the App Registration (Field User ID without brackets from the Microsoft Entra Application card) in the launch.json when debugging web service calls on cloud sandboxes. This critical requirement is not mentioned in the current documentation.

What's Missing / Needs Clarification

The documentation for the Attach and Debug Next feature does not mention that the userId is mandatory when attaching to web service requests in cloud sandboxes. https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-attach-debug-next#example-attach-to-an-online-sandbox-web-services-session

There's no warning or guidance from the AL Language extension when trying to debug a session that silently fails due to missing userId.

Suggested Improvements

1. Update the official documentation to state clearly:

• When attaching to web service requests on a cloud sandbox, userId must be set to the Microsoft Entra App Registration's User ID if the session is initiated by an app (e.g., via OAuth).
• Provide an example that reflects this scenario.

2. Enhance the AL Language extension to:

• Warn or notify the developer when attempting to attach to a web service client in a cloud sandbox without a userId, especially if using OAuth.
• Optionally suggest the App Registration User ID from the active app.json or connected identity.

Why This Matters

This requirement is obscure but essential. The current lack of documentation and tooling support causes:

• Wasted hours debugging sessions that never break,
• Frustration during development and testing of integrations,
• Reliance on external community sources to solve what should be a well-documented behavior.