You’re offline. This is a read only version of the page.
At first glance, this seems like a fairly standard setup. As a partner, we often need two types of access in a customer tenant:
Individually, both approaches work perfectly fine. The problem starts when both are used with the same identity.
In our case, the consultant had already been invited as a guest user in the customer tenant. The invitation was accepted and the user had already worked with Teams and DevOps.
Later, we tried to access Business Central Online using GDAP – and that’s where things started to behave unexpectedly.
Instead of seeing the usual “GDAP-style” user (the anonymized USER_xxx account), Business Central seemed to pick up the already existing guest user context. That effectively broke the expected delegated admin behavior, because the guest user didn’t have a Business Central license.
The result: no proper access via GDAP anymore.
What made this tricky was that it wasn’t immediately obvious what was going on. The key indicator for us was the Users page in Business Central. Instead of seeing the typical technical GDAP user, we saw a normal, personalized user – which was a strong hint that the system wasn’t treating the login as a pure delegated admin scenario anymore.
From what we understand, this is consistent with how Business Central works in general. Delegated admins are supposed to show up as separate, anonymized identities. But if the same user already exists in the customer tenant, the system seems to associate everything with that existing identity.
The real challenge, however, was not identifying the issue – but fixing it.
Once the “wrong” user context was established, we didn’t find a clean way to simply switch back to the intended GDAP behavior. Disabling the user in Business Central was not sufficient.
The workaround that worked for us was the following approach:
In one of our scenarios, the cleanup was even more complex, and we ended up recreating the Business Central environment to fully reset the situation.
We want to clearly emphasize: this is not an official Microsoft guideline. It’s simply the approach that worked for us in practice.
That’s also the reason for this post.
We would really like to understand if this is a common issue in the community, or if we just ran into a very specific edge case.
A few questions to those of you working with GDAP and Business Central Online:
Our current takeaway is quite simple: mixing guest access and GDAP access with the same identity can lead to unexpected side effects in Business Central Online. At the very least, it’s something we will pay much closer attention to in future projects.
Looking forward to hearing your experiences and thoughts.
Share
Report
All responses (
Answers (
2,028
