Commercial marketplace certification policies

These General policies apply to all offer types. Additional policies for each specific offer type are listed below by offer type. Please be sure you review both policy sections for the type of offer you are developing for the marketplace.

The types of offer types supported by the marketplace can be found in the publishing guide by offer type and the Microsoft 365 AppSource documentation. All offers and your publisher activities on Partner Center are subject to the Microsoft Publisher Agreement.

100.1 Value proposition and offer requirements

Test offers are only permitted for private offers and must be labeled "MS Test Offer". Your listing must clearly, concisely, and accurately communicate the value proposition and requirements for your offer. Your offer should represent a distinct product. Your offer must leverage the appropriate offer type as represented in the publishing guide by offer type.

100.1.1 Title

All offers and plans must have an accurate and descriptive title. If your offer is promoted on a website outside of the commercial marketplace, the title on the promotional website should match the title in the marketplace. If your product includes repackaged open-source software or software that was originally created by a vendor other than you, the product title must indicate the value added by your repackaging that distinguishes it. If there is no additional intellectual property added to the product, the product title must include the seller’s name (for example: <Product> with support by <Seller>).

100.1.2 Summary

Offers must have a concise, well written summary of the offer and its intended use. This summary will be shown on the commercial marketplace search results screen and is limited to 100 characters.

100.1.3 Description

All offers and plans must have a description that identifies the intended audience, briefly and clearly explains its unique and distinct value, identifies supported Microsoft products and other supported software, and includes any prerequisites or requirements for its use. The description should not simply repeat the offer summary.

You must clearly describe any limitations, conditions or exceptions to the functionality, features, and deliverables described in the listing and related materials before the customer acquires your offer. The capabilities you declare must relate to the core functions and description of your offer.

Your listing, including the description, metadata, and any other provided content, should describe your offer’s capabilities, strengths, and what makes it desirable, including any compatibility with other offers. Comparative marketing, including using competitor logos or trademarks in your offer listing, or including tags or other metadata referencing competing offers or marketplaces, is not allowed.

100.1.4 Non-English content

Commercial marketplace content (including Storefront text, documents, screenshots, Terms of Use, and Privacy Policy) is not required to be in English. If your offer is published with non-English content, the description must begin or end with the English phrase, "This application is available in <a list of languages including the language of your offer content>." It is also acceptable to provide a Useful Link URL to offer content in a language other than the one used in the marketplace content.

If your offer supports multiple languages, all offer and marketplace listing content should be localized for each supported language. Offers listed in multiple languages must be easily identified and understood.

100.1.5 Active and visible presence

You must maintain an active presence in the marketplace. Offers submitted to the marketplace must be commercially available and under active development and/or supported until they are removed from the marketplace.

Each offer submitted to the marketplace must have at least one public plan, which may be Contact Me, Bring Your Own License (BYOL), or Get It Now (Transact). Private plans are not allowed without a corresponding public plan.

100.2 Discoverability

To help customers discover offers, categories, industries, keywords, and Professional service Solutions Partner designations must accurately identify your expertise. The description of your listing must be relevant to the selected categories and industries.

100.2.1 Categories and Industries

Select the most relevant category or categories in alignment with your offer’s value proposition. The description should help a customer understand how your offer is applicable to the selected categories. A maximum of two categories can be selected.

Select an industry only if your offer is designed to solve a specific need or industry scenario. The industry and/or vertical your offer targets must be included in either the short or long description. Customers should be able to understand from the description how your offer helps them solve a specific industry scenario.

100.2.2 Keywords

Keywords must be relevant to the offer and any supported products. Adding competitor names or products as keywords is not permitted. Categories and titles should not be added as keywords.

100.2.3 Solutions Partner designations (only required for Professional Services offers that are intended for Microsoft first-party software)

You must earn the appropriate Solutions Partner Designations and qualifications depending on the Primary Product your service is supporting. More details in the 810 Professional Service section below.

100.2.4 Listing organization

Products from a single publisher with multiple or related versions of the same product must be grouped under a single listing and the multiple or related versions captured as distinct plans.

100.3 Graphic elements

Graphic elements help customers identify the source and understand the features of your offer. When used, graphic elements must be current, accurate, easy to understand, and related to your offer. Graphic elements include:

Logo
- Logos are uploaded as a .png file between 216- and 350-pixels square. This logo appears on the offer listing page in Azure Marketplace or AppSource.
- An optional 48-pixel square logo may be added later to replace the autogenerated small logo. This logo appears in Azure Marketplace search results or on the AppSource main page and search results.
Images, including screenshots
- Images must be 1280x720 pixel .png files.
- Images should be of good quality: high resolution, sharp, with legible and readable text.
- Comparative marketing, including using competitor logos or trademarks, is not allowed.
Videos
- Videos must be hosted on YouTube or Vimeo; no other video hosts are allowed.
- YouTube and Vimeo links must be direct video links. Short URLs, redirects, or playlists will not work.
- Videos must be publicly viewable and embeddable.
- Videos and their thumbnail images should be of good quality: high resolution, understandable, and related to the offer.
- Video links must lead directly to the individual video page. No short URLs, "human readable" redirects, or other obfuscating services may be used. Account pages, playlists, or other collection pages are not allowed.

100.4 Acquisition, pricing, and terms

Customers need to understand how to evaluate and acquire your offer. Your listing must accurately describe:

How you are providing your offer (for example, as a limited time trial or as a purchase)
Pricing, including currency
Variable pricing structures
Features or content that require an extra charge, whether through in-app or add-in purchases or through other means. Your description must also disclose any dependencies on additional services, accounts, or hardware. Offers cannot have any dependencies on any product or component that is no longer supported or commercially available.

Pricing models must conform to the pricing models supported by the marketplace.

All purchase transactions associated with your offer must begin by using a starting point in the commercial marketplace listing, such as the Contact Me or Get It Now buttons.

Microsoft provides limited native application programming interfaces (APIs) to support in-offer purchases. If your in-offer purchases are not possible with Microsoft's APIs, you may use any third-party payment system for those purchases.

Within the offer listing, you may not redirect or up-sell customers to software or services outside the marketplace. This restriction does not apply to support services that publishers sell outside the marketplace.

You may not promote the availability of your offer on other cloud marketplaces within the offer listing.

The commercial marketplace does not currently support the sale of hardware. Any offers for hardware must be transacted outside of the marketplace. Charges for services such as support included with your offer and billed through the marketplace outside of the professional service offer type may only amount to an ancillary component (less than 10%) of the total price charged to end customers.

100.5 Offer information

Customers need to know how to find out more about your offer. Include relevant offer information:

Terms and conditions
- Should describe the legal terms between you and your customers governing use of your offer
Privacy policy
- Should detail any of your applicable collection, use, and storage of customer data
Documentation
- Should be available, detailed, instructive, and current
"Learn More" links to additional offer information

Links must be functional, accurate, and must not jeopardize or compromise user security. For example, a link must not spontaneously download a file.

100.6 Personal information

Customers and partners care about the security of their personal information. Personal Information includes all information or data that identifies or could be used to identify a person, or that is associated with such information or data. Your listing must not include third-party personal information without authorization. Your listing must include a link to your privacy policy for the listed offer.

100.7 Accurate source

Customers want to know who they are dealing with and expect clarity about the offers and relationships they rely on. All content in your offer and associated metadata must be either originally created by the offer provider, appropriately licensed from the third-party rights holder, used as permitted by the rights holder, or used as otherwise permitted by law. Offers must be unique and cannot duplicate an offer made available by another publisher on the marketplace.

When referring to Microsoft trademarks and the names of Microsoft software, products, and services, follow Microsoft Trademark and Brand Guidelines.

References to Business Programs participation or eligibility are not allowed. Example (but not limited to) references to Microsoft Azure Consumption Commitment (MACC), Partner Co-sell, Co-sell Prioritized, IP Co-sell, MPN Competency, Cloud Solution Partner Designation. Such references must not be included anywhere in the metadata of your offer.

100.8 Significant value

Offers must provide enough value to justify the investment it takes to learn and use them. Your offer should provide significant benefits such as enhanced efficiency, innovative features, or strategic advantages. Simple utilities, offers with limited scope, or offers that duplicate offerings in well-served areas are not a good fit for the commercial marketplace. Offers must provide a useable software solution.

100.10 Inappropriate content

Customers expect offers to be free of inappropriate, harmful, or offensive content. Your offer must not contain or provide access to such content including, but not limited to content that:

Facilitates or glamorizes harmful activities in the real world.
Might pose a risk of harm to the safety, health, or comfort of any person or to property.
Is defamatory, libelous, slanderous, or threatening.
Is potentially sensitive or offensive or that advocates discrimination, hatred, or violence based on membership in a particular racial, ethnic, national, linguistic, religious, or other social group, or based on a person's gender, age, or sexual orientation.
Facilitates or glamorizes excessive or irresponsible use of alcohol or tobacco products, drugs, or weapons.
Contains sexually explicit or pornographic content.
Encourages, facilitates, or glamorizes illegal activity in the real world, including piracy of copyrighted content.
Includes excessive or gratuitous profanity or obscenity.
Is offensive in any country/region to which your offer is targeted. Content may be considered offensive in certain countries/regions because of local laws or cultural norms.

100.11 Security

Customers want to be confident that offers are safe and secure. Your offer must not jeopardize or compromise user security, the security of the Azure service, or related services or systems. These are related criteria:

If your offer collects credit card information, or uses a third-party payment processor that collects credit card information, the payment processing must meet the current PCI Data Security Standard (PCI DSS).
- Your offer must not install or launch executable code on the user's environment beyond what is identified in or may reasonably be expected from the offer listing.
- You must report suspected security events, including security incidents and vulnerabilities of your Marketplace software and service offerings, at the earliest opportunity.
- Your offer should not share any application credentials or access information publicly in the product description page.

100.12 Functionality

Customers expect offers to deliver what they promise. Your offer must provide the functionality, features, and deliverables described in your listing and related materials.

If your offer has trial and paid versions, trial functionality must reasonably resemble the paid version.

Offer user interfaces should not look unfinished. All UI should be intuitive and obvious in purpose, without requiring users to read support documentation for basic tasks.

Your offer should be reasonably responsive. Long wait or processing times should be accompanied by some form of warning or loading indicator.

100.13 Business requirements

Offers you submit to the marketplace must meet applicable business requirements including:

Specific qualification or approval by Microsoft as needed
Appropriately targeting customer segments, categories, or industries
Appropriate configuration including offer type and billing

100.14 Testability

Your offer submission must include any necessary instructions and resources for successful certification of your offer.

100.15 Supporting documents

Your listing may include documents detailing your offer. These can mention Microsoft competitors only when discussing migration to Microsoft products. Do not include confidential information like credentials or internal data.

200 Virtual Machines

To ensure that customers have a clear and accurate understanding of your offer, please follow these additional listing requirements for Virtual Machines (VM) offers.

200.1 Technical Requirements

Offers you publish to the Marketplace must meet the following technical requirements:

The Azure Resource Manager (RM) module may still be used but is being deprecated. We recommend using the Azure PowerShell Az module instead.

In addition to your solution domain, your engineering team should have knowledge on the following Microsoft technologies:

Basic understanding of Azure Services
Working knowledge of Azure Virtual Machines, Azure Storage and Azure Networking
Working knowledge of Azure Resource Manager
Working knowledge of JSON

