Apps & Microsoft Partner Specialisations

We all know how much we love Microsoft specialisations as users. Studying for exams, passing the certifications, earning those wonderful badges. It’s great on a personal level, and can show that someone has (usually) been actively researching the material, and knowing what it’s about.

In the consulting space, Microsoft partners also can qualify for different specialisations. There are Silver Partners, Gold Partners, as well as other qualifications that partners can achieve as well. It’s something that partners strive towards, as they can get various benefits based on the level that they’re at, and the specialisation/s that they hold.

Some of the specialisations depend on the people that they employ. So, for example, to gain Silver status they’d need 3 people who have taken the PL-200 exam (I’m not going to list specific details around each level here, as they change semi-frequently, and Microsoft has good amount of information around it on their website).

One of the things in recent times that Microsoft has started actively tracking is something called MAU. This stands for ‘Monthly Active Users’. Ideally partners should be creating & deploying solutions that will attract more users within their customer organisations, so this should be a number that grows over time. In fact, partners are actually rated based on their customers MAU figures, so it’s something that’s actually quite important for partners to keep on top of!

So why am I bringing apps (all types!) into this, and talking about it? Well, off the back of a conversation I had with our Microsoft PTS (Partner Technical Specialist) recently, I thought it would be helpful to expand on something.

In the ‘Low Code Application Development’ specialisation, for example, there’s a section around performance. Note that this also appears on other advanced specialisations as well:

We were talking to our PTS around how exactly, as a partner, we can ‘register’ the app so that Microsoft knows that we built it, and how the MAU is measured etc. It really was quite fascinating to delve deeper into this, to gain a better understanding of such things.

Firstly, the process by which a partner registers that they’re a partner who is working in the customer organisation is by a process called PAL (Partner Admin Link). If you’re curious about the process, and wanting to know more, take a look at https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/link-partner-id. There’s a good amount of information there, as well as the process for it.

Now, how does this work exactly? Well, the creator of the app needs to carry out the registration. This essentially says that the creator works for a partner, and associates the partner ID. Microsoft can see who the the creator of the app is, and automatically connects all of the apps that they’ve created to the partner that they’re associating as. This is really the only step that’s needed to be done.

But how does this actually work, behind the scenes? Well, this is the interesting part!

See, every app has an ID that’s automatically generated when the app is first created/saved. This is an automatic part of the process, and isn’t something that we, as app creators, have any control over.

It’s possible to view this by going into the Maker portal, finding the app, and clicking ‘Details’:

This will then show a variety of information about the app, included the App ID:

Now what is interesting is that the underlying app code doesn’t actually show/use this App ID. It has a different GUID that’s used within it to reference the app. So somewhere behind the scenes Microsoft has something that maps one to the other:

So we’ve now seen how each app has it’s own ID. Now for the interesting part (well, I guess that’ll depend on your experience with such things). When an app is deployed through different environments (within the same tenant), the App ID remains the same! So if I have a canvas app in DEV, and then deploy it to UAT, Staging, Pre-Prod, Prod, etc, the App ID will always remain the same.

This is how Microsoft tracks the app through the different environments. This is quite important to note, because the creator of an app may not actually have access to the Production environment (or others), for example. So when we’re needing to register that we’re the owners of an app, we can do so in the Development environment, and it will counted for us across all environments.

Note: This will not work cross-tenant. It’s important to note that even when deploying across tenants, the App ID will remain the same. However Microsoft do NOT track it across tenants – it needs to be registered by the partner in the tenant that it will be used in (regardless of which actual environment). For customers therefore who have a a multi-tenant deployment approach, necessary conversations would need to be had with them as to the best way to handle this.

Now above we’ve mentioned MAU, and that Microsoft tracks this to assess if the partner (who’s created the app) is meeting necessary requirements or not.

Given that developers may not have access to the Production environment, and that some customers like to ‘soft launch’ new apps, measuring MAU at a late point isn’t going to be beneficial to the partner. After all, if you only register PAL when you have 100 users on the app, and the customer only has 120 users overall, the MAU isn’t going to be very significant.

Based on my conversations with Microsoft people around this, it would seem that the best practise would therefore be as follows for the process:

1. App creator creates the app (by saving it). App ID is automatically generated
2. App created registers PAL in the client tenant (this needs to be done once per app creator – all apps created by the same user will automatically be tracked)
3. Microsoft can start tracking the necessary statistics
4. ALM process for deploying the app (& any other components) to take place as usual. Nothing else needs to be done

I hope that this information & guide is useful for people working at Microsoft Partners, and can help them understand how this process works.

If you have any questions or comments, please feel free to drop a comment below – I’d love to hear from you around this!

The post Apps & Microsoft Partner Specialisations appeared first on The CRM Ninja.