Commercial marketplace certification policies

Document version: 1.13

Document date: July 28, 2020

Note

For a summary of recent changes to these policies, see Change history.

Table of contents

100 General

200 Virtual Machines

220 Network Virtual Appliances

300 Azure Applications

600 IoT Edge Modules

700 Managed Services

800 Consulting Services

1000 Software as a Service (SaaS)

1100 Office 365

1120 Office add-ins

1140 Teams

1160 SharePoint

1170 SharePoint Framework Solutions

1180 Power BI visuals

1200 Power BI visuals additional certification

1220 Excel custom functions

1240 Power BI Service Apps

1400 Dynamics 365 Business Central

1420 Dynamics 365 CE

1440 Dynamics 365 Finance Ops

3000 Co-sell solutions

100 General

Your offer listing on the Marketplace must accurately and clearly reflect the source, functionality, and features of your offer. Your listing should let customers quickly and easily understand the value proposition, usage scenario, and benefits of your offer, including provisions for acquisition and support.

100.1 Value proposition and offer requirements

To let customers quickly identify offers of interest, your listing must clearly, concisely and accurately convey the type of offer, the value proposition for your offer, and requirements for its adoption. The listing elements related to this requirement apply to offers and any plans that are part of the offer. These include:

  • An accurate and descriptive title.
  • A concise, well written summary of the offer or plan and its intended use.
  • A description that identifies the audience for the offer or plan, briefly and clearly explains the unique and distinct value of the offer or plan, identifies supported Microsoft products and other supported software, and includes any prerequisites or requirements for its use.

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. In the descriptions, you may not directly compare your offer or its capabilities to other marketplace offers or their capabilities.

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.

Author the summary and description elements of your listing by using the Markdown markup language. For information about using Markdown, see the Docs Markdown reference. Attached documents must be in .pdf format.

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.

The commercial marketplace does not currently support the sale of hardware. Any offers for hardware must be transacted outside of Microsoft commercial marketplace.

100.2 Discoverability

To help customers identify appropriate publishers and offers, your listing must accurately identify your expertise and the areas your offer supports. Listing features that do this include:

  • Categories
  • Industries
  • Competencies
  • Keywords

You must provide accurate current information needed to validate your competencies and qualifications when you submit your offer.

Keywords must be relevant to the offer and any supported products.

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
  • Images, including screenshots
  • Videos

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.

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.

You may not redirect or up-sell customers to software or services outside of the Marketplace from the offer listing. This restriction does not apply to support services that publishers sell outside of the Marketplace.

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

100.5 Offer information and support contacts

Customers want to know how to find out more about your offer and how they'll get support for evaluating and using it. Links to information should include:

  • Terms and conditions (required)
  • Privacy policy (required)
  • Support and Help links with appropriate information (required)
  • Detailed and instructive documentation (required)
  • "Learn More" links to additional offer information (optional)
  • Transaction information (optional)

Links must be functional, accurate, and must not jeopardize or compromise user security. For example, a link must not spontaneously download a file. All links provided throughout the offer metadata, including the above listed options and in any other metadata fields, must be served using the secure HTTPS protocol.

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.

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

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 marketplace.

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.

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.

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
  • 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.

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 1 MB.

OS Architecture must be 64 bits.

Image must have been deprovisioned. For more information, 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: https://docs.microsoft.com/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.

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.

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 (i.e. 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.

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 a Virtual Machine (VM) to ensure it 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

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

220.1 Technical Requirements

Network Virtual Appliances (NVAs) must satisfy the following technical requirements:

  • Must support multiple Network Interface Card (NIC) configurations.
  • Must support a reboot operation in Azure.
  • Must support being redeployed from the Marketplace template from which they were originally published.
  • Must be able to withstand a network disruption.
  • Must support VNet Peering configurations.
  • For High Availability (HA) configurations, must support the HA Ports feature of the Internal Load Balancer.

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.

Container offers are not supported for Azure applications in the commercial marketplace.

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.

300.3 Functionality

VMs must be built on Windows or Linux.

Azure applications must be deployable through the commercial marketplace.

300.4 Technical requirements

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.

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.2 Offer information and support contacts

A CRM system must be connected with the Lead Destination configured in the Customer Leads section of the Offer Setup.

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 a Silver or Gold Cloud Platform competency level to publish a Managed Service offer.

You should review the managed services publication guidelines before submission.

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).

800 Consulting Services

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

800.1 Value proposition