200.2 Business Requirements

The publisher must be registered through Partner Center and approved for the VM billing plan.

The App Description must match the application included in the Virtual Machine and must have been tested for primary functionality after deployment of the VM image in Microsoft Azure.

Usage/distribution of third-party software and consumption of services must be in compliance with all respective redistribution licensing.

200.3 VM Image Requirements

As a VM image contains one operating system disk and zero or more data disks, one Virtual Hard Drive (VHD) is needed per disk. Even blank data disks require a VHD to be created. You must configure the VM operating system (OS), the VM size, ports to open, and up to 15 attached data disks. Regardless of which OS you use, add only the minimum number of data disks needed by the stock keeping unit (SKU).

200.3.1 General

VM image must be provided in the form of a VHD file and built on an Azure-approved base image.

VM image must be deployable and able to provision on Azure from either the Azure Portal or PowerShell scripts.

Must support deployment of the image with at least the publisher recommended Azure VM Size.

While additional configuration steps may be required by the application, deployment of the VM image allows the VM to be fully provisioned and the OS to start properly.

Image should support enablement of VM Extensions including Azure Diagnostics and Monitoring.

Disk count in a new image version cannot be changed. A new SKU must be defined to reconfigure data disks in the image. Publishing a new image version with different disk counts will have the potential of breaking subsequent deployments based on the new image version in cases of auto-scaling, automatic deployments of solutions through Azure Resource Manager templates, and other scenarios.

Image must be well-formed including standard footer.

VHD image must be submitted via a valid and available Shared Access Signature (SAS) URI.

Choose one or both of the Azure PowerShell or Azure command-line interface (CLI) scripting environments to help manage VHDs and VMs.

Image size must be an exact multiple of 1MB.

OS Architecture must be 64 bits.

Image must have been deprovisioned. See Configure the Azure-Hosted VM: Generalize the Image.

200.3.2 Windows

OS disk size validation should be between 30GB and 250GB.

Data disk size should be between 1GB and 1023GB.

Support Compatibility with Serial Console: Windows: Registry.

Application must not have a dependency on the D: drive for persistent data. Azure offers the D: drive as temporary storage only and data could be lost.

Application usage of the data drive must not have a dependency on C: or D: drive letter designations. Azure reserves C: and D: drive letter designations.

Build lean and limit possible cloud compatibility issues by avoiding dependency and not including specialized Windows Server roles and features such as Failover Cluster, DHCP, Hyper-V, Remote Access, Rights Management Services, Windows Deployment Services, BitLocker Drive Encryption on OS disk, and Network Load Balancing Windows Internet Name Service.

200.3.3 Linux

No swap partition on the OS disk. Swap can be requested for creation on the local resource disk by the Linux Agent. It is recommended that a single root partition is created for the OS disk.

Leverage Endorsed Linux distributions on Azure: /azure/virtual-machines/linux/endorsed-distros. Custom images may be subject to additional validation steps and requiring specific approval from Microsoft.

OS disk size validation should be between 30GB and 1023GB.

Data disk size validation should be between 1GB and 1023GB.

Support Compatibility with Serial Console – parameter Linux: console=ttyS0.

The latest Azure Linux Agent should be installed using the repair manager (RPM) or Debian package. You may also use the manual install process, but the installer packages are recommended and preferred.

No swap partition on the OS disk. Swap can be requested for creation on the local resource disk by the Linux Agent. It is recommended that a single root partition is created for the OS disk.

Choose one or both of the Azure PowerShell or Azure command-line interface (CLI) scripting environments to help manage VHDs and VMs.

Secure Shell (SSH) server should be included by default.

Your VM image must boot and reboot successfully.

Your VM image must be able to connect to the network. DNS name resolve successfully.

Your VM image can’t contain any pre-existing users or password.

VM image must boot and reboot successfully when provisioning with premium disk.

VM image must boot and reboot successfully when provisioning with standard ssd disk.

VM image must boot and reboot successfully when provisioning with ephemeral managed disk.

VM image must boot and reboot successfully when provisioning with synthetic NIC.

VM image must boot successfully on reboot operation.

VM image must boot and reboot successfully on stop and start operation.

Microsoft Hyper-V virtual network driver 'hv_netvsc' must be installed on your image installed.

Images should not contain any antivirus solution, remote management tools, or other software that allows login or data access for anyone other than the end user. Security solutions like Microsoft Defender Advanced Threat Protection, Microsoft Defender for Endpoint, and Microsoft Defender for Cloud should not be pre-installed by image publishers. See Generalize the image without Defender

200.4 VM Image Generalization

All images in the Azure Marketplace must be reusable in a generic fashion. To achieve this reusability, the operating system VHD must be generalized, an operation that removes all instance-specific identifiers and software drivers from a VM. The operating system VHD for your VM image must be based on an Azure-approved base image that contains Windows Server or SQL Server.

If you are installing an OS manually, then you must size your primary VHD in your VM image. For Windows, the operating system VHD should be created as a 127-128 GB fixed-format VHD. For Linux, this VHD should be created as a 30-50 GB fixed-format VHD.

Windows OS disks are generalized with the sysprep tool. If you subsequently update or reconfigure the OS, you must rerun sysprep.

Ensure that Azure Support can provide our partners with serial console output when needed and provide adequate timeout for OS disk mounting from cloud storage. Images must have the following parameters added to the Kernel Boot Line: console=ttyS0 earlyprintk=ttyS0 rootdelay=300.

200.5 Security

Ensure that you have updated the OS and all installed services with all the latest security and maintenance patches. Your offer should maintain a high level of security for your solution images in the Marketplace.

All the latest security patches for the Linux distribution must be installed and industry guidelines to secure the VM image for the specific Linux distribution must be followed. It is recommended that Logical Volume Manager (LVM) should not be used.

Images should not include significant Common Vulnerability and Exposures. Verify the following:

Windows must have the latest security patches.
Linux minimum kernel versions including latest security patches.
Latest versions of required libraries should be included:
- OpenSSL v1.0 or greater.
- Python 2.6+ is highly recommended.
- Python pyasn1 package if not already installed.
- Linux Azure Agent 2.2.10 and above should be installed.
Firewall rules must be disabled unless application functionally relies on them, such as for a firewall appliance.
The source code and resulting VM image must be scanned for malware and verified to be malware free.
All code that is considered suspicious (such as penetration tests and exploits) shall be identified and disclosed to limit false positive detections by malware monitoring tools.
All non-OS scheduled tasks shall be well identified to limit exposure to CRON job type malware.
Limit the attack surface by keeping a minimal footprint with only necessary Windows Server roles, features, services, and networking ports.
Applications should not have a dependency on restricted usernames such as 'Administrator,' 'root', and 'admin'.
Bash/Shell history entries must be cleared.
Azure expects the VM images to be free of any known vulnerability to keep customer workloads secure.

Your offer should use a secure OS base image.

The VHD used for the source of any image based on Windows Server must be from the Windows Server OS images provided through Microsoft Azure.
Do not use the solution VHD (such as the C: drive) to store persistent information.
The VHD image must only include necessary locked accounts that do not have default passwords that would allow interactive login; no back doors are allowed.
All sensitive information, such as test SSH keys, known hosts file, log files, and unnecessary certificates, must be removed from the VHD image.

If Trusted Launch is enabled on your VM, then the following requirements apply:

Only trusted bootloader can be loaded by the UEFI firmware to ensure the bootloader's digital signature hasn't been modified. Please ensure the image OS bootloader is signed with one of the two certificates below to securely boot the Trusted Launch VM: - Windows:Microsoft Windows Production PCA 2011 - Linux:Microsoft Corporation UEFI CA 2011
Trusted Launch attestation proves the VM health to Microsoft Attestation service cryptographically using Trusted Platform Module (TPM) measurements of boot process. This test also detects any unauthorized or unsigned components running on the VM.

If Confidential is enabled on your VM, then the Trusted Launch requirements apply in addition to the following:

Confidential VMs are provisioned with secure boot as default with confidential disk encryption using platform managed key. Learn more about the features of confidential VMs.
Confidential VM attestation helps to confirm that the VM is running on a hardware-based trusted execution environment (TEE) with security features enabled for isolation and integrity. It uses TPM measurements of the boot process. This test also detects the unauthorized or unsigned components running on VM. Learn more about Confidential VM attestation.

200.6 Testing and Certification

After you create and deploy your Virtual Machine (VM), you must test and submit the VM image for Azure Marketplace certification with the Certification Test Tool. Instructions for using the tool are available at the Certify your VM image page. If any of the tests fail, your image is not certified. In this case, review the requirements and failure messages, make the indicated changes, and rerun the test.

During the publishing process, you must provide a uniform resource identifier (URI) for each virtual hard disk (VHD) associated with your SKUs. Microsoft needs access to these VHDs during the certification process. When generating shared access signature (SAS) URIs for your VHDs, adhere to the following requirements:

Only unmanaged VHDs are supported.
List and Read permissions are sufficient; do not provide Write or Delete access.
The duration for access (expiry date) should be a minimum of three weeks from when the SAS URI is created.
To safeguard against Coordinated Universal Time (UTC) variations, set the start date to one day before the current date; for example, if the current date is October 6, 2019, select 10/5/2019.

Review and verify each generated SAS URI by using the following checklist. Verify that:

The URI is of the form: <blob-service-endpoint-url> + /vhds/ + <vhd-name>? + <sas-connection-string>
The URI contains your VHD image filename, including the filename extension ".vhd"
Towards the middle of the URI, sp=rl appears; this string indicates that Read and List access is specified
After that point, sr=c also appears; this string indicates that container-level access is specified

You can use the VM Self-test Service API to pre-validate that a Virtual Machine (VM) meets the latest Azure Marketplace publishing requirements.

Preview images are stored during the testing and preview phase of the offer publication process and are not visible to customers. Microsoft may remove inactive images from storage.

220 Network Virtual Appliances (NVAs)

An NVA offer submitted to Azure Marketplace goes through the certification process. To ensure the offer is certified and published on Azure Marketplace, it must meet all the following requirements.

220.1 NVA Internal Service Error

NVA Offers are qualified by a certification service that can sometimes result in an internal error. In this case, publisher will see an error message with Policy ID as 220.1 and no action is needed by the publisher.

220.2 NVA VHD Access

The certification process begins by accessing the Virtual Hard Disk (VHD) image of your offer. Ensure the VHD can be accessed without any issue.

The correct SAS URL is provided for the VHD
The VHD is accessible
The NVA image is generalized

220.3 NVA boot performance

Please ensure your virtual appliance supports up to 8 network interfaces and that it is functional within 20 minutes of being started.

220.6 NVA High Availability

One of the most common architectures is to deploy NVAs in a High Availability configuration using a Load Balancer. To pass this test, ensure the following requirements are met:

The NVA is reachable through the Internal load balancer's frontend IP
For High Availability configurations, the appliance must be compatible with the HA Ports feature on the Internal Load Balancer

220.7 NVA VNET Peering

NVA products must support virtual network peering and global virtual network peering (Learn more about VNet peering)

220.8 NVA Accelerated Networking

Please ensure the following requirements are met for Accelerated Networking testing:

Accelerated Networking can be enabled and disabled on a NIC in the NVA VM
Traffic is allowed through the NVA NICs on which Accelerated Networking is enabled and disabled

