Mastering Microsoft Partner Associations: GDAP, PAL, and CPOR Explained

16 September, 2025

Microsoft CSP partners rely on GDAP, PAL, and CPOR to secure access, track contributions, and earn incentives. In this blog, we break down how each works and share best practices to simplify management and ensure your efforts are recognised.

Understanding Partner Associations

Microsoft utilises GDAP to enhance security, PAL, and CPOR (C4) to recognise partner contributions. 

  • GDAP (Granular Delegated Admin Privileges): Provides secure, time-bound, least-privilege access, allowing partners to responsibly manage customer environments.
  • PAL (Partner Admin Link): Connects partner IDs to customer Azure environments, enabling Microsoft to measure and attribute Azure revenue influence.
  • CPOR (Claiming Partner of Record / C4): Formally links partners to workloads or subscriptions, recognising deployment, usage, and customer success.

Why this matters?

From 1 October 2025, partners can start earning incentives across solution areas if they meet minimum revenue thresholds AND hold at least 25 points in their Solution Partner designation category. You don't need full designation status in October; 25 points are enough. PAL and CPOR play a critical role here, as they directly contribute to scoring and incentive eligibility, while GDAP ensures partners can manage customers securely along the way. 

GDAP: Secure, Granular Access for Partners

GDAP is Microsoft's modern security model for partner access, built on Zero Trust principles. Unlike the old DAP model (broad, permanent access with higher risk), GDAP gives partners time-bound, least-privilege access with full customer visibility and control.

How it works:

  • Partners use their secure admin credentials in Partner Center to request GDAP access with selected roles that align with operational needs 
  • Roles selected must reflect least-privilege access aligned to operational needs. 
  • Access duration can be customised from 1 day to 730 days.
  • Customers receive an approval link and decide which roles to approve.
  • All activity (creation, approvals, assignments, expiries) is logged in Partner Center. 

Why it matters:

  • Customers maintain peace of mind with transparency and the ability to revoke access at any time.
  • Partners can manage environments effectively while minimising unnecessary risk.

Best practices checklist:

  • Apply least privilege (grant only the roles required).

  • Map roles to security groups and limit global admin use.

  • Limit privileged users. Keep the number of users with admin roles as small as possible.

  • Enforce role segregation. Separate duties (e.g., billing admin vs. security admin) to avoid conflict of interests.

  • Review access regularly. Audit security groups and GDAP relationships quarterly and remove unused permissions.

  • Always engage customers in the process to ensure trust and clarity.

  • Maintain transparency by showing customers who has access, why, and for how long.

Key Takeaway: When explaining GDAP to customers, highlight that unlike the old delegated admin model (broad, permanent access), GDAP puts them in control. Customers decide which roles you need, for how long, and at what level of access. Nothing is activated until they approve via a secure link giving them greater security and transparency.

PAL: Partner Admin Link

PAL is how Microsoft attributes and recognises a partner's influence on Azure consumption and customer success. By linking your Partner ID (MPN ID) to a customer's Azure environment, Microsoft can track and report on the value you deliver, even if you're not the transacting partner.

How it works:

  • Customers grant you admin access (guest account, local account, or service principal). You will require a valid, active MPN ID.
  • You link your MPN ID to admin credentials in the Azure portal.
  • Only the partner who creates the PAL link can update or change it
  • PAL automatically measures and reports partner influence on Azure Consumed Revenue (ACR)
  • Multiple partners can be recognised in the same customer environment.

Why it matters:

  • Without PAL, your contribution to Azure consumption may go unrecognised.
  • Attribution ensures your influence counts toward incentives, programs, and Microsoft recognition.
  • Customers remain fully in control through Azure's role-based access (subscription, resource group, or resource level). PAL only tracks; it doesn't change permissions.

Best practices checklist:

  • Make PAL setup a standard step in customer onboarding. Link your Partner ID (PLA/MPN ID) to customer Azure credentials ensuring attribution to ACR starts from day one.

  • Assign clear accountability. Designate SMEs to manage PAL linkage and QA across all customers.

  • Document the process in your onboarding playbook.

  • Educate customers. Explain that PAL doesn't remove control, but ensures their partner's contribution is visible and rewarded.

Key Takeaway: When introducing PAL to customers, frame it as a win-win. Explain that linking your Partner ID helps Microsoft see the value you deliver in Azure ensuring your work is visible, recognised, and backed by stronger tools, support, and programs for the customer. Make PAL a standard part of onboarding, assign clear ownership within your team, and document the process in your playbook. Most importantly, educate customers on how PAL benefits both sides, it's about recognition, not control.

CPOR: Claiming Partner of Record

CPOR (C4) allows Microsoft to formally recognise a partner for servicing a customer's Microsoft Cloud environment. Unlike PAL, only one partner of record can be assigned per workload or product. A customer may still work with multiple partners across different workloads or subscriptions, but ownership is clear for each.

How it works:

  • CPOR counts toward partner capability scoring in Modern Work, Business Applications, and Security.
  • CSP transactions automatically establish association for customer adds and usage growth.
  • For non-transacting relationships, you can file a CPOR claim to ensure your work is recognised.
  • The process requires proof of execution (e.g., SOW, workshop, deployment activity) which Microsoft reviews and validates with both partner and customer.
  • Customers are notified and can opt out, so it's best to align with them in advance.

Why it matters:

Recognition and incentives are tied to usage growth, but claims must be created at the start of engagement. You can't claim retrospectively. CPOR gives partners access to usage insights for that workload only not transactional or broader tenant data ensuring transparency and customer trust.

Proper claims ensure your work driving adoption and deployment is rewarded.

