Managing individual customer tenants is time-consuming and therefore today many Business Central Partners operate external platforms that help manage environments across multiple customers. These platforms automate administration and simplify cross-tenant operations, such as App deployments and updates.
Orbit is one example: a platform used by Partners to manage Business Central environments at scale. To run these platforms, you would require access to Admin Center API via Entra App consent.
When onboarding customers to this kind of platform, the biggest friction usually isn’t Business Central itself. It’s Microsoft Entra consent.
Without a clear approach to delegated permissions, onboarding each customer tenant can turn into a slow process dependent on customer IT. This article explains how Partners can structure onboarding so that it becomes predictable and scalable.
Why onboarding often becomes slow
External management tools typically use a multi-tenant Entra application. To allow the application to access a customer tenant, someone with sufficient Entra privileges must grant tenant-wide admin consent for the required permissions.
If the Partner does not have delegated authority to perform this action, the process looks like this:
- The Partner sends an onboarding request.
- The customer must involve someone with the correct permissions.
- The admin reviews the permissions and grants consent.
- The Partner proceeds with configuration.
In practice, this often introduces delays. Customer admins may not be available, may require a security review, or may simply not prioritize the request. Even small changes later—such as adding permissions—require repeating the process.
For Partners managing dozens or hundreds of tenants, this approach does not scale.
The scalable alternative: Partner-managed consent through GDAP
Microsoft introduced Granular Delegated Admin Privileges (GDAP) so that customers can grant Partners limited administrative capabilities in a controlled way.
Instead of relying on customer IT for every onboarding step, the customer grants the Partner specific Entra roles through a GDAP relationship. Once those roles are approved, the Partner can perform the required administrative tasks directly.
For onboarding management tools like Orbit, this means the Partner can grant admin consent for the application and complete onboarding during the implementation process.
The customer still controls which roles the Partner receives and how long the relationship lasts.
What permissions are required to grant admin consent
Granting tenant-wide consent requires a role that is authorized to approve permissions for applications.
Depending on the permissions requested by the application, this typically includes roles such as:
- Application Administrator
- Cloud Application Administrator
- Privileged Role Administrator
- Global Administrator
These roles allow a user to approve application permissions on behalf of the organization.
Note: the ‘Dynamics 365 Administrator’ or ‘Dynamics 365 Business Central Administrator’ role gives access to the Admin Center, but it does not allow that user to grant application consent in Microsoft Entra Apps.
When a customer establishes a GDAP relationship, they can assign one of these roles to the Partner. The Partner then operates under that role when performing administrative actions in the tenant.
For most onboarding scenarios, Application Administrator or Cloud Application Administrator is sufficient and avoids the need for broader privileges.
How Partners should structure this operationally
A scalable setup usually follows a simple pattern.
1. Establish a GDAP relationship
The customer grants the Partner a GDAP relationship through Partner Center. This replaces older broad delegated admin access with a more controlled model.
2. Assign Entra roles to a Partner security group
Instead of assigning roles directly to individuals, the roles are assigned to a security group in the Partner tenant. Partner staff who perform onboarding are placed in that group.
This approach keeps permissions manageable and auditable.
3. Partner grants application consent during onboarding
With the delegated role in place, the Partner can grant admin consent to the application directly in the customer tenant. The enterprise application is created and permissions are approved in one step.
Once consent is granted, the Partner can proceed with configuring the customer environment in the management platform.
What happens if the Partner does not have these permissions? The Partner then relies on customer timeline, which realistically means that many tenants are not connected to a centralized platform for easier management.
How this relates to Business Central
Delegated administration for Business Central and Entra permissions are related but separate.
A Partner may already have delegated access to Business Central environments and still be unable to grant application consent in Entra. The consent operation depends entirely on the Entra roles granted through GDAP.
This is why Partners who build operational tooling around Business Central should treat Entra delegation as a core part of their onboarding design.
Final thoughts
For Partners operating management platforms like Orbit, onboarding must be predictable. Relying on ad-hoc approval from customer administrators introduces delays and makes large-scale operations difficult.
Using GDAP with the appropriate Entra roles allows Partners to perform the required consent steps themselves while keeping the process controlled and auditable.
With the right structure in place, onboarding a new Business Central tenant becomes a routine step rather than a multi-day coordination effort with customer IT.