220.9 NVA Multi-NIC basic

Ensure that when NVA is deployed with multiple NICs, the private IP address and MAC address of the NVA Network Interface Cards (NICs) are unchanged after redeployment.

220.10 NVA Network Disruption

On a VM deployed using the NVA image, verify that after configuring a Network Security Group (NSG) to block all incoming traffic, the VM status remains Running.

300 Azure Applications

The policies listed in this section apply only to Azure Applications offers.

300.1 Value proposition and offer requirements

The Azure Application offer type must be used when the following conditions are required:

You deploy a subscription-based solution for your customer using either a VM or an entire IaaS-based solution.
If you or your customer requires that the solution be managed by a partner, then the Azure Application SKU type should be used.

300.2 Acquisition, pricing, and terms

The resources will be provisioned in the customer's Azure subscription. Pay-as-you-go (PAYGO) virtual machines will be transacted with the customer via Microsoft, billed via the customer's Azure subscription (PAYGO).

In the case of bring-your-own-license, Microsoft will bill infrastructure costs incurred in the customer subscription, and you will transact your software licensing fees to the customer directly.

Pricing for your Azure App using the per-month price and metered billing must only account for the management fee (i.e., may not be used for IP/software costs, Azure infrastructure, or add-ons). All costs outside of the management fee should be incurred through any Azure infrastructure or pay-as-you-go software costs incurred by the resources deployed by this solution.

300.3 Functionality

VMs must be built on Windows or Linux.

Azure applications must be deployable through the commercial marketplace.

300.4 Technical requirements

The Azure Resource Manager (ARM) Template being leveraged should deploy your solutions from the Azure Marketplace or Azure provided services.

For more details on the following requirements, see the Azure Resource Manager Templates best practices guide.

300.4.1 Code

Code must pass the best practice tests.

Code must address any comments provided as part of the code review in the certification process.

300.4.2 Security

All firewall rules and network security groups (NSGs) must be reasonable for the application.

Role-based access control (RBAC) assignments should use the least privilege required and must have a justification for "owner".

Passwords in createUIDef must have a minimum of 12 characters or use the default settings.

Managed Service Identity (MSIs) must be assigned a role. Unused MSIs must be removed.

300.4.3 Variables

Any declared variables must be used.

300.4.4 Parameters

Any declared parameters must be used.

Values such as username and password (secrets) must always be parameterized.

Any defaultValue supplied for a parameter must be valid for all users in the default deployment configuration.

Do not provide default values for user names, passwords (or anything that requires a SecureString, or anything that will increase the attack surface area of the application.

Templates must have a parameter named location for the primary location of resources.

The default value of this parameter must be [resourceGroup().location].
The location parameter must not contain allowedValues. Location values may be restricted in CUID but not the template.

Do not use allowedValues for lists of things that are meant to be inclusive (for example, all VM SKUs). allowedValues should only be used for exclusive scenarios. Overusing allowedValues will block deployment in some scenarios. Resources without built-in controls in createUIDef may only be populated with values that can be validated in createUIDef.

300.4.5 Resources

Top-level template properties must be in the following order:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/...",
  "contentVersion": "1.0.0.0",
  "apiProfile": "...",
  "parameters": {},
  "functions": {},
  "variables": {},
  "resources": [],
  "outputs": {},
}

All empty or null properties that are not required must be excluded from the templates.

Resource IDs must be constructed using one of the resourceId() functions.

Any reference to a property of a resource must be done using the reference() function.

Hard-coded or partially hard-coded URIs or endpoints are not allowed.

The apiVersion specified for a resource type must be no more than 24 months old. A preview apiVersion must not be used if a later version (preview or non-preview) is available.

The apiVersion property must be a literal value.

Each VM extension resource must have the autoUpgradeMinorVersion property set to true.

Any secureStrings used by extensions must use protectedSettings.

300.4.6 CUID (`createUIDef`)

Regex validation of textbox controls must match the intent of the control and properly validate the input.

All properties must be output for each control in createUIDef.

300.4.7 Deployment artifacts

All of the artifacts needed for deployment must be included in the zip file submitted for publishing.

mainTemplate.json and createUIDefinition.json must be in the root of the folder.

Applications that create resources for which there is no createUIDefinition element must not prompt for input of any names or properties of these resources that cannot be validated.

Scripts, templates, or other artifacts required during deployment must be staged to enable a consistent deployment experience throughout the development and test life-cycle, including command line deployment with the scripts provided at the root of the repository. To do this, two standard parameters must be defined:

_artifactsLocation – The base URI where all artifacts for the deployment will be staged. The defaultValue must be [deployment().properties.templateLink.uri].
_artifactsLocationSasToken – The sasToken required to access _artifactsLocation. The default value should be an empty string ("") for scenarios where the _artifactsLocation is not secured.

300.4.8 VM image references and disks

All imageReference objects for virtual machines or virtual machine scale sets must use core platform images, or images that are available in the commercial marketplace. Custom images cannot be used.

An imageReference using an image from the commercial marketplace cannot be a preview or staged version of the image in production deployments.

An imageReference using an image from the commercial marketplace must include information about the image in the plan object of the virtual machine.

If a template contains an imageReference using a platform image, the version property must be the latest version.

VM sizes must be selected using the VM SizeSelector control in createUIDef, and passed to the template as a parameter.

VM sizes in allowed values must match the storage type selection (premium, standard, or standard SSD).

OS Disks and Data Disks must use implicit managed disks.

400 Azure container offers

When publishing an offer in Partner Center, ensure you follow the policies listed below. This ensures customers can easily find and deploy your offer securely and easily in the commercial marketplace.

400.1 Technical requirements

Adhere to the following technical requirements to ensure successful submission of your offer:

Ensure your application can be deployed using a helm chart.
- The application must be deployable to Linux environment.
- The images must be of amd64 architecture.
- All the image repos and digest details must be included in the chart. No additional charts or images can be downloaded at runtime.
Package your application artifacts as a CNAB bundle.
Published application must be deployable on Azure Kubernetes service.

400.2 Business requirements

Publishing an Azure container offer requires the following:

Usage/distribution of third-party software and consumption of services must follow all respective redistribution licensing.
Select a billing model (e.g. percore, pereverycoreincluster) per offer/plan. Add labels to pods relevant for percore billing.
Add the term KubernetesApps to offer description to make it easily discoverable by customers.

Custom meters may only be used for the consumption or usage of software that has already been consumed (for examples go here ). Custom meters should be used for the offer IP only (i.e. not used for add-ons, services, or additional IP).

400.3 Security

Your product must not jeopardize or compromise user security, or the security or functionality. You are solely responsible for all product safety testing, and the implementation of any appropriate feature safeguards.

Your product must not contain or enable malware as defined by the Microsoft criteria for Unwanted and Malicious Software.
Your product must address all known vulnerabilities.

Microsoft performs regular security validations on container offers. If vulnerabilities are identified in a published offer, Microsoft reserves the right to hide/deprecate the offer (with or without advanced notification to the publisher) to ensure the safety of our customers. You can republish your offer after the vulnerabilities are remedied. When possible, we will notify you of any vulnerabilities identified and provide a timeline for you to fix them.

600 IoT Edge Modules

To ensure that customers have a clear and accurate understanding of your offer, please follow these additional listing requirements for IoT Edge Modules offers.

600.1 Offer Information

Offers must link to supported IoT Edge devices in the IoT device catalog. General-purpose modules must link to the device catalog with the text "List of compatible IoT Edge certified devices" linked to https://aka.ms/iot-edge-certified.

600.2 Plan Information

SKU metadata must meet the following requirements:

Manifest and image tags must be properly formatted and consistent. The "latest" tag must be listed.
Defaults must be accurate:
- Routes must be specific and use the proper syntax.
- Twin desired properties value syntax must be proper non-escaped JSON, without arrays or values exceeding 512 characters, and with a maximum four (4) levels of nested hierarchy.
- Environment variable value must be less than 512 characters.
- createOptions value must be proper non-escaped JSON, without values exceeding 512 characters, and not granting privileged rights unless absolutely necessary.

600.3 Technical Requirements

Containers must meet the following requirements:

The "latest" tag must be a manifest tag available in the container registry.
All image tags referred to by manifest tags must be present in the registry.
All version tags must be immutable.

The module must start, run, and remain stable with the default options.

The "latest" tag must run with the default configuration options on all claimed supported OS/architectures. For general-purpose modules, this means supporting x64, arm32, and arm64 under both Linux and Windows (x64 platform only).

Modules that include the IoT SDK and are set to the PartnerId.OfferIdPlanId must send telemetry.

700 Managed Services

The policies listed in this section apply only to Managed Services offers.

700.1 Value proposition and offer requirements

The term "managed service" or "managed services" must be included somewhere in the offer description.

Managed services offers must have the primary purpose of providing services that manage customers' use of Azure. Offerings, with the primary purpose of selling licenses or subscriptions to software or a platform, must instead be listed as an application.

700.3 Graphic elements

No text other than official logo marks may be used in logo images.

Logo backgrounds should not be black, white, or gradients. If a transparent background is used for the required logos, logo elements should not be black, white, or blue. Hero logos may not use transparent backgrounds.

700.4 Business requirements

You must have Solutions Partner designation for Infrastructure (Azure) or Security.

700.5 Plan details

Plan titles, summaries, and descriptions must be descriptive of the plan.

The billing model for plans must be "Bring your own license".

700.6 Plan manifest details

Manifest version numbers must be in the n.n.n format (for example, 1.2.5).

810 Professional Services

The policies listed in this section apply only to Professional Services offers.

810.1 Value proposition

Professional Services must be fixed in scope and have a defined outcome. Offers with the primary purpose of selling licenses or subscriptions to software or a platform must instead be listed as an application.

810.2 Eligibility requirements

Primary Product: Azure	Eligibility Requirement(s)
Azure	Solutions Partner designation with a qualified score for Data & AI (Azure), Infrastructure (Azure), Digital & App Innovation (Azure), or Security.

Primary Product: Dynamics 365	Eligibility Requirement(s)
Dynamics 365 Business Central	Solutions Partner designation for Business Applications OR Have at least two associated Dynamics 365 Business Central customer deployments in the trailing 12 months (either through DPOR, CPOR,or OSU).
Dynamics 365 Customer Engagement Applications (Sales, Marketing, Customer Service, Field Service, HR)	Solutions Partner designation for Business Applications OR Have at least two associated Common Data Service customer deployments.
Dynamics 365 Customer Insights	Solutions Partner designation for Business Applications OR Have at least one associated Customer Insights customer deployments via PAL in the trailing 12 months.
Dynamics 365 Finance and Operations Applications (Finance, Supply Chain Management, Commerce, Project Service Automation)	Solutions Partner designation for Business Applications OR Have at least two associated Finance and Operations, Retail, and/or Core HR customer deployments in the trailing 12 months (either through DPOR, CPOR, or OSU).
Power BI	Solutions Partner designation for Business Applications or Data and AI (Azure) OR Have at least two associated Power BI customer deployments via PAL in the trailing 12 months.
Power Apps	Solutions Partner designation for Business Applications or Digital and App Innovation (Azure) OR Have at least two PAL associated Power Apps customer deployments.
Power Automate	Solutions Partner designation for Business Applications or Digital and App Innovation (Azure) OR Have at least two PAL associated Power Automate customer deployments.
Power Virtual Agents	Solutions Partner designation for Business Applications or Digital and App Innovation (Azure) or Data & AI (Azure) OR Have at least two PAL associated Power Automate customer deployments.
Power Pages	Solutions Partner designation for Business Applications or Digital and App Innovation (Azure) or Have at least two PAL associated Power Apps customer deployments in the trailing 12 months.
Dynamics 365 Mixed Reality	Solutions Partner for Business Applications OR If the offer is focused on Guides, you should have at least one associated Guides customer deployment in the trailing 12 months. If the offer is Remote Assist, you must have at least one associated Remote Assist customer deployment in the trailing 12 months.

