How to Create and Publish a SaaS Listing on the Azure Marketplace with Clazar
Last updated: July 13, 2026
Publishing a SaaS product on the Azure Marketplace is about far more than filling in a form. Each field shapes how buyers find your product, understand its value, and decide to subscribe — and a few of them are permanent once submitted. This guide walks through every section and field required to create and publish a SaaS listing on the Azure Marketplace via Clazar, with field-by-field instructions, character limits, tips, and best practices for each.
Throughout the guide, fields carry one of three status markers:
Compulsory — mandatory. The listing cannot be submitted without completing this field.
Optional — not required, but recommended for better discoverability and buyer engagement.
Optional (Recommended) — not mandatory, but strongly advised for best results.
Section 1: General Information
This is the first section of your Azure listing on Clazar, and it captures the core identity of your product — the title, identifier, alias, short description, and logo. It's also the first impression buyers get on the Azure Marketplace search results.
1.1 Listing Title — Compulsory
The Listing Title (up to 200 characters) is the official name of your SaaS product as it appears on the Azure Marketplace. It's the primary display name buyers see when browsing or searching, so it should be concise, descriptive, and brand-aligned.
Include your product name and a short qualifier if needed — for example, "Acme Analytics Suite — Business Intelligence Platform." Avoid generic terms like "Software" or "App" on their own, don't use all-caps, and steer clear of special characters like !, @, or # unless they're part of your brand.
1.2 Listing ID — Compulsory
The Listing ID (up to 50 characters) is a unique identifier for your listing that appears in the listing URL on the Azure Marketplace. This is a permanent identifier — once the listing is submitted to Clazar, the Listing ID cannot be modified under any circumstances, so choose it carefully before submitting.
Use lowercase letters, numbers, and hyphens only (for example, "acme-analytics-saas"). Keep it short, readable, and aligned with your product name, avoid spaces and special characters, and double-check the spelling before submission since it cannot be changed later.
1.3 Listing Alias — Compulsory
The Listing Alias (up to 60 characters) is an internal reference name used exclusively within Microsoft Partner Center. It will not be displayed on the Azure Marketplace and is not visible to buyers — it's intended for your internal team to easily identify and manage the listing within Partner Center.
Use a descriptive internal name your team will recognize, such as "Acme Analytics - Azure SaaS - v2." You may include version numbers or environment tags for clarity, and since this is internal-only, it can include spaces and punctuation.
1.4 Short Description — Compulsory
The Short Description (up to 100 characters) is a single-line summary of your product's core functionality. It appears on the Azure Marketplace search results page, directly below the listing title, and is one of the most critical fields for discoverability — buyers use it to quickly decide whether your product is relevant.
Write a single, clear sentence that captures what your product does and mention the primary value proposition (e.g., "Automate your data pipelines with real-time Azure-native analytics"). Include one or two relevant keywords naturally for search optimization, avoid repeating the product name if it's already in the title, and don't use jargon or abbreviations buyers may not understand.
1.5 Listing Logo — Compulsory
The Listing Logo is your product's visual brand identity on the Azure Marketplace, appearing as a thumbnail next to your listing in search results, on your product detail page, and in any Microsoft promotional materials. It must be PNG only, with a 1:1 (square) aspect ratio, and sized between 216 px and 350 px — both width and height must be equal and within this range.
Use your company or product logo with a clean, professional appearance, ideally at 216 × 216 px or 350 × 350 px for best quality. A transparent or white background keeps it looking clean across different backgrounds. Make sure the logo is legible at small sizes since it displays as a thumbnail, and don't include marketing text or banners in the image.
Section 2: Listing Overview
This section provides the full, in-depth overview buyers read on your Azure Marketplace product page. It includes the long description of your product and internal getting-started instructions — your primary opportunity to explain your product's value, capabilities, and use cases in detail.
2.1 Long Description — Compulsory
The Long Description (up to 5,000 characters) is the main body content of your marketplace listing page. It gives buyers a thorough understanding of what your product does, who benefits from it, and the specific pain points it addresses. This content is fully visible on your product detail page and supports HTML formatting for headings, lists, bold text, and links, so you can create a well-structured, readable description.
Aim to include a product overview (a clear explanation of what your SaaS product does), your target users (who benefits — e.g., data engineers, finance teams, IT administrators), the pain points addressed (the specific problems you solve), your key features (a bullet list of the most important capabilities), your Azure integration (how your product integrates with or complements Azure services), and a call to action encouraging buyers to start a trial or contact your team.
For best results, use clear headings and bullet points to improve readability, and aim for at least 1,000 characters — ideally 2,000–4,000 — to provide sufficient detail. Write in a professional but engaging tone, avoid excessive keyword repetition (it harms credibility and readability), and focus on business value and outcomes rather than just technical specs.
2.2 Getting Started Details — Compulsory
The Getting Started Details field (up to 3,000 characters) provides onboarding instructions for how buyers connect to your SaaS product and begin using it after purchase. This content is internal only — it's shared with Microsoft for internal reference and review purposes and is not published to the public marketplace page.
Include step-by-step instructions on how a buyer activates and accesses your product after purchasing from the Azure Marketplace, a link to your activation or landing page where buyers are redirected after subscription, any prerequisites or system requirements they need beforehand, and an overview of the onboarding flow (sign-up, account creation, configuration).
Since this is reviewed by Microsoft during the certification process, be clear and concise. Number your steps for clarity ("1. Go to…, 2. Enter…, 3. Click…") and keep it under 500 words for readability.
Section 3: Listing Assets
This section contains the visual branding collateral for your listing — product screenshots and optional demo videos displayed on your Azure Marketplace product page. High-quality visuals significantly increase buyer confidence and conversion rates.
3.1 Screenshots — Compulsory
Screenshots are displayed in a gallery on your product page and give potential buyers a visual preview of your interface and functionality. At least 1 screenshot is required, and you can add up to 5. They must be PNG only at exactly 1280 × 720 px (16:9 aspect ratio, landscape orientation). Each screenshot can include an optional caption of up to 100 characters.
A strong set of screenshots typically covers your main dashboard or home screen (Screenshot 1), a key feature or workflow in action (Screenshot 2), an analytics, reporting, or insights view if applicable (Screenshot 3), an integration or configuration screen if applicable (Screenshot 4), and user settings, an onboarding screen, or collaborative features if applicable (Screenshot 5).
Use actual product screenshots rather than marketing graphics, and make sure they're clear, high-resolution, and not blurry or pixelated. Remove or mask any sensitive data such as PII, real customer data, or API keys, and show a populated, working state of the product rather than empty or blank screens. Write captions that describe the action or feature shown (e.g., "Real-time dashboard showing KPI metrics").
3.2 Videos — Optional
Videos let you showcase your product in action through a demo, walkthrough, or explainer. They're optional but highly recommended, as they significantly increase buyer engagement. You can add up to 4 videos, and they must be hosted externally on YouTube or Vimeo and linked via URL (videos are not uploaded directly).
Consider a product demo (2–5 minutes) walking through key features, an explainer video giving a high-level overview of what the product does and the value it delivers, and a setup or onboarding tutorial showing how to get started in under five minutes.
Keep videos under five minutes since buyers have short attention spans, ensure they have clear audio narration or subtitles, set YouTube/Vimeo visibility to "Public" or "Unlisted" (not Private), and lead with your most valuable or engaging video first.
Section 4: Pricing
This section defines the pricing model and plans for your SaaS listing. Pricing configuration is critical and has permanent implications once published, so take time to thoroughly plan your pricing strategy before filling it in.
4.1 Pricing Type — Compulsory
⚠ Important: Once the listing is published, the pricing type cannot be changed. All pricing plans within a listing must use the same pricing type.
You have two options:
Flat Rate — A fixed recurring fee for access to the product, regardless of the number of users. Best for products where the entire organization accesses it without per-seat restrictions (e.g., a platform tool or infrastructure software).
Per User — A recurring fee charged per individual user who has access. Best for productivity tools, collaboration software, or products where pricing scales with team size.
As guidance: choose Flat Rate if you charge by organization or instance (e.g., $499/month per company), and choose Per User if you charge per seat (e.g., $15/user/month). Consult with your pricing and revenue team before making this selection.
4.2 Metered Dimensions — Optional
Metered Dimensions let you charge buyers for usage beyond the limits set in their subscription plan — additional usage-based charges on top of the base subscription fee. You can add up to 10 metered dimensions, and they apply across all pricing plans within the listing, not just specific plans.
Common use cases include API calls beyond a certain limit (e.g., $0.001 per API call over 10,000/month), data storage or processing volume (e.g., $5 per GB of data processed), and transactions or events processed (e.g., $0.01 per 1,000 transactions).
Only add metered dimensions if your product genuinely has usage-based costs. Clearly define the unit of measurement (e.g., per 1,000 API calls, per GB), and ensure your backend can accurately track and report usage to the Azure Marketplace Metering API.
4.3 Pricing Plans — Compulsory
Pricing Plans are the subscription tiers buyers choose from when purchasing your listing. You must create at least one plan. Each plan represents a distinct tier with its own price and description, and buyers can only select one plan at a time.
Each plan is built from the following fields:
Plan ID — Compulsory (up to 50 characters). A unique identifier visible in the listing URL for this specific plan. Use lowercase letters, numbers, and hyphens. This ID appears in the marketplace URL and cannot easily be changed after publishing. Examples: "starter-plan", "professional", "enterprise-tier".
Plan Name — Compulsory (up to 200 characters). The publicly visible name of the plan on the marketplace — what buyers see when selecting a subscription tier. Keep it clear and indicative of the tier level. Examples: "Starter", "Professional", "Enterprise", "Team Plan".
Plan Description — Compulsory (up to 3,000 characters). Visible to buyers, this explains what's included in this specific tier. It should clearly differentiate the plan from others and articulate the features, limits, and benefits at this price point — include the feature list for the tier, user/usage limits, support level, and any special benefits.
Free Trial Option — Optional (a checkbox to allow a one-month free trial). When enabled, buyers can try the plan for one month at no charge before being billed; after the trial ends, billing automatically begins at the plan's price. This is a powerful conversion tool and is strongly recommended for new listings to increase adoption.
Billing Terms and Payment Options — Compulsory (at least one billing term and payment option combination per plan). The billing term is the duration the buyer has access under a single billing cycle, selected from available options such as Monthly or Annual, and defines how long the subscription lasts before renewal. The payment option is how the buyer is billed — Monthly payment charges each month, while Upfront payment charges the full amount at the start of the term. The price / payment is the USD price for that billing term and payment option combination (e.g., 99.00 for $99/month). You can add multiple billing term/payment option combinations to the same plan — for example, offering both monthly and annual billing at different price points.
Section 5: Legal
This section captures the legal terms and privacy documentation for your listing. Buyers must agree to your End User License Agreement (EULA) before purchasing, and your Privacy Policy must be accessible so buyers understand how their data is handled. It's mandatory to complete this section before your listing can be published.
5.1 EULA (End User License Agreement) — Compulsory
The EULA defines the legal terms under which buyers may use your product. You have two options:
Standard Contract from Microsoft — Use Microsoft's standard commercial marketplace contract as your EULA. This is the quickest option and is pre-approved by Microsoft. It's recommended if you don't have specific custom legal requirements, and because buyers are already familiar with this contract format, it can improve conversion rates.
Custom EULA — Provide a URL linking to your own custom EULA hosted on your website. This suits organizations with specific licensing requirements, IP protections, or compliance obligations that differ from the standard Microsoft contract.
If you select a Custom EULA, ensure the URL is publicly accessible (not behind a login). Consult your legal team before choosing a EULA type, and have custom EULAs reviewed by your legal counsel to ensure compliance with Azure Marketplace policies.
5.2 Privacy Policy Link — Compulsory
Provide the URL to your company's Privacy Policy page (it must begin with https://). This link is displayed on your Azure Marketplace listing page so buyers can review how your product collects, processes, stores, and handles user data. A valid, accessible Privacy Policy is required by Microsoft before your listing can be published.
The URL must be publicly accessible with no login required, must use HTTPS rather than HTTP, and must cover data collection, use, storage, and sharing practices. Keep it current, as outdated privacy policies may lead to listing removal.
Section 6: Support
This section collects all support-related information and contact details for your listing, including buyer resources, internal support contacts used by Microsoft, and required support documentation. All contact information here is used internally by Microsoft and is not publicly displayed on the marketplace.
6.1 Support Resources — Optional
Support Resources are links to publicly accessible materials that help buyers understand, onboard, and use your product. These links are visible on the marketplace listing page and serve as self-service support. You can add up to 10 support resource links, which can include FAQs, documentation, blog posts, product overviews, tutorials, and more.
Recommended resource types include product documentation or a knowledge base (e.g., docs.yourproduct.com), an FAQ page, a getting started tutorial or quick-start guide, a blog post or case study, and a product overview or feature walkthrough page.
Add at least two or three resources to help buyers self-serve before contacting support, ensure all URLs are live and not broken, and use descriptive resource titles so buyers can quickly identify what each link provides.
6.2 Support Contact — Compulsory
The Support Contact is the person or team at your company Microsoft will contact when buyers report issues or open support tickets through the Azure Marketplace. These details are internal only — they are used by Microsoft to route buyer complaints, support escalations, and certification queries, and are not published on the marketplace.
Complete the following: the Name (full name of the support contact person or team, e.g., "Support Team" or "John Smith"), the Email (a valid, monitored address such as support@yourcompany.com), the Phone (with country code selected from the dropdown), and the Support URL (a link to your product's support page or help portal where buyers can submit tickets).
Use a team inbox rather than an individual's personal email to avoid disruption when staff changes, and ensure the email is actively monitored with a short response time, since Microsoft may test this during certification.
6.3 Engineering Contact — Compulsory
The Engineering Contact is the technical point of contact Microsoft will reach for technical issues related to the listing, integration, or certification failures — typically your lead developer, CTO, or engineering manager responsible for the marketplace integration. These details are internal only and are not published on the marketplace.
Complete the Name (full name of the engineering contact, e.g., "Jane Doe" or "Dev Lead"), the Email (a valid address such as engineering@yourcompany.com), and the Phone (with country code). The Engineering Contact and Support Contact can be the same person or different people, depending on your organization's structure.
6.4 Support Documents — Compulsory
Support Documents are additional documentation files that give buyers more in-depth information — brochures, white papers, product information documents, technical specs, or any other materials that help buyers evaluate and use your product. Upload between 1 and 3 documents.
Suggested document types include a product brochure or datasheet (PDF), a white paper or technical overview (PDF), and a case study or customer success story (PDF).
Use PDF format for universal compatibility, ensure documents are polished, branded, and professionally formatted, and keep file sizes reasonable — under 10 MB per document is recommended.
Section 7: Categories & Keywords
This section determines where your listing appears in the Azure Marketplace storefront and how buyers find it through search. Categories determine the storefronts (Azure Marketplace and/or Microsoft AppSource) where your listing is published, while keywords help buyers discover your listing through marketplace search. Getting this right is essential for maximum discoverability.
7.1 Primary Categories — Compulsory
Primary Categories determine which storefront sections and category pages your listing appears in on the Azure Marketplace and Microsoft AppSource. The Primary Category is required — select the top-level category that most closely matches your product type (e.g., Analytics, AI + Machine Learning, Security, Developer Tools, Business Applications). You can also add an optional Subcategory 1 for a more specific placement (e.g., under "Analytics," you might select "Business Intelligence") and an optional Subcategory 2 to refine the product type even further where available.
Choose the category a buyer would most naturally browse to find your type of product, select the most specific subcategories available for maximum placement relevance, and research competitor listings to see which categories similar products use.
7.2 Secondary Categories — Optional
Secondary Categories let you appear in an additional marketplace category beyond your primary selection, expanding your visibility to buyers browsing different sections of the marketplace. They follow the same structure as Primary Categories (a Secondary Category plus up to two subcategories).
Use Secondary Categories if your product serves two distinct use cases or buyer segments — for example, a security analytics tool could use "Security" as primary and "Analytics" as secondary. Don't select a secondary category just to maximize exposure if it doesn't genuinely apply.
7.3 Search Keywords — Optional (Recommended)
Search Keywords are terms that help buyers find your listing when searching the Azure Marketplace. You can provide up to 3 keywords (or keyword phrases), each up to 100 characters, and they're used by the marketplace search algorithm to surface your listing for relevant queries. This field is optional but strongly recommended.
Choose keywords buyers would actually type when searching for a product like yours, and use specific phrases rather than very generic single words (e.g., "data pipeline automation" rather than just "data"). Think about the pain point — "automated invoice processing," "real-time sales analytics," "cloud security monitoring" — and avoid using your product name as a keyword, since buyers searching by name will already find you. It can also help to consider what your top competitors rank for and use similar high-intent phrases.
For the complete, always-up-to-date version of these guidelines, refer to the full document here: