Commercial marketplace certification policies
Document version: 1.33
Document date: May 20, 2022
Table of contents
- Commercial marketplace certification policies
- Table of contents
- 100 General
- 100.1 Value proposition and offer requirements
- 100.2 Discoverability
- 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
- 200 Virtual Machines
- 300 Azure Applications
- 800 Consulting Services
- Next steps
100 General
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. All offers and your publisher activities on Partner Center are subject to the Microsoft Publisher Agreement.
100.1 Value proposition and offer requirements
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.
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.7 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) .
100.2 Discoverability
To help customers discover offers, categories, industries, keywords, and consulting service competencies 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 Competencies (consulting services offers only)
You must provide accurate current information needed to validate your competencies and qualifications when you submit your offer.
100.2.4 Lising 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 China Marketplace. - An optional 48-pixel square logo may be added later to replace the autogenerated small logo. This logo appears in Azure Marketplace search results.
- Logos are uploaded as a
- 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.
- Images must be 1280x720 pixel
- Videos
- 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)
- BYOL or Free
- 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.
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 or professional services. Any offers for hardware must be transacted outside of the marketplace.
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 21Vianet or Microsoft trademarks and the names of 21Vianet or Microsoft software, products, and services, follow Microsoft Trademark and Brand Guidelines and/or the 21Vianet's brand guideline.
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 Incentive, 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:
- 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.
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 21Vianet as needed
- Appropriately targeting customer segments, categories, or industries
- Appropriate configuration including offer type and pricing.
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 Azure operated by 21Vianet.
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: /virtual-machines/linux/endorsed-distros. Custom images may be subject to additional validation steps and requiring specific approval from Azure.
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.
VM image must get booted and rebooted successfully.
VM images should be able to connect to network. DNS name should be resolved successfully.
VM image should not contain any pre-existing users and password keys for them.
Microsoft Hyper-V virtual network driver 'hv_netvsc' should be loaded and reloaded gracefully.
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 (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.
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. 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.
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.
300.2 Acquisition, pricing, and terms
The resources will be provisioned in the customer's Azure subscription.
In the case of bring-your-own-license, 21Vianet 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. ThedefaultValue
must be [deployment().properties.templateLink.uri
]._artifactsLocationSasToken
- ThesasToken
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.
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
Primary Product: Azure | Eligibility Requirement(s) |
---|---|
Azure | To publish a Consulting Service offer in Commercial Marketplace, you must be enrolled into Microsoft Cloud Partner Program, and have qualified score in at least one of the following areas: Data & AI (Azure), Infrastructure (Azure), Digital & App Innovation (Azure), Security OR Retained benefits in the following competency based on competencies held as of September 30, 2022: Silver or Gold competency in at least one of the following areas: Application Development, Application Integration, Application Lifecycle Management, Cloud Platform, Data Analytics, Data Center, Data Platform, DevOps or Security. |
For more information on meeting these prerequisites, see the Consulting Services prerequisites.
The following sections provide more detail on publishing requirements for "Power" offer types noted in the table above.
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.
- Agendas for workshops longer than one day.
- Detailed itemization of briefing and workshop topics.
- Provide contact channels for customers who are interested in your solution and intend to contact your organization.
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.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:
800.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
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.
Next steps
Visit the commercial marketplace publishing guide.