Consulting 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.

800.2 Eligibility requirements

For offers where Azure is selected as the primary product, your offer must list at least one of the following fully earned competencies:

  • Application Development
  • Application Integration
  • Application Life-cycle Management
  • Cloud Platform
  • Data Analytics
  • Data Center
  • Data Platform
  • DevOps

For offers with one of the following options selected as the primary product, you must meet the eligibility requirements listed below or have a Co-sell offer for the primary product to which the service offering is related.

  • Customer Engagement Applications

    Applies to: Dynamics 365 Sales, Dynamics 365 Marketing, Dynamics 365 Customer Service, Dynamics 365 Field Service, Dynamics 365 Human Resources

    Criteria: Must be Gold or Silver certified in the Cloud Business Applications competency for Customer Engagement option.

  • Finance and Operations Applications

    Applies to: Dynamics 365 Finance, Dynamics 365 Operations, Dynamics 365 Commerce, Dynamics 365 Human Resources, Dynamics 365 Project Service Automation

    Criteria: Must be Gold or Silver certified in the Cloud Business Applications competency for Unified Operations option.

  • Dynamics 365 Customer Insights

    Criteria: Must have at least one successful in-production implementation of Dynamics 365 Customer Insights with at least five measures and five segments.

  • Dynamics 365 Business Central

    Criteria: Must be Gold or Silver certified in the Enterprise Resource Planning competency and serve at least three customers OR must have published a Business Central application in Microsoft AppSource.

  • Power BI

    Criteria: Must be listed on the Power BI partner showcase.

  • Power Apps

    Criteria: Must be eligible for Advanced Benefits in the PowerApps Partnership Program.

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

800.3 Title

Your Title must follow the format "Offer Name: Duration Service type." For example, "CompanyX - Database Security: 2-wk Implementation."

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

The offer type must match the type specified during submission.

800.4 Summary and description

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

  • Service deliverables and outcomes.
  • Daily or weekly agendas for workshops longer than one day.
  • Detailed itemization of briefing and workshop topics.
  • Country of offer
    • Offers may only be targeted to one country; to target multiple countries, please create one offer per country

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.

800.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.

800.6 Offer information and support contacts

A CRM system must be connected with the Lead Destination configured in the Customer Leads section of the Offer Setup.

1000 Software as a Service (SaaS)

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

1000.1 Value proposition and offer requirements

Your offer must meet at least one of the following criteria:

  • Run on Microsoft Azure: The primary function of the software or service must run on Microsoft Azure.
  • Be deployable on Microsoft Azure: Publishers must describe in their offer listing information on how the software or service is deployed on Microsoft Azure.
  • Integrate with or extend a Microsoft Azure service: Publishers must describe in their offer listing information which service the software or service integrates with or extends and how it does so.

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

Your offer must allow logging in to your application using Azure Active Directory (Azure AD) SSO. If you choose to sell through Microsoft, the buyer must be able to log in; if you process transactions independently and use the Get it now or Free trial options, the acquiring user must be able to log in.

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 Offer information and support contacts

A CRM system must be connected with the Lead Destination configured in the Customer Leads section of the Offer Setup.

1100 Office 365

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

1100.1 General content

Your app or add-in title may not include "app", "plug-in", or derivatives.

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.

1100.2 Displaying ads

Apps or add-ins can contain ads.

  • The primary purpose of the app or add-in must be more than displaying advertisements.
  • Ads must comply with our content policies and should match our ad design guidelines.
  • Ads should not interfere with app or add-in functionality.

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 or add-in should not consume an unreasonable amount of memory that negatively impacts the performance of an average user's environment.

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

  • 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.