Best practices checklist:

  • Make CPOR setup part of customer onboarding at the start of every new customer engagement to ensure influence is recognised early.

  • Assign clear accountability for creating and maintaining CPOR claims.

  • Document CPOR processes with claim submission and validation steps in playbooks.

  • Standardise proof of execution templates to avoid delays, rejections, or errors.

  • Review and resolve validation requests promptly (Microsoft allow 14 days).

  • Educate customers. CPOR doesn't reduce their control; it ensures Microsoft sees which partner is helping them achieve value.

  • Consider including CPOR attribution in contracts so expectations are clear upfront.

Key Takeaway: When discussing C4 with customers, emphasise reassurance. C4 simply lets Microsoft recognise which partners are driving cloud value and adoption. Partners gain visibility only into usage and seat data for the specific workload they're associated with, not broader transactional data. This insight helps you make tailored recommendations to maximise customer adoption and value. Importantly, customers don't need to take any additional action.

Final Thoughts

GDAP, PAL, and CPOR aren't just technical acronyms; they are powerful tools that help partners secure access, ensure proper recognition, and maximise incentives. By understanding how each mechanism works and applying best practices, you can simplify management, maintain customer trust, and make sure your contributions are fully acknowledged.

The key is to integrate these processes into your standard customer engagement workflows from the start. Secure access with GDAP, track influence with PAL, and claim recognition with CPOR to build a structured, transparent, and reward-driven approach to Microsoft partner activities.

When managed effectively, these associations not only protect your customers and your business but also position your organisation for success in Microsoft's evolving partner ecosystem.

Need to Know:

If you're unable to select Synnex as your indirect provider in Partner Center, it's often because your tenant was onboarded as an end user rather than as a reseller. Many partners self-transact licenses internally through CSP, but this block establishing an indirect provider relationship.

Key points:
  • You cannot self-provision licensing for internal use as this violates the Microsoft Partner Agreement.
  • You must choose either end user or reseller; both cannot coexist on the same tenancy.
  • If you've provisioned licenses internally but need to select Synnex as your indirect provider, contact Synnex for guidance. They can help align your tenancy with the correct internal use programs or core benefits packages from Microsoft.
  • Always verify your tenant isn't transacting licenses internally before trying to authorise an indirect provider relationship.

Q & A

Q: Can we get a report of all our clients that are non-compliant with the new MCA rules?

A: Yes. Any end users with an MCA acceptance date before March 2023 are considered non-compliant.

How to check:
  1. Go to the Customers tab in the Synnex Cloud portal.
  2. Click Download Report (top right).
  3. The CSV will show all customer records, including the date of their last active MCA.
  4. Filter for dates older than March 2023 to identify customers who need to update their agreement.
Notes:
  • Bulk MCA attestation is still available for now but will be replaced with other methods soon.
  • Partners should not accept the MCA on behalf of customers. The MCA is a legal agreement between the end user and Microsoft, and the customer must sign it themselves.
  • With the new enforcement, ensuring customers have accepted the updated MCA is critical to avoid blocked transactions and legal/compliance issues.

Q: What's the difference between a PLA ID and an MPN ID?

A: When you join the Microsoft Partner Program, you're issued a Microsoft Partner Network (MPN) ID. This is your global partner identifier. A Partner Location Account (PLA) ID is tied to a specific geography or market. It defines where you're allowed to transact (your territory).

For example, if you operate in Australia, your PLA ID allows you to transact in Australia and nearby territories (e.g., PNG). If you also operate in the US, you'll need a separate PLA ID for that market.

👉 Think of it this way:

MPN ID = who you are as a partner (global identity).

PLA ID = where you're authorised to transact (local territory).

Note: Some portals still label this field as "MPN ID" — but what you actually need to enter is your PLA ID.

Q: Why does GDAP have to expire? Can't we just extend it indefinitely?

A: GDAP is intentionally time-bound because customer engagements eventually end. You don't want indefinite access to a tenant if the relationship no longer exists.

Q: How does the six-month extension work?

A: Auto-extension renews GDAP every six months. You'll get reports and 30-day notifications before expiry so you can review and act. If auto-extension is enabled, the association will keep rolling forward in six-month increments.

Q: Why is limiting roles important?

A: Unlike the old DAP global admin model, GDAP uses a granular approach. Out of 100+ roles, only nine are typically required. This reduces risk by giving just enough access to get the job done.

Q: Should we just set auto-extension and forget it?
A: Not quite. Microsoft recommends reviewing access permissions on an ongoing basis. Multiple providers and GDAP requests can stack up across tenants. A regular access review ensures only the right people and organizations maintain access.

Q: When is CPOR applicable? And what if there's already a CSP relationship?

A: If you are the CSP transacting partner, you don't need to submit a CPOR claim. Attribution is automatically tracked.

If you're not the CSP, CPOR is how you get recognised for your deployment, enablement, or workload influence.

Key scenarios where CPOR applies:

Enterprise Agreements (EA): Required for attribution, especially if you're pursuing the Enterprise track of a Solution Partner Designation. This can unlock additional incentives for workloads (e.g., Security beyond 300 seats).

Non-transacting partners: If another CSP or Microsoft itself is the procurement channel, but you're driving the migration, deployment, or adoption, CPOR ensures your contribution is recognised.

Best practice: Even if you're not required to, some partners choose to submit CPOR to keep records clean and attribution clear.

👉 in short:

CSP = no CPOR needed.

Non-CSP or EA = CPOR required to secure attribution.

Reach out to the Synnex CSP team 📩 csp@au.synnex-grp.com for support to ensure you are claiming the credit you deserve.