Publisher Access control and permissions
11 min
by default, the publisher has full access to the managed resource group and the customer has read only visibility (enforced through deny assignments) while configuring the offer the publisher sets the following items publisher access if management access is enabled, the publisher needs to enter their tenant id as well as the principal id (object id in entra) of the user or group (recommended) that has access to the managed resource group the publishes chooses access level as well (owner/contributor) optionally, instead of standing access, the publisher can request just in time elevated access that the customer approves for a limited period customer access publishers decide at the time of configuring the product if customers should have access they can have full access or only read access (deny assignment), and that can be specified more by adding allowed customer actions important publisher management access and customer access settings cannot be changed after the offer is live in the marketplace get this right before publishing reference plan an azure managed application (microsoft learn) https //learn microsoft com/en us/partner center/marketplace offers/plan azure app managed app the scenario below describes how a typical setup looks like from a customer’s and publisher’s point of view customer access by default, customers can not access the resources inside the resource group because of a deny assignment they can see resources, but creating, updating or deleting is not possible during publication, customer access can set by explicitly checking a box publisher access publishers do get all access by default so when the publisher goes to the managed application center in the azure portal, they would see this clicking on the managed resource group will give them direct access they can create, read, update and delete resources as they have owner or contributor permissions (depending on how the offer is published) updating your application this is where things typically go wrong, so read this section carefully there are two distinct update paths and they must be kept in sync existing customers go into the managed resource group deployed in the customer's subscription (using your management access) and update the product there directly guide update managed resources (microsoft learn) https //learn microsoft com/en us/azure/azure resource manager/managed applications/update managed resources new customers update the zip deployment package in the plan so new deployments install the new version remember republishing can take up to 24 hours warning never ask an existing customer to delete and redeploy just to get a new version redeploying wipes the whole deployment, and that typically means losing data for publishers with mature engineering, updates across many customer subscriptions can be automated with standard ci/cd pipelines and cross tenant management in practice most publishers do this manually per customer sample architecture azure managed application update sample (github) https //github com/azure samples/ama update sample commercial model \<font color="#f3f4f6"> charge \</font> \<font color="#f3f4f6"> who pays it \</font> \<font color="#f3f4f6"> notes \</font> azure infrastructure customer, directly to microsoft for the resources running in their subscription — vms, storage, networking invoiced separately from your software fee product fee customer, through marketplace flat monthly fee only no per user option and no annual term custom meters customer, through marketplace usage based dimensions, on top of or instead of the flat fee store service fee publisher microsoft charges a 3% standard store service fee on transact offers the flat fee limitation only a flat monthly fee is supported as the standard price some publishers emulate one or three year prepaid terms by setting the flat fee to zero and billing through custom dimensions, but renewal and term enforcement then have to be handled outside marketplace — through contract terms plus access control in the application custom metering also carries real operational cost you have to track charges and emit them to microsoft's metering api at the right time that is a technical integration, and it changes the commercial picture too the reporting cadence for usage payouts differs from non usage payouts on the microsoft side note there is also an option to configure a managed app plan for isv billed infrastructure, where the azure resources are billed to you and the customer sees a single flat fee covering infrastructure, licences and management this shifts azure cost risk onto publisher — model it carefully before choosing it cancellation and refunds the customer pays the full monthly fee there is no pro rata refund for a partial month microsoft's refund policy states "you're eligible for a refund of the fixed monthly charge if you delete your managed application within 72 hours of purchase " delete after that window and the charge stands in full \<font color="#f3f4f6"> charge \</font> \<font color="#f3f4f6"> effect of deleting mid month \</font> fixed monthly fee charged in full, no proration invoiced up front via next day invoicing, so it is usually already on an invoice future monthly fees stop deleting the managed application ends the recurring charge custom dimensions billed for actual usage up to deletion never refundable underlying azure resources on the customer's own azure subscription stop when the resources are deleted for cancellations or refunds beyond the 72 hour window, the customer contacts you as the publisher if you approve, you submit a ticket to process it through marketplace pricing policy disclaimer under microsoft's certification policy, the per month price and metered billing on a managed application must only account for the management fee — they may not be used for ip or software costs, azure infrastructure, or add ons costs outside the management fee should be incurred through azure infrastructure charges or pay as you go software costs from the deployed resources, or transacted through a separate vm or container offer how you structure and justify your price is your own responsibility wetransact cannot advise on this split and cannot take responsibility for pricing that does not comply with microsoft policy, so make sure your pricing is defensible as a service fee reference microsoft marketplace certification policies, section 300 2 — acquisition, pricing, and terms https //learn microsoft com/en us/legal/marketplace/certification policies macc and co sell advantage managed applications can earn dual recognition the customer's infrastructure consumption runs in their own subscription and counts toward their azure consumption, while your software fee transacts through marketplace and, when the offer is enrolled correctly, is eligible to decrement the customer's macc (microsoft azure consumption commitment) for you as publisher, managed application consumption can also contribute toward azure ip co sell eligibility thresholds note macc eligibility is per offer, not per product, and the offer must meet all azure ip co sell eligibility requirements first free and byol (bring your own licence) offers are not transactable and do not qualify cancellation and ending the contract when a customer deploys a managed application, two things exist in their subscription the managed application resource — the reference object in the resource group the customer chose the customer fully controls this object the managed resource group — where the actual solution resources live the customer can see it, and can delete it, but cannot look inside by default to cancel, the customer deletes the managed application resource azure then automatically deletes the managed resource group with all its resources and stops future billing the deletion takes a few minutes, and wetransact receives a notification that the order has been cancelled warning deletion is not reversible and takes all deployed data with it make sure the customer has exported anything they need first 💬 for more, contact us at \<font color="#a855f7">\</font>