Your app experience must not prompt a user to disclose the credentials of a Microsoft identity (for example, 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.

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.

Multiple variants of an app or add-in (for example, with different functionalities at different price points) must be submitted separately with separate product IDs. The binary may remain the same across multiple listings. We recommend that all listing descriptions include a notification of the multiple variants, so users are aware of different cost/functionality tiers.

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

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

1120.1 Easy identification

All Office add-ins must use the latest Microsoft-hosted Office.js file.

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

You must specify a valid Support URL in the SupportURL element of your add-in manifest.

1120.2 Acquisition, pricing, and terms

Office add-ins also available on iOS, Android, or for Teams:

  • Must not include any in-app purchases, trial offers, UI that aims to upsell 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 Seller Dashboard submission form.
  • Your add-in must be compliant with all relevant Apple App Store policies.
  • You must provide a valid Apple ID.

PowerPoint add-ins which use restricted permissions must clearly display links to their Privacy Policy and Terms of Use information on the first screen of the add-in. If your add-in does not collect or transmit user information, you must link to a statement stating this fact.

1120.3 Functionality

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

Add-ins must be compatible with all versions of Internet Explorer 11 and later, and the latest versions of Microsoft Edge, Google Chrome, Mozilla Firefox, and Apple Safari (macOS).

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 Online 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.
  • 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.
  • Add-ins that use the taskpane manifest must support add-in commands.

Content add-ins for PowerPoint may not activate their content (e.g., 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.

1140 Teams

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

1140.1 Value proposition and offer requirements

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

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. These apps must be collaborative and designed for multiple participants. All content should be suitable for general workplace consumption.

1140.3 Security

Bots may not transmit financial instrument details through the user to bot interface. Bots may only transmit links to secure payment services to users if this is disclosed in the app's Terms of Use, Privacy Policy, and any profile page or website for the app before a user agrees to use the bot.

Bots and Compose Extensions:

  • Must follow privacy notice requirements as communicated in the Developer Code of Conduct for the Microsoft Bot Framework.
  • 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.

Domains outside of your organization's control (including wildcards) and tunneling services cannot be included in the valid domains 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.

1140.4 Functionality

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

Bot manifest information must be consistent with the bot's Bot Framework metadata (bot name, logo, privacy link, and terms of service link).

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

Apps must be fully functional on the following operating systems and browsers:

  • Microsoft Windows 7 and later.
  • macOS 10.10 and later.
  • Microsoft Edge 12 and later.
  • Mozilla Firefox 47.0 and later.
  • Google Chrome 51.0 and later.
  • iOS 9.0 and later.
  • Android 4.4 and later.

Bot experiences must be fully functional on the following mobile systems:

  • iOS 9.0 and later.
  • Android 4.4 and later.

Response times must be reasonable.

  • For tabs: Responses that take more than three seconds must display a loading message or warning.
  • For bots: Responses to user commands that take more than two seconds must display a typing indicator.
  • For compose extensions: Responses to user commands must occur within five seconds.

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

  • Tab experiences must provide value beyond hosting an existing website.
  • Content in a channel tab must be contextually the same for all members of the channel and not scoped for individual use.
  • Content in a tab should not have excessive chrome or layered navigation.
  • Configurable tabs should not allow users to navigate outside the core experience within the same tab. Tab configuration must happen in the configuration screen, which must clearly explain the value of the experience and how to configure.
  • Bots must be responsive and fail gracefully.
  • Bots must send a welcome message on first launch that includes a help command that provides the value proposition and all valid commands.

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.5 Advertising

Teams apps may not include advertising.

1160 SharePoint

The policies listed in this section apply only to SharePoint 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.

Add-ins must prompt the administrator to explain that the add-in must install a full-control app.

  • The administrator must be able to install this full-control app without interacting with the add-in provider (for example, via email or web forms).
  • The full-control app must comply with all Marketplace policies.
  • If the full-control app meets all validation policies, the add-in can function only to install the full-control app.

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 must not have remote debugging settings enabled. The manifest for your add-in must not include the DebugInfo element.

1170 SharePoint Framework Solutions

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.

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 Windows 10 and the latest versions of Microsoft Edge, Google Chrome, Mozilla Firefox, and Apple Safari (macOS).

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.

Power BI visuals must be accompanied by a sample file in .pbix format included in the same location as the pbviz 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 Source code

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.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.

1200.3 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.

1220 Excel custom functions

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

1220.1 Offer information and support contacts

Your custom functions metadata must have the helpUrl property set.

1220.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.

1220.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.

1220.4 Validation

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

1240 Power BI Service 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.1 Value proposition and offer requirements

For more information on any of the following marketing requirements, please see the marketing validation checklist.

1400.1.1 Language

Offer listings and all linked information, including any landing pages, graphics, documentation, and support options may be presented in languages other than English. If the listing is presented in a language other than English, a .pdf document with the offer name, summary, description, and support contact details translated into English must be included.

For more information, see the language and branding guidelines.

1400.1.2 Branding

Microsoft branding must be consistent throughout your communications:

  • "Microsoft Dynamics 365 Business Central" for first mention and all prominent locations (title, headings, etc.)
  • "Dynamics 365 Business Central" on second mention.
  • "Business Central" on subsequent mentions.

Microsoft trademarked imagery (including the Microsoft, Dynamics, and Business Central logos) may not be used.

For more information, see the language and branding guidelines.

1400.1.3 Name

Two naming structures are allowed for offer names:

  • (Your offer name) for Microsoft Dynamics 365 Business Central.
    Example: Sales & Inventory Forecast for Microsoft Dynamics 365 Business Central.
  • (Your offer name)
    Example: Sales & Inventory Forecast.

For more information, see the offer name guidelines.

1400.1.4 Summary

Offer summaries must summarize the value proposition of your offer in one short and concise sentence.

For more information, see the offer summary guidelines.

1400.1.5 Description

Offer descriptions may be a maximum of 3,000 characters.

For more information, see the offer description guidelines.

Offer descriptions must clearly state which edition(s) (Essentials, Premium, or both), countries, and languages are supported by your offer. Please use the following template in your description:

    Supported Editions:
    This app supports the Essentials and Premium Editions of Dynamics 365 Business Central
    Supported Countries:
    Canada, Mexico, and United States
    Supported Languages:
    This app is available in English (United States) and Spanish (Mexico).

For more information, see the supported editions and supported countries guidelines.

1400.1.6 Keywords

If keywords are used, a maximum of three keywords may be provided.

For more information, see the supported products, keywords, and hide key guidelines.

1400.2 Graphic elements

For more information on any of the following marketing requirements, please see the marketing validation checklist.

1400.2.1 Logos

Any text included in the logos must be legible.

For more information, see the offer logo guidelines.

1400.2.2 Screenshots

Screenshots of Business Central must show the latest web client user interface.

For more information, see the screenshots guidelines.

1400.2.3 Videos

Videos including Business Central must show the latest web client interface.

For more information, see the videos guidelines.

1400.3 Acquisition, pricing, and terms

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

For more information, see the industries, categories, app type guidelines.

Supported countries must be selected on submission.

For more information, see the supported countries, languages, app Version, and app release date guidelines.

1400.4 Offer information and support contacts

The offer Help Link and Support Link should not be identical, unless a single page covers all Help Link and Support Link requirements below.

  • The Help Link should be a landing page on your website that provides help resources such as documentation, FAQs, step-by-step guides, webinars, etc.
  • The Support Link should be a distinct support page on your website, that includes contact options and documentation including defined service level agreements (SLAs). These should include at least two of the following options: email, phone number, live chat (if possible), and address.

For more information, see the help URL and support URL guidelines.

The offer's Privacy Policy and Terms of Service links have the following requirements:

  • The Privacy Policy must include DPO contact details for customer enquiries regarding data usage.
  • The Terms of Service may be hosted on AppSource. If hosted on AppSource, they must be formatted in HTML.

For more information, see the privacy policy and terms of use guidelines.

A CRM system must be connected with the Lead Destination configured in the Customer Leads section of the Offer Setup.

The App Version field must be numeric and formatted as x.x.x.x. The version number must increment with every update and match the app.json manifest.

For more information see the supported countries, languages, app version, and app release date guidelines.

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 CE

The policies listed in this section apply only to Dynamics 365 CE 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, or Contact Me.

1420.3 Content requirements

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

A CRM system must be connected with the Lead Destination configured in the Customer Leads section of the Offer Setup.

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.

For further information on these requirements, see the 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.

For further information on these requirements, see the 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 Finance Ops

The policies listed in this section apply only to Dynamics 365 Finance Ops offers.

For further information on these requirements, see the 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.
  • A CRM system must be connected with the Lead Destination configured in the Customer Leads section of the Offer Setup.
  • 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 Co-sell solutions

The policies listed in this section apply only to Co-Sell Solutions offers.

3000.1 Business requirements

Offers built on Dynamics 365 Customer Engagement, Finance and Ops, or PowerApps where the partner has signed up for the Business Applications ISV Connect program are eligible for IP Co-Sell acceleration, subject to the following requirements.

  1. Your offer must be listed on AppSource.
  2. Your offer must include a complete co-sell bill of materials, including:
    • A solution pitch deck,
    • A one-page leave-behind or website listing,
    • A case study or website listing.
  3. You must have a business profile in Partner Center.
  4. You must have a dedicated sales contact for each co-sell eligible region (country or geographical area).

Next steps

Visit the Azure Marketplace and AppSource Publisher Guide page.

Return to the commercial marketplace policies and terms page.