Primary Product: Microsoft 365	Solution Path	Eligibility Requirement(s)
	Adoption and Change Management	Solutions Partner designation with a qualified score for Modern Work.
	Calling for Microsoft Teams	Solutions Partner designation with a qualified score for Modern Work.
	Cloud Security	Solutions Partner designation with a qualified score for Security.
	Compliance Advisory Services	Solutions Partner designation with a qualified score for Security.
	Device Deployment and Management	Solutions Partner designation with a qualified score for Modern Work (if Windows or Devices), Security (if Enterprise Mobility Management.
	Firstline Workers	Solutions Partner designation with a qualified score for Modern Work (if Cloud Productivity), Security (if Enterprise Mobility Management).
	Identity & Access Management	Solutions Partner designation with a qualified score for Security.
	Information Protection & Governance	Solutions Partner designation with a qualified score for Security.
	Insider Risk	Solutions Partner designation with a qualified score for Security.
	Knowledge and Insights	Solutions Partner designation with a qualified score for Modern Work.
	Meetings for Microsoft Teams	Solutions Partner designation with a qualified score for Modern Work.
	Meeting Rooms for Microsoft Teams	Solutions Partner designation with a qualified score for Modern Work.
	Microsoft 365 Live Events Solutions Partner designation with a qualified score for Modern Work.
	Mobile Device Management	Solutions Partner designation with a qualified score for Modern Work (if Windows & Devices), Security (if Enterprise Mobility Management).
	Power Platform for Teams	Solutions Partner designation with a qualified score for Modern Work (if Cloud Productivity), Business Applications (if Cloud Business Applications).
	Teams Custom Solutions	Solutions Partner designation with a qualified score for Modern Work (if Cloud Productivity), Business Applications (if Cloud Business Applications), Digital & App Innovation (Azure) (if Application Development / App Integration).
	Teamwork Deployment	Solutions Partner designation with a qualified score for Modern Work.
	Threat Protection	Solutions Partner designation with a qualified score for Security.
	Workplace Analytics	Solutions Partner designation with a qualified score for Modern Work (if Cloud Productivity), Data & AI (Azure) (if Data Analytics).

For more information on meeting these prerequisites, see the Professional Services prerequisites.

The following sections provide more detail on publishing requirements for "Power" offer types noted in the table above.

810.2.2 Primary Product: Dynamics 365 Apps on Dataverse and Power Apps (Sales, Marketing, Customer Service, Field Service, HR and Customer Voice)

To publish a Dynamics 365 Apps on Dataverse and Power Apps Professional service offer in the marketplace, you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications solutions partner.

Have at least two associated Common Data Service customer deployments in the trailing 12 months (either through DPOR, CPOR, or OSU).

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications

810.2.3 Primary Product: Dynamics 365 Finance and Operations Applications (Finance, Supply Chain Management, Commerce, Project Operations)

To publish a Dynamics 365 Finance and Operations Professional Service offer in the Marketplace you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner.

Have at least two associated Finance and Operations, Retail, and/or Core HR customer deployments in the trailing 12 months (either through DPOR, CPOR, or OSU).

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

810.2.4 Primary Product: Dynamics 365 Customer Insights

To publish a Dynamics 365 Customer Insights Professional service offer in the marketplace, you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner.

Have at least one associated Customer Insights customer deployments via PAL in the trailing 12 months.

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

For more information on validating your customer deployment projects using PAL, please see Link a partner ID to your account that’s used to manage customers.

810.2.5 Primary Product: Dynamics 365 Business Central

To publish a Dynamics 365 Business Central Professional Service offer in the Marketplace you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner.
OR have at least two associated Dynamics 365 Business Central customer deployments in the trailing 12 months (either through DPOR, CPOR,or OSU).

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

810.2.6 Power BI

To publish a Power BI Professional service offer in the marketplace, you must Enrolled in the Microsoft Cloud Partner Program as a Solutions Partner for Business Applications OR Solutions Partner for Data & AI.

Have at least two associated Power BI customer deployments via PAL in the trailing 12 months.

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

For more information on validating your customer deployment projects using PAL, please see Power Apps Acccounts.

810.2.7 Power Apps

To publish a Power Apps Professional Service offer in the marketplace you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner or Digital and App Innovation (Azure).

Have at least two PAL associated Power Apps customer deployments in the trailing 12 months.

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

For more information on validating your customer deployment projects using PAL, please see Link a partner ID to your Power Platform and Dynamics Customer Insights accounts.

810.2.9 Power Automate

To publish a Power Automate Professional Service offer in the marketplace, you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner or Digital and App Innovation (Azure).

Have at least two PAL associated Power Automate customer deployments in the trailing 12 months.

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

For more information on validating your customer deployment projects using PAL, please see Link a partner ID to your Power Platform and Dynamics Customer Insights accounts.

810.2.10 Power Virtual Agents

To publish a Power Virtual Agents Professional Service offer in the marketplace, you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner or Digital and App Innovation (Azure) or Data & AI (Azure).
OR

Have at least two PAL associated Power Automate customer deployments in the trailing 12 months.

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications.

For more information on validating your customer deployment projects using PAL, please see Power Apps Accounts.

810.2.11 Power Pages

To publish a Power Pages Professional Service offer in the marketplace you must be Enrolled in the Microsoft Cloud Partner Program as a Solutions Partner for Business Applications or Digital and App Innovation (Azure).

Have at least two PAL associated Power Apps customer deployments in the trailing 12 months. For More on information on how to become a Solutions Partner please see Solutions Partner for Business applications - Partner Center | Microsoft Learn

For more information on validating your customer deployment projects using PAL, please see Link-partner-id-power-apps-accounts

810.2.12 Primary Product: Dynamics 365 Mixed Reality

To publish a Dynamics 365 Mixed Reality Professional service, offer in the marketplace, you must be Enrolled in the Microsoft Cloud Partner Program as a Business Applications Solution Partner.

If the offer is focused on Guides, you should have at least one associated Guides customer deployment in the trailing 12 months. If the offer is Remote Assist, you must have at least one associated Remote Assist customer deployment in the trailing 12 months.

For more on information on how to become a Solutions Partner please see Solutions Partner for Business Applications

810.3 Title

Your offer Title must not include your company name unless it is also a product name. For example, CompanyX Assessment

810.4 Summary and description

The Summary and Description must provide enough detail for customers to clearly understand your offer, including:

Service deliverables and outcomes.
Agendas for workshops longer than one day.
Detailed itemization of briefing and workshop topics.

Any Applicable Products and keywords defined during submission must be directly relevant to the offer.

If mentioned in the summary or description, the offer type must match the type specified during submission.

810.4.1 Quality

Duplicate Description The descriptions cannot be the same for multiple offers. Each description should accurately represent and differentiate the services associated with the offers. 7For more information, please see:

Missing Estimated Price Rationale If you provide an estimated price, an explanation of why it is estimated and what factors influence the final price must be included in the description. Please update the description with this information and resubmit your offer.
Example: Price is based on scope of work

For more information, please see:

Extraneous Content in Description Your description includes a notable amount of marketing or promotional information not directly relevant to the offer. Please remove the extraneous content and resubmit your offer. For more information, please see:

810.4.2 Content

Summary

Please briefly describe the purpose or goal of your offer in 200 characters or fewer. Your summary cannot be the same text as the title of the offer. This will be displayed in the search box and must be different from the name of the offer.

Example: Free 2 hour assessment on how to use Office 365 and SharePoint with Power Apps, Power Automate, Dataverse, and Power BI by industry leading partner, trainer, and thought leaders. See Offer Listings.

Primary Product Content

Explain how the primary product is part of this offer by specifically mentioning it and making it clear. Our goal is not to just publish your offer, but to drive more leads that will help move your business forward. It needs to be clear to the potential customer how your service is going to help their business. See Primary products and online stores.

Deliverables and Outcomes

Your description needs to have deliverables and outcomes using Markdown language for bullet points. Examples:


### Deliverables 
* List of applicable solutions that can be built using Office 365, SharePoint, Power Apps, Flow, Power BI, > and Dataverse 
* Skill gap assessment of your current staff 
* License review 
* Recommendations on where and how to start using Power Apps, Flow, CDS, and Power BI with SharePoint and > Office 365 
 
You may format your description using Markdown formatting (### Header, * Bullet, *Italics*, **Bold**) or simple HTML. Partner Center also allows rich text formatting.

If you are using HTML, check the PREVIEW before you go live. You may want to switch to Markdown formatting if the bullets aren’t rendering properly.

See Offer Listings.

Agenda

Workshops longer than a day should include a clear daily or weekly agenda in the description. Please see examples below:


### Agenda 
* Day 1: Dashboard-in-a-Day using Power BI 
* Day 2: Design the reporting platform for your enterprise 
* Day 3: Develop and deploy the relevant visualizations on the Power BI reporting platform 
* Day 4 & 5: Remote Support

Or

### Weekly Agenda 
* Week 1: Design the reporting platform for your enterprise 
* Week 2: Develop and deploy the relevant visualizations on the Power BI reporting platform 
* Week 3: Remote Support 
 
You may format your description using Markdown formatting (### Header, * Bullet, *Italics*, **Bold**)  or simple HTML. Partner Center also allows rich text formatting.

If you are using HTML, check the PREVIEW before you go live. You may want to switch to Markdown formatting if the bullets aren’t rendering properly.   See Offer Listings.

Topics for Briefings

Briefings should include at least four bullets with information on topics to be covered, using Markdown formatting for the bullet points. Examples:


**What does this Briefing include?**
 
* Review your existing Microsoft Excel or Microsoft Access based business processes
* Discuss your current goals and limitations
* The alternatives and approaches with Power Platform
* Review the licensing options and costs
* Discuss the "Citizen Developer" capabilities

You may format your description using HTML. Links to external resources (such as license agreements) should be properly HTML formatted for readability and useability (“clickability”) instead of being plain text URL strings. If you do so, check the Preview before you go live.   If you are using HTML, check the PREVIEW before you go live. You may want to switch to Markdown formatting if the bullets aren’t rendering properly.   See Offer Listings.

Omits Microsoft Cloud Solutions Aspects

The description of your offer must clearly state how it leverages or relates to [Choose one: Microsoft Azure, Microsoft Power BI, etc.] cloud services value propositions, and state how the offer is providing a professional service for the selected primary product. Update the description and resubmit your offer.

See Offer Listings.

Contact Info in Description

The description of your offer should not contain contact information. However, it may direct customers to the "Contact Me" button on the offer page to start a discussion. Update the description and resubmit your offer

810.5 Supporting documents

Your listing may include supporting documents with further information for your offer. Documents may feature Microsoft competing products only in the context of migration to Microsoft products.

1000 Software as a Service (SaaS)

The policies listed in this section apply only to SaaS offers.

1000.1 Value proposition and offer requirements

For your SaaS offer to be listed on Azure Marketplace, it must be primarily platformed on Microsoft Azure.

The following are generally supported scenarios:

Hosted - your entire product and all components are hosted in your Azure infrastructure for Azure customers.
Migrations to Azure - your product migration tooling has Azure as its only destination for migration, but can run on-premises or on another cloud as a migration source.
Backup or data replication to Azure - your backup, replication, or data product replicates data only to Azure, while the product’s control plane can run on-premises or on other clouds.
Azure platformed SaaS with external dependencies - your product compute and/or data plane runs on Azure, but smaller control planes or support infrastructure, such as logging, run on-premises or on another cloud. In this case, your Azure-hosted compute and/or data plane must be the resource whose consumption increases the fastest when your users increase their consumption
Azure platformed SaaS with smaller, peripheral agents - your product's compute and/or data plane runs on Azure. Your product's monitoring or security agents can run on-premises or on another cloud or on the customer’s tenant, but they must send data to an Azure-hosted environment for storage and analysis.

If your product requires components to be deployed in the customer’s Azure tenant, the following requirements apply:

The components being deployed to the customer’s Azure tenant must be deployed through an Azure Marketplace offer.
The components must be provisioned in a secure manner. For example, using Azure Role Based Access Control (RBAC), Azure Active Directory Service Principals, or Azure Lighthouse.

For your SaaS offer to be listed on AppSource, it must meet these criteria:

Integrate with or extend a Microsoft service or product and your offer must describe how it does so.
Accept single sign-on from work accounts from any company or organization that has Azure Active Directory (AAD). More information is at Get AppSource certified for Azure Active Directory.

1000.2 Offer targets

Offer categories may only include Internet of things (IoT), if the offer supports Azure IoT Services such as IoT Hub or Device Provisioning Service (DPS), and the partner has been approved by the IoT team.

1000.3 Authentication options

If you choose to sell through Microsoft, the marketplace buyer must be able to activate their subscription using the Azure Active Directory (Azure AD) log in information that they used to purchase your marketplace offer. This means that your offer landing page and your application must allow the marketplace buyer to log in using Azure AD Single Sign-On (SSO). If you process transactions independently using the Get it now or Free trial options, the marketplace user that acquires your offer must be able to log in to your application using Azure AD SSO.

Offers must support both Azure AD and Microsoft Account (MSA) types.

You must limit your Microsoft Graph API request(s) to use only the "User.Read" permissions during the marketplace subscription activation process. Requests requiring additional permissions can be made after the subscription activation process has been completed. See Microsoft’s guidance on incremental consent to learn more.

1000.4 SaaS Fulfillment and Metering APIs

Your SaaS offer must be integrated with the SaaS Fulfillment APIs and the integration must be kept up to date. See the technical SaaS fulfillment APIs guidelines.

For Webhook implementation, you must follow the documented guidelines. See Implementing a webhook on the SaaS service.

If your SaaS offer uses meters for billing, it must also be integrated with the metered billing API. See the metered billing APIs guidelines

Custom meters may only be used for the consumption or usage of software that has already been consumed. Custom meters should be used for the offer IP only (i.e., not used for hardware, services, or additional IP).

1000.5 Microsoft 365 App and Add-In Linking

Microsoft 365 apps and add-ins linked to your SaaS offer must extend your SaaS offer's user experience and functionality. In addition:

You must be the publisher of both the SaaS offer and the app or add-in(s), or
You must provide written authorization from the publisher of the SaaS offer or app or add-in to which you are trying to link your offer.

1000.6 Landing Page

The landing page for your SaaS offer must comply with the following:

The landing page must always be available and functional. Clear, user-friendly messages should be displayed for errors or access denials.
The landing page should display information necessary to complete the configuration. It must not display any sensitive customer data (e.g, authorization tokens, passwords, API Keys).
The landing page must comply with the inappropriate content policy as defined in 100.10 and the Microsoft Trademark and Brand Guidelines.
You may not prompt any installations or downloads on the landing page.

1100 Microsoft 365

The policies listed in this section apply only to Microsoft 365 offers, formerly known as Office 365 offers.

1100.1 General content

Your offer listing must only describe your app or add-in, and not include advertising for other offers.

Your offer description must disclose any app or add-in features or content that require an extra charge, whether through in-app or add-in purchases or through other means.

If your product offers in-app purchases, you must select the "My product requires purchase of a service or offers additional in-app purchases" check box on the Product Setup tab when submitting your offer via Partner Center.

Office Add-ins must have a clear value proposition and provide a seamless first run experience (FRE). If users must sign in or sign up to use the add-in, the value proposition must be clear to the user before they do so.

1100.3 Selling additional features

Apps or add-ins running on mobile must not offer any additional features or content for sale.

1100.4 Predictable behavior

Your app or add-in must not make unexpected changes to a user's document.

Your app or add-in must not launch functionality outside of the app or add-in experience without the explicit permission of the user.

Your app experience must not prompt a user to disclose the credentials of a Microsoft identity (for example, Microsoft 365 (formerly called Office 365) or Microsoft Azure Organizational Account, Microsoft Account, or Windows Domain Account) except through Microsoft approved OAuth flow, where your app is authorized to act on behalf of the user.

1100.5 Customer control

Your app or add-in must obtain consent to publish personal information.

Your app or add-in must not obtain, store, pass, or transmit customer information or content without notifying the user.

Your app or add-in must be secured with a valid and trusted SSL certificate (HTTPS).

Your app or add-in may not open pop-up windows unless they are triggered by explicit user action. Pop-up windows must not be blocked by the browser's pop-up blocker when the blocker is set to the default value.

Your app or add-in may not request unreasonably high permissions or full-control permission.

Your app or add-in must have a correctly sized and formatted icon specified in the package or manifest.

Add-ins that depend on external accounts or services must provide a clear and simple sign in/sign out and sign-up experience.

Apps or add-ins that target larger organizations or enterprises:

Do not require a sign-in experience for external accounts or services if sign-ups are managed by the enterprise outside of the app or add-in and not by the individual user.
Do not require a seamless first run experience and value proposition but must include an email contact or link in the UI so users can learn more about your services.
Please refer to this blog post to learn more.

1100.6 Global audience

You must provide details on the offer submission form if your app or add-in calls, supports, contains, or uses cryptography.

1100.7 Easy identification

You must specify language support for your app or add-in within the package manifest. The primary language selected when you submit your offer must be one of the specified supported languages. The app or add-in experience must be reasonably similar in each supported language.

The title may not include your brand or service unless your offer targets a larger organization or enterprise.

Microsoft Teams apps may not include the brand or service in the title.

Your app or add-in must not be a duplicate of an app or add-in you have already submitted.

1100.8 Preserving functionality

If you update your app or add-in's pricing or licensing terms, you must continue to offer the original functionality to the existing user base at the original pricing. New pricing and/or licensing terms may only apply to new users.

If you update your pricing from free to paid, existing users must receive the same level of functionality as before the update.
If you update site license pricing from free to paid or not supported, existing users must continue to be supported for free.
Apps or add-ins may convert from free to subscription pricing as long as existing users receive the same level of functionality as before the update. Converting from paid to subscription pricing is not currently supported.

1120 Office Add-ins: Word, Excel, PowerPoint, and Outlook

The policies listed in this section apply only to Office Add-in offers.

1120.1 Offer requirements

All Office Add-ins must use the latest version of the Microsoft-hosted Office.js file at https://appsforoffice.microsoft.com/lib/1/hosted/office.js.

All Office Add-ins must use the latest manifest schema.

Specify a valid Support URL in the SupportURL element of your add-in manifest.

A high-resolution icon is mandatory.

Source location must point to a valid web address.

The version number in the app package updates must be incremented.

1120.2 Mobile requirements

Office Add-ins also available on iOS or Android:

Must not include any in-app purchases, trial offers, UI that aims to up-sell to paid versions, or links to any online stores where users can purchase or acquire other content, apps, or add-ins.
- The iOS or Android version of the add-in must not show any UI or language or link to any other apps, add-ins, or website that ask the user to pay. If the add-in requires an account, accounts may only be created if there is no charge; the use of the term "free" or "free account" is not allowed. You may determine whether the account is active indefinitely or for a limited time, but if the account expires, no UI, text, or links indicating the need to pay may be shown.
The associated Privacy Policy and Terms of Use pages must also be free of any commerce UI or Store links.
Must comply with the Outlook add-in design guidelines.

For Office Add-ins also available on iOS:

You must accept Apple's Terms and Conditions by selecting the appropriate checkbox on the Partner Center app submission form.
Your add-in must be compliant with all relevant Apple App Store policies.
You must provide a valid Apple ID.

Outlook add-ins with mobile support receive additional design review during validation, which adds to the required validation time. Outlook add-in design guidelines (link above) describes how your offer will be evaluated during the design review.

1120.3 Functionality

Add-ins must follow design guidelines without impeding the customer experience within the host application.

Your app or add-in must be fully functional with the supported operating systems, browsers, and devices for Office 2016, SharePoint 2013, and Office 365.

Your add-in will be tested and evaluated on Windows 10 (build 1903+ on Edge Legacy and earlier builds prior to 1903 with Internet Explorer 11).
All features must work on a touch-only device without a physical keyboard or mouse.
Your app or add-in must not utilize deprecated functionality.
Your add-in may not alter or promote the alteration of Office or SharePoint except via the Office and SharePoint add-ins model.

Add-ins must be compatible with the latest versions of Microsoft Edge, Google Chrome, Mozilla Firefox, and Apple Safari (macOS). Internet Explorer (IE) in Windows is still used in many Office configurations as noted in Browsers used by Office Add-ins. We recommend supporting IE, but if your add-in does not, you should advise users to install the latest Office version. For details, see Determine at runtime if the add-in is running in Internet Explorer.

Add-ins must work in all Office applications specified in the Hosts element in the add-in manifest.

Add-ins must work across all platforms that support methods defined in the Requirements element in the add-in manifest, with the following platform-specific requirements.

Add-ins must support Office on web and Mac applications compatible with the APIs listed in the Requirements element.
Add-ins that support iOS must be fully functional on the latest iPad device using the latest version of iOS.
Add-ins that use the task pane manifest must support add-in commands.
Content add-ins for PowerPoint may not activate their content (such as play audio or video) until after the JavaScript API for Office Office.initialize event has been called. This ensures that content display will correctly synchronize with presentations.

To help ensure an efficient validation process, if your add-in supports Single Sign-On, you must provide certification test notes explaining how your add-in uses SSO and what functionality in the add-in uses it. This information is required to ensure the validation team can test the fallback implementation. Offers that support Single Sign-On (SSO) must follow the SSO guidelines and include a fallback authentication method.

1120.4 Outlook add-ins functionality

The policies listed in this section apply only to Outlook add-in offers.

All Outlook add-ins must support Outlook on the web (Modern).
Outlook on the web (Classic) is preferred but optional for requirement sets of 1.5 or lower.
Outlook add-ins must not include the CustomPane extension point in the VersionOverrides node.
Outlook add-ins that support mobile must allow users to log on separately for each email account added to the Outlook app.
Add-in commands must be supported if your add-in is shown on every message or appointment, whether in read or compose mode.
If your add-in manifest includes the SupportPinning element for read mode of a message and/or appointment, the pinned content of the add-in must not be static and must clearly display data related to the message and/or appointment that is open or selected in the mailbox.
Outlook add-ins must not include the ItemSend event in the Events extension point.
If your add-in can use the AppendOnSend feature, you must include a disclosure in your offer description noting in what conditions the option is used and what information is being inserted (for example, "If configured to do so, this add-in appends legal disclaimers to email sent by the user").
If your add-in uses the Event-based Activation feature, you must include a disclosure in your offer description noting what information is being inserted in what events or conditions (for example, "Defined Signature will be inserted in Mail subject on composing new e-mail"). To help ensure an efficient validation process, when submitting your offer you must provide certification test notes explaining how to configure and test scenarios for auto launch events in your add-in.
Add-ins must not include the "Block" SendMode when using LaunchEvents "OnMessageSend" and/or "onAppointmentSend".

1120.5 Excel custom functions

The policies listed in this section apply only to Excel offers.

1120.5.1 Offer information and support contacts

Your custom functions metadata must have the helpUrl property set.

1120.5.2 Security

To help to ensure the security of your app and users, your custom functions HTML, JavaScript, and JSON metadata files must be hosted on the same domain.

1120.5.3 Functionality

Add-ins that contain custom functions must support add-in commands. This is to ensure that users can easily discover your add-in.

Your add-in must work across all platforms that support custom functions.

After an add-in is approved using the EquivalentAddins tag in the manifest, all future updates to the add-in must include this tag. This tag ensures that your custom functions save in XLL-compatible mode.

1120.5.4 Validation

To help ensure an efficient validation process, if your add-in contains custom functions, you must provide certification test notes for at least one custom function to validate them on submission.

1140 Teams and Microsoft 365 Copilot agents

The policies listed in this section apply only to Teams offers.

Refer to the Teams store validation guidelines to get a better understanding of these policies and to increase the likelihood of your app passing the Microsoft Teams store validation process.

1140.1 Value proposition and offer requirements

1140.1.1 App Name

Teams app names must not copy or mimic the title of an existing Teams app or other offer in the commercial marketplace.

Common nouns must be prefixed or suffixed with the publisher’s name (for example, "XYZ Tasks" rather than "Tasks").

1140.1.2 Workplace appropriateness

All content should be suitable for general workplace consumption. Apps must be collaborative and designed for multiple participants. Apps catering to team bonding and socializing needs of Microsoft Teams users may be published. Such apps should not require intense time investment or perceptively impact productivity.

1140.1.3 Other platforms and services

Teams apps must focus on the Teams experience and must not include names, icons, or imagery of other similar chat-based collaborative platforms or services unless the apps provide specific interoperability.

1140.1.4 Access to services

If your app requires an account or service, you must provide a clear way for the user to sign in, sign out, and sign up across all capabilities in your app. Teams apps that depend on authentication to an external service to allow content sharing in channels, must clearly state in their help documentation or similar location how a user can disconnect or unshare any shared content if the same feature is supported on the external service. The ability to unshare the content does not have to be present in the Teams app, but the process should be clearly documented, and the documentation should be accessible from within the app.

1140.3 Security

1140.3.1 Financial transactions

Financial transaction details must not be transmitted to users through a bot interface. Apps may only receive payment information through a user interface linked to a secure purchase API. Apps may only link to secure payment services if the link is disclosed in the App's terms of use, privacy policy, app description, and any profile page or associated website before the user agrees to use the app.

No payment shall be made through an app for goods or services prohibited by General policy 100.10 Inappropriate content.

1140.3.2 Bots and messaging extensions

Bots and Messaging Extensions must follow privacy notice requirements as communicated in the Developer Code of Conduct for the Microsoft Bot Framework and must operate in accordance with the requirements set forth in the Microsoft Bot Framework Online Services Agreement and Developer Code of Conduct for the Microsoft Bot Framework.

Message extensions that use OpenAPI specs must follow below security standards: All API calls must use HTTPS with TLS 1.2 or higher. API calls must not lead to any URL redirection. Actual API calls must be served from the same domain or subdomain as the root domain verified for the developer.

1140.3.3 External domains

Domains outside of your organization's control (including wildcards) and tunneling services cannot be included in the valid domains or OpenApi urls of your manifest, except in the following conditions:

If you are using OAuthCard, Token.botframework.com must be in the valid domains list.
Teams apps that require their own SharePoint URLs to function may include {teamsitedomain} in their valid domain list.
Teams apps built on the Microsoft Power Platform may include apps.powerapps.com in their valid domain list, to enable app to be accessible within Teams.

1140.4 Functionality

1140.4.1 General

App packages must be correctly formatted and conform to the latest release of the manifest schema.

Apps may not launch functionality outside of the Microsoft Teams app experience without the explicit permission of the user.

Graph API permissions requested by apps should align with business scenarios.

Compatibility: Teams apps must be fully functional on the latest versions of the following operating systems and browsers:

Microsoft Windows
- macOS
- Microsoft Edge
- Google Chrome
- iOS
- Android
For other unsupported operating systems and browsers, apps must provide a graceful failure message.

Response time: Teams apps must respond within a reasonable time frame.
Tabs must load within two seconds or display a loading message or warning.
- Bots must respond to user commands within two seconds or display a typing indicator.
- Messaging extensions must respond to user commands within two seconds.
- Notifications based on user actions must be displayed within two seconds.

App listing must contain a minimum of 3 screenshots depicting the app functionality in app store.

Screenshots must include caption to let the user clearly understand the app capability & always show relevant experience. Apps with copilot extension functionality, must have at least one screenshot related to copilot functionality

Videos provided in the app listing must not be more than 90 seconds in duration and must only show how the app works in Teams. You must turn off ads in YouTube/Vimeo settings before submitting the video link in Partner Center.

You must provide test accounts and / or fully configured test environments that are valid in perpetuity (till app is live on the Teams store) for continuous health evaluation of your app.

Apps from the same developer offering the same functionality must share an app listing unless;

privacy compliance requirements mandate separate app listings or
- required to support government cloud.
1. Apps with Artificial intelligence(AI)-generated content must meet below requirements:
App must not generate, contain, or provide access to inappropriate, harmful, or offensive Artificial intelligence(AI)-generated content consistent with existing commercial marketplace policies outlined in 100.10.
App must provide mechanism for app users to report inappropriate, harmful, or offensive content to the developer.
Developer must take timely action on reported concerns.
App must clearly describe Artificial intelligence (AI) functionality before the customer acquires the offer consistent with policy 100.1.3 & prompt user to review the info as a part of in-app functionality.

2. Apps using facial recognition capabilities are subject to the following policies:

App must not allow use of facial recognition capabilities to identify an individual to be used by or for a police department in the United States.
Developers of apps utilizing facial recognition or emotional inference technologies must provide a prominent tag or indication of each of these capabilities in the app description.
- This policy pertains only to apps that use facial expressions or facial movements to infer emotional states, such as anger, disgust, happiness, sadness, surprise, fear, or other terms commonly used to describe the emotional state of a person. It does not pertain to apps that use facial expressions and movements to detect and classify only individual facial elements, such as smiles or raised eyebrows. The key distinction is between the detection of facial expressions or movements as visual signals versus the inference of an emotional state.

1140.4.2 Tabs

Teams apps must follow Teams tab design guidelines without impeding the customer experience within the host application.

Tab experiences must provide value beyond hosting an existing website.
Tabs should not have excessive chrome or layered navigation.
Tabs must not provide navigation that conflicts with the primary Teams navigation.
Tabs should not allow users to navigate outside of Teams for the core experience.
Channel/ Chat/ meeting tabs are collaborative spaces. Content in these tabs must be contextually the same for all members of the channel and must not be scoped for individual use.
If tab configuration is required it must clearly explain the value of the experience and how to configure.

1140.4.3 Bots

Teams apps must follow Teams bot design guidelines without impeding the customer experience within the host application.

Bot information in the app manifest must be consistent with the bot's Bot Framework metadata (bot name, logo, privacy link, and terms of service link).
Bots must be responsive and fail gracefully.
Bots must not spam users by sending multiple messages in short succession. Avoid multi turn conversations in a bot response.
Bot should provide a welcome message or list of commands adhering to bot design guidelines for good first run user experience.
Bots in collaborative scope must provide user interaction value in the same scope.
Bot commands must not include special characters such as “/”
Prompt starters/ Commands must be functional and return responses.
Command description must be coherent & clearly communicate value of the command
Prompt starters/commands must be relevant to the app functionality
Prompt starters/ Commands must be generic in nature and not include custom references. For example, project names or task name.
Bot must have at least three unique Prompt starters/ commands (Recommended)
Bot must provide atleast one command that let’s user know about the value proposition of the app.

1140.4.4 Messaging extensions

Teams apps must follow Teams messaging extension design guidelines without impeding the customer experience within the host application.

Action Commands:

For action commands triggered from a chat message or channel post, calls to action in apps must incorporate the host app name instead of only using a generic verb (for example, "Start a Contoso Meeting" rather than "Start Meeting", "Upload file to Contoso" rather than "Upload file", and so on).
Action commands triggered from a chat message or channel post should leverage the context of the conversation and must not ask users to re-enter this information.

Search commands:

Search commands in messaging extensions should enable users to see real-time search results as they type text.
Search commands in messaging extensions must provide text that helps users search effectively.

Preview links (link unfurling):

Do not add domains that are outside your control (either absolute URLs or wildcards). For example, yourapp.onmicrosoft.com is valid but *.onmicrosoft.com is not valid. Top-level domains are also prohibited (for example, *.com or *.org).

1140.4.5 Task modules

Teams apps must follow Teams task module design guidelines without impeding the customer experience within the host application.

Task modules should not embed an entire app. Task modules should only display the components required to complete a specific action.

1140.4.6 Meeting extensions

Teams apps must follow Teams meeting extension design guidelines without impeding the customer experience within the host application. Teams meeting apps must provide a responsive in-meeting experience aligned with the Teams meeting experience. If an app offers a pre-meeting or post-meeting experience, these must be relevant to the meeting workflow. In-meeting experience must not take users outside the Teams meeting for core experiences. Apps must provide value beyond only offering custom Together Mode scenes in Teams meetings.

1140.4.7 Notification APIs

Notifications must provide value to the user.

Apps must not spam users by sending multiple notifications in quick succession.

Users must not be redirected outside of Teams when clicking a notification.

1140.4.8 Mobile experience

Teams apps should offer an appropriate cross device mobile experience.

App experiences on iOS and Android:

Must not include any in-app purchases, trial offers, UI that aims to up-sell to paid versions, or links to any online stores where users can purchase or acquire other content, apps, or add-ins.
Must not show any UI or language or link to any other apps, add-ins, or websites that ask the user to pay. If the add-in requires an account, accounts may only be created if there is no charge; the use of the term "free" or "free account" is not allowed. You may determine whether the account is active indefinitely or for a limited time, but if the account expires, no UI, text, or links indicating the need to pay may be shown.
The associated Privacy Policy and Terms of Use pages must also be free of any commerce UI or Store links.

You must provide a valid Apple App Store Connect Team ID in your Partner Center account to enable users to acquire and install your app from the Teams App Store on Teams mobile clients.

1140.5 Teams app linked to Software as a Service (SaaS) offers

The following additional requirements apply for Teams apps linked to a Software as a Service (SaaS) offer.

1140.5.1 Manifest and metadata requirements

The manifest for the Teams app must completely and accurately define the SubscriptionOffer details and OfferID of the linked SaaS offer.
The SaaS offer linked to the Teams app must meet all requirements defined in 1000 Software as a Service (SaaS).
The SaaS offer linked to the Teams app must be live in AppSource and must have at least one plan with pricing.
Available pricing plans for the SaaS offer must use a per-user pricing model.
Offer metadata should match across the Teams manifest, the Teams app listing in AppSource, and the SaaS offer in AppSource.
Plan descriptions and pricing details must provide enough information for users to clearly understand the offer listings.
Any limitations or specialized purchase flows must be clearly called out in the app metadata and pricing plan details.

1140.5.2 Purchasing and managing subscriptions

Users must be able to complete the end-to-end purchase flows with adequate information at each step.

Users completing a purchase must be able to activate and configure the subscription in the SaaS application.
Users completing a purchase must be able to manage licenses, including assigning and removing licenses, reassigning licenses among users, and authorizing users to manage licenses.
Any modifications in purchased licenses or plans must be reflected in the SaaS application with correct license counts, subscription details, and user assignments.

Admin users must be able to complete end-to-end bulk purchase flows from the Microsoft Teams Admin Center.

After successful purchase and assignment of licenses, your offer must provide enough value to justify the purchase and users must have access to the subscribed plan features in Teams.

1140.5.3 Testability and technical requirements

For testing purposes, your Teams app submission to Partner Center must include an end-to-end (E2E) functional document, linked SaaS offer configuration steps, and instructions for license and user management as part of the Notes for Certification.

The offer must meet all the technical requirements for Teams apps linked to a SaaS offer.

1140.6 Publisher Attestation

Teams apps must complete Publisher Attestation in Partner Center.

1140.7 Advertising

Teams apps may not include advertising.

1140.8 Teams apps extensible across Microsoft 365

1140.8.1 General

App packages must be correctly formatted and conform to manifest schema 1.13 or later

Teams apps extensible across Microsoft 365 must be fully responsive and fully functional on the latest versions of these clients:

Outlook on Desktop, Web and iOS
Microsoft 365 on Desktop, Web, Android and iOS
Microsoft Teams on Desktop and Web
Microsoft Teams on Android and iOS

Screenshots in the app listing must depict app functionality in all the supported clients.

The app’s listing description must be relevant to all the supported clients (Microsoft Teams, Microsoft Outlook and Microsoft Office)

The app’s support URL content must be relevant to all the supported clients (Microsoft Teams, Microsoft Outlook and Microsoft Office)

The app’s Get Started/Sign-in/Sign-out/Sign-up/Help/Permissions and all other way forward screens must contain content that is relevant to all the supported clients (Microsoft Teams, Microsoft Outlook and Microsoft Office)

For actions in Microsoft 365, display name must incorporate the intend AND app name (for example, "Open in Contoso" rather than "Contoso" or "Open")

Actions triggered on the content file should leverage the existing content file and must not ask users to re-upload the file.

1140.9 Copilot agents for Microsoft 365 Copilot

Copilot agents include Plugins, Graph connectors, Declarative agents & Custom engine agents
App packages must be correctly formatted and conform to manifest schema 1.13 or later
App must be consistent with responsible AI checks
App adheres to the compatible criteria here
Copilot agents must be fully responsive and functional on the latest versions of these clients: Teams, Microsoft 365 app, Outlook, Word and PowerPoint.

1160 SharePoint add-in

Important

As of March 1, 2024 net new SharePoint Add-Ins are not accepted anymore for submission. Read the full SharePoint Add-In retirement article to learn more.

The policies listed in this section apply only to SharePoint add-in offers.

1160.1 Security

Add-ins must not have any unauthenticated pages or APIs, except for the error page.

An unauthenticated error page should not link to other pages or other protected resources of the add-in.

If the solution requires full trust (formerly known as high trust) permissions, you will need to follow the guidelines from this Developer Blog post.

1160.2 Functionality

SharePoint add-ins must be fully functional with Windows 7, Windows 10, all versions of Internet Explorer 11 and later, and the latest versions of Microsoft Edge, Google Chrome, and Mozilla Firefox.

Add-ins designed for the modern SharePoint experience are not required to support the classic SharePoint experience. If your add-in supports only the classic experience, you must include that limitation in your add-in description.

Add-ins must not have remote debugging settings enabled. The manifest for your add-in must not include the DebugInfo element.

1170 SharePoint Framework Solutions

Important

Solutions cannot use domain isolation, the 'isDomainIsolated' property in the config/package-solution.json file must be set to 'false'. Read the Retiring SharePoint Framework domain isolated web parts for SharePoint Online article to learn more.

The policies listed in this section apply only to SharePoint Framework Solutions offers.

1170.1 Value proposition and offer requirements

SharePoint Framework (SPFx) solutions must clearly declare in the description the type of SPFx components that are included in the package.

1170.2 Security

SharePoint Framework solutions can request any permissions with the solution manifest. High permissions requests will need to be justified and clarified as part of the solution submission process.

Needed permissions must be automatically configurable with the manifest file.

1170.3 Functionality

SharePoint Framework (SPFx) solutions must be correctly formatted and conform to the latest SPFx versions.

Solutions must be fully functional with Windows 10 and the latest versions of Microsoft Edge, Google Chrome, and Mozilla Firefox. Solutions are only required to be tested in the non-root site of a modern SharePoint site. Test SPFx solutions on /appsmod only.

Response times must be reasonable. Responses that take more than three seconds must display a loading message or warning.

1170.4 Branding and advertising

SharePoint Framework solutions may not include advertising.

1170.5 Validation

SharePoint Framework (SPFx) solutions must be submitted with full configuration instructions in the Notes for Certification.

Offers should include the E2E functional document. Alternatively, SPFx solution functionality demonstration video links can be included in the Notes for Certification.

1180 Power BI visuals

The policies listed in this section apply only to Power BI offers.

1180.1 Acquisition, pricing, and terms

Power BI visuals must be free but can offer additional purchases.

If your Power BI visual offers additional purchases, it must comply with the In-App Purchase (IAP) guidelines.

1180.2 Functionality

Your visual must support Power BI Desktop, Power BI Online, Power BI mobile apps, and Power BI Windows universal apps. It must be compatible with supported operating systems, browsers, and devices for Power BI, including touch-only devices without a physical keyboard or mouse.

All visuals must support the context menu (right click menu). You can learn more about the context menu here.

Your visual must support the core functions of Power BI for that visual type, including but not limited to pinning to dashboard, filtering focus mode, and formatting various data types.

Data type support will be evaluated based on the following tests:

String values
Empty values
Negative values
Lots of rows (at least 20,000 rows)
Large numbers of 16 digits

Your visual must not launch functionality outside of the visual experience without the explicit permission of the user.

Your visual and its description must not prompt the user to install any additional files.

Your visual must not prompt a user to disclose the credentials of a Microsoft identity (for example, Microsoft 365 (formerly called Office 365) or Microsoft Azure Organizational Account, Microsoft Account, or Windows Domain Account) except through Microsoft approved OAuth flow, where your visual is authorized to act on behalf of the user.

Your visual may not open pop-up windows unless they are triggered by explicit user action. Pop-up windows must not be blocked by the browser's pop-up blocker when the blocker is set to the default value.

Your visual may not request unreasonably high permissions or full-control permission.

Visuals that depend on external accounts or services must provide a clear and simple sign in/sign out and sign-up experience.

Power BI visuals must be accompanied by a sample file in .pbix format. The version and content of the .pbiviz file should match the corresponding visual contained in the .pbix sample file. For the best user experience, consider adding Hits and Tips for using the visual to the sample file.

1200 Power BI visuals additional certification

The policies listed in this section apply only to Power BI visuals offers.

1200.1 Certification requirements

1200.1.1 Code repository

Your visual source code must conform to the visual code repository requirements.

The code repository for your visual should be available and correctly formatted.

1200.1.2 Code quality

Your source code should be readable, maintainable, expose no functionality errors, and correspond to the provided visual's package.

1200.1.3 Code security

Your source code should comply with all security and privacy policies. Source code must be safe and not pass or transmit customer data externally.

1200.1.4 Code functionality

Running visual development related commands on top of your visual source code should not return any errors.

Visual consumption should not expose any errors or failures and must ensure the functionality of any previous version is preserved.

1200.1.5 Update without advanced certification

Power BI Visual additional certification does not apply automatically to updated visuals. All updates to certified Power BI Visuals must also be certified as part of the submission process.

1200.2 Duplicate offers

Visuals that rely on access to external services or resources are not eligible to be certified Power BI visuals.

You may submit duplicate versions of visuals to the Marketplace: a non-certified version that uses external services or resources, and a certified version that does not use external services or resources. The offer that accesses external services or resources must clearly state so in the description.

1240 Power BI Template Apps

To ensure customers have an accurate understanding of your offer, please follow these additional listing requirements for Power BI App offers.

1240.1 Value Proposition and Offer Requirements

Offer titles must not include "(Preview)".

Descriptions and summaries should not use the deprecated term "content packs". New app offers may use the term "template apps".

1240.2 Technical Validation

Publisher ownership of the offer must be verifiable.

Offer updates should use the same Power BI tenant and workspace as previous offer versions.

Power BI apps may not be published more than once via different offers.

Offers should successfully install within two minutes and load within thirty seconds.

All UI aspects should be publication ready. This includes:

Overall look and feel
Reports and dashboards
Titles
Visuals and text
Logos and graphics
Content (static and generated)

Organization-specific Power BI visuals may not be used.

Sample data is not supported for new (not yet published) offers. Offers must be able to connect with customer data.

When "Connect Data" is available, test accounts, parameters, and/or additional instructions must be included in the offer's validation instructions, and custom parameters should not produce any errors.

1400 Dynamics 365 Business Central

The policies listed in this section apply only to Dynamics 365 Business Central offers.

1400.3 Acquisition, pricing, and terms

Add-on apps may be either "Free", "Free or Trial", or "Contact me". Connect and Localization apps must be listed as "Contact Me".

See Industries, categories, app type.

Supported countries must be selected on submission.

See Supported countries, languages, app Version, and app release date.

1400.5 Technical requirements

Offers must meet all of the requirements in the technical validation checklist.

1400.6 Business Central version functionality

Your add-on apps must function and your data must upgrade to the current version of Business Central Online. Add-on updates require recertification which must be submitted with sufficient lead time prior to a Business Central Online update release.

1420 Dynamics 365 apps on Dataverse and Power Apps

The policies listed in this section apply only to Dynamics 365 apps on Dataverse and Power Apps offers.

1420.1 Value proposition and offer requirements

Any feature changes between updates must be reflected in the marketing materials submitted to the Marketplace.

1420.2 Acquisition, pricing, and terms

Offers must be listed as either Free, Trial, Contact Me, or ISV app license management.

1420.3 Content requirements

The Offer Description field must be in plain text or simple HTML format and must include the full product name.

1420.4 Functionality

Any feature changes between updates must be re-certified when the offer is re-submitted. The entire solution package must be submitted with each update to ensure dependency issues are covered. The version number must be incremented with each update.

1420.5 Technical requirements

Offers must support:

Dynamics 365 v9.1 or above
Unified Client Interface (UCI) (Model Driven Apps only)

Offers must only use publicly available APIs.

Submitted packages must contain all required artifacts for publication on the Marketplace.

The end-to-end (E2E) functional document must be updated with functional scenarios and the user/admin journey.

Commercial marketplace offers must be recertified within six months of their last successful publish.

1420.6 Code validation

Canvas apps and Common Data Services solutions will have their code validated to check for the following:

Static formula errors and warnings.
Runtime errors (may occur once the app is opened in Run mode to view).
Accessibility errors.

See App certification checklist.

1420.7 Deployment validation

Offers will be installed to a PowerApps Environment using Package Deployer to ensure that:

Canvas apps successfully connect through provided connectors.
All Common Data Service components (entities, web resources, plug-ins, and other components) are available.
All associated components are properly removed upon uninstall.

See App certification checklist.

1420.8 Functionality validation

Offers should include the E2E functional document. Video links may be emailed as an alternative.

1420.9 Security validation

Apps will be checked for:

Connections to external data sources or connections that require access. Proper connection details should be included in the E2E functional document.
External connections out of PowerApps connectors.

Custom code provided inside Package Deployer will be validated before offer approval and checked for retrieval of customer data from the target environment.

1420.10 Sitemap validation

Published app customizations must not change or remove any out of box (OOB) site map.

1440 Dynamics 365 Operations Apps

The policies listed in this section apply only to Dynamics 365 Operations Apps offers.

See Requirements for publishing apps on AppSource.

1440.1 Content requirements

The following requirements must be met in the offer listing:

The Offer Description field must be in HTML format and must include the full product name.
The Contact Email and Phone Number fields must have valid, working values.
The Storefront Details > App Choice field must be set to "Contact me".
The CAR file must be uploaded using the Technical Info > Validation asset(s) field.

1440.2 Technical requirements

Offers must support the most current version of Dynamics 365.

Commercial marketplace offers must be recertified within six months of their last successful publish.

1440.3 Code validation

Offers must be validated to verify that custom code meets Microsoft guidelines.

Before submission, publishers must:

Successfully create a CAR without any localization, accessibility, performance, or security issues.
Publish a solution package with all the required artifacts to LCS and create a solution identifier (GUID) for the solution.

1440.4 Deployment validation

Offers must be validated to verify that a solution package can be successfully bundled and delivered in a Microsoft Dynamics 365 for Finance and Operations environment.

Before submission, publishers must:

Reference best practice information in the Migrate and Create methodology section of LCS.
Successfully deploy at least one Finance and Operations environment without any errors.
- The environment configuration must be the same as the partner's reference environment.
- Partner-supplied master and reference data must be able to be successfully pushed into the Finance and Operations environment without any errors.

1440.5 Functionality validation

During the functionality demonstration:

A user must be able to sign in to the environment without any errors.
Business transactions must be able to be completed as defined in the package scope without any errors.

3000 Requirements for Co-sell Status Tiers

The policies listed in this section apply only to offers pursuing Co-sell status. Requirements are tiered: all 3000.1 Co-sell ready status requirements must be satisfied in order to be eligible for 3000.2 Azure IP co-sell eligible status.

3000.1 Co-sell ready status

Your offer must be listed on the commercial marketplace.

Your offer must include a complete set of collateral documents (bill of materials), including a solution/offer pitch deck and a solution/offer one-pager.

You must have a business profile in Partner Center.

Your offer must have a dedicated sales contact for each region (country or geographical area) in which you would like to be eligible to co-sell.

Services partners must be enrolled in the Microsoft Cloud Partner Program and completed a Solutions Partner Designation.

3000.2 Azure IP co-sell status

Offers must be built on or built for Azure.

Azure Applications, Azure Containers, IoT Edge Modules, SaaS, and VMs must meet the following requirements:

Your organization must meet or exceed $100,000 USD of Azure consumed revenue over a trailing 12-month period, or your offer must have a cumulative marketplace billed revenue of $100,000 USD.
For SaaS offers: your product must be primarily platformed on Microsoft Azure.
For non-SaaS offers: must be deployed in Azure.
Your offer must be transactable and listed as a "Sell through Microsoft” on the Azure Marketplace.

3000.3 Azure IP Co-Sell Program Deal Registration

Referral eligibility for IP Co-sell for Azure requires having an IP co-sell eligible offer that meets the following requirements and registering the deal through Partner Center.

3000.3.1 Segmentation

Deals must be signed with an Enterprise or SMC-Corporate customer.

3000.3.2 Opportunity Age

The opportunity must be created by the partner (through Partner Center) or by Microsoft (through MSX) and, except for partner-led deals, shared before the contract sign date or marketplace transaction date.

3000.3.3 Solution Tagging

The Azure IP Co-sell incentive tag must be added.

3000.3.4 Timeline

Completed deals must be registered within 60 days after signing.

3000.3.5 Contract Parameters

The input contract value must be based on the entirety of the contract, not the annualized value. The registered value of the offer should match the total contract value and currency agreed upon by you and your customer.

The deal must be at least $25,000 USD in annual revenue, including your products, licenses, and IP solution related services, and should exclude any trial component, EA, and hardware components.

Start and end dates are required for the contract duration. If the contract term is 6 or more years or there is no defined term or end date, the perpetual partner license should be selected.

3000.4 Azure benefit eligibility for customer (Microsoft Azure Consumption Commitment)

Marketplace purchases that contribute towards a customer's Microsoft Azure consumption commitment (MACC) are limited to Azure benefit-eligible offers and can only be used to purchase solutions that are primarily platformed on or extend Microsoft Cloud products or infrastructure. To participate in this benefit, your offer(s) need to reach Azure IP co-sell status.

4000 Microsoft 365 Application Compliance

M365 Certification requirements can be found on the M365 App Compliance page. Most requirements must be met for successful certification. If you are interested in applying for M365 Certification, please contact appcert@microsoft.com. If any significant changes happen after you receive certification, the team must be notified of the changes.

Once certified, information on M365 Certification for your application is available at https://aka.ms/appcertification.

5000 Connectors & Agents in Microsoft Copilot Studio

Connectors & Agents for Microsoft Copilot Studio submitted to Partner Center goes through certification lifecycle. It must meet the following criteria and requirements to be certified.

5000.1 Offer and Package Requirements

Solution Package should contain connector, AI enabled connector, connector based flow and copilot agent (as applicable).
If Your package contains Power platform connector or AI enabled connectors you should comply with the standards highlighted here.
If your package contains Connector based templates you should comply with the standards highlighted here.

5000.2 Technical and Functional Requirements

Operation and parameter summaries should be phrases of 80 characters or shorter & should contain only alphanumeric characters or parentheses.
Operation responses should be provided with an exact schema only with valid response schema definitions for all operations in the swagger.
Empty response schemas, operations and properties are prohibited except for special cases.
"openapidefinition" should be in a correctly formatted JSON file.
Swagger definition should comply with the OpenAPI 2.0 standard and the connectors’ extended standard.
Connection Parameters should comply to the standards outlined here.
Add metadata for your connector, plugin & its end service which will be publicly accessible to all users.
Open source your connector on GitHub by following the instructions here.
After we certify the connector Microsoft will ask you to perform thorough testing to validate your connector’s functionality & content.
Connector and the actions should be searchable while installing the custom connector.
OpenAPI definition should contain valid paths like definition of actions & triggers.

5000.3 Security Requirements

Valid client ID and client secret should be provided if the connector supports OAuth.
The redirect URL should be configured correctly before the connector is deployed to public.
Package URI submitted should be valid and the SAS token should not expire before 15 days.
Valid URL for your APIs website and privacy policy URL should be provided for customers to access or reach out to the partner in case of any concerns.
All API calls must use HTTPS with TLS 1.2 or higher.

5000.4 AI enabled connectors

All the AI enabled connectors will follow the Responsible AI guidelines highlighted here.
AI enabled connectors must not generate, contain, or provide access to inappropriate, harmful, or offensive Artificial intelligence(AI)-generated content consistent with existing commercial marketplace policies outlined in 100.10.

5000.5 Copilot Agents

Copilot Agent must clearly describe Artificial intelligence (AI) functionality before the customer acquires the offer consistent with policy 100.1.3 & prompt user to review the info as a part of in-app functionality.
Copilot Agent must not generate, contain, or provide access to inappropriate, harmful, or offensive Artificial intelligence(AI)-generated content consistent with existing commercial marketplace policies outlined in 100.10.
All the Copilot Agents will follow the Responsible AI guidelines highlighted here.

Next steps

Visit the commercial marketplace publishing guide.

Return to the commercial marketplace policies and terms.

次の方法で共有

Commercial marketplace certification policies

Table of contents

100 General

100.1 Value proposition and offer requirements

100.1.1 Title

100.1.2 Summary

100.1.3 Description

100.1.4 Non-English content

100.1.5 Active and visible presence

100.2 Discoverability

100.2.1 Categories and Industries

100.2.2 Keywords

100.2.3 Solutions Partner designations (only required for Professional Services offers that are intended for Microsoft first-party software)

100.2.4 Listing organization

100.3 Graphic elements

100.4 Acquisition, pricing, and terms

100.5 Offer information

100.6 Personal information

100.7 Accurate source

100.8 Significant value

100.10 Inappropriate content

100.11 Security

100.12 Functionality

100.13 Business requirements

100.14 Testability

100.15 Supporting documents

200 Virtual Machines

200.1 Technical Requirements

200.2 Business Requirements

200.3 VM Image Requirements

200.3.1 General

200.3.2 Windows

200.3.3 Linux

200.4 VM Image Generalization

200.5 Security

200.6 Testing and Certification

220 Network Virtual Appliances (NVAs)

220.1 NVA Internal Service Error

220.2 NVA VHD Access

220.3 NVA boot performance

220.6 NVA High Availability

220.7 NVA VNET Peering

220.8 NVA Accelerated Networking

220.9 NVA Multi-NIC basic

220.10 NVA Network Disruption

300 Azure Applications

300.1 Value proposition and offer requirements

300.2 Acquisition, pricing, and terms

300.3 Functionality

300.4 Technical requirements

300.4.1 Code

300.4.2 Security

300.4.3 Variables

300.4.4 Parameters

300.4.5 Resources

300.4.6 CUID (createUIDef)

300.4.7 Deployment artifacts

300.4.8 VM image references and disks

400 Azure container offers

400.1 Technical requirements

400.2 Business requirements

400.3 Security

600 IoT Edge Modules

600.1 Offer Information

600.2 Plan Information

600.3 Technical Requirements

700 Managed Services

700.1 Value proposition and offer requirements

700.3 Graphic elements

700.4 Business requirements

700.5 Plan details

700.6 Plan manifest details

810 Professional Services

810.1 Value proposition

810.2 Eligibility requirements

810.2.2 Primary Product: Dynamics 365 Apps on Dataverse and Power Apps (Sales, Marketing, Customer Service, Field Service, HR and Customer Voice)

810.2.3 Primary Product: Dynamics 365 Finance and Operations Applications (Finance, Supply Chain Management, Commerce, Project Operations)

810.2.4 Primary Product: Dynamics 365 Customer Insights

810.2.5 Primary Product: Dynamics 365 Business Central

300.4.6 CUID (`createUIDef`)