Design tenant linking to scale selling on Microsoft Marketplace
Designing tenant linking and Open Authorization (OAuth) directly shapes how customers onboard, grant trust, and operate your AI app or agent through Microsoft Marketplace. In this context, consent refers to the explicit authorization a customer tenant grants—via OAuth—for a publisher’s application or agent to access specific resources and perform defined actions within that tenant. This post explains how to design scalable, review‑ready identity patterns that support secure activation, clear authorization boundaries, and enterprise trust from day one. Guidance for multi‑tenant AI apps Identity decisions are rarely visible in architecture diagrams, but they are immediately visible to customers. In Microsoft Marketplace, tenant linking and OAuth consent are not background implementation details. They shape activation, onboarding, certification, and long‑term trust with enterprise buyers. When identity decisions are made late, the impact is predictable. Onboarding breaks. Permissions feel misaligned. Reviews stall. Customers hesitate. When identity is designed intentionally from the start, Marketplace experiences feel coherent, secure, and enterprise‑ready. This article focuses on how to design tenant linking and consent patterns that scale across customers, offer types, and Marketplace review—without rework later. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why identity across tenants is a first‑class design decision Designing identity is not just about authentication. It is about how trust is established between your solution and a customer tenant, and how that trust evolves over time. When identity decisions are deferred, failure modes surface quickly: Activation flows that cannot complete cleanly Consent requests that do not match declared functionality Over‑privileged apps that fail security review Customers who cannot confidently revoke access These are not edge cases. They are some of the most common reasons Marketplace onboarding slows or certifications are delayed. A good identity and access management design ensures that trust, consent, provisioning, and operation follow a predictable and reviewable path—one that customers understand and administrators can approve. Marketplace tenant linking requirements A key mental model simplifies everything that follows, separate trust establishment from authorization. Tenant linking and OAuth consent solve different problems. Tenant linking establishes trust between tenants OAuth consent grants permission within that trust Tenant linking answers: Which customer tenant does this solution trust? OAuth consent answers: What is this solution allowed to do once trusted? AI solutions published in Microsoft Marketplace should enforce this separation intentionally. Trust must be established before meaningful permissions are granted, and permission scope must align to declared functionality. Making this explicit distinction early prevents architectural shortcuts that later block certification. Throughout the rest of this post, tenant linking refers to trust establishment, not permission scope. Microsoft Entra ID as the identity foundation Microsoft Entra ID provides the primitives for identity-based access control, but the concepts only become useful when translated into publisher decisions. Each core concept maps to a choice you make early: Home tenant vs resource tenant Determines where operational control lives and how cross‑tenant trust is anchored. App registrations Define the maximum permission boundary your solution can ever request. Service principals Determine how your app appears, is governed, and is managed inside customer tenants. Managed identities Reduce long‑term credential risk and operational overhead. Understanding these decisions early prevents redesigning consent flows, re‑certifying offers, or re‑provisioning customers later. Marketplace policies reinforce this by allowing only limited consent during activation, with broader permissions granted incrementally after onboarding. Importantly, activation consent is not operational consent. Activation establishes the commercial and identity relationship. Operational permissions come later, when customers understand what your solution will actually do. OAuth consent patterns for multi‑tenant AI apps OAuth consent is not an implementation detail in Marketplace. It directly determines whether your AI app can be certified, deployed smoothly, and governed by enterprise customers. Common consent patterns map closely to AI behavior: User consent Supports read‑only or user‑initiated interactions with no autonomous actions. Admin consent Enables agents, background jobs, cross‑user access, and cross‑resource operations. Pre‑authorized consent Enables predictable, enterprise‑grade onboarding with known and approved scopes. While some AI experiences begin with user‑driven interactions, most AI solutions in Marketplace ultimately require admin consent. They operate asynchronously, act across resources, or persist beyond a single user session. Aligning expectations early avoids friction during review and deployment. Designing consent flows customers can trust Consent dialogs are part of your product experience. They are not just Microsoft‑provided UI. Marketplace reviewers evaluate whether requested permissions are proportional to declared functionality. Over‑scoped consent remains one of the most common causes of delayed or failed certification. Strong consent design: Requests only what is necessary for declared behavior Explains why permissions are needed in plain language Aligns timing with customer understanding Poor explanations increase admin rejection rates, even when permissions are technically valid. Clear consent copy builds trust and accelerates approvals. Tenant linking across offer types Identity design must align with offer type; a helpful framing is ownership: SaaS offers The publisher owns identity orchestration and tenant linking. Microsoft Marketplace reviewers expect this alignment, and mismatches surface quickly during certification. Containers and virtual machines The customer owns runtime identity; the publisher integrates with it. Managed applications Responsibility is shared, but the publisher defines the trust boundary. Each model carries different expectations for control, consent, and revocation. Designing tenant linking that matches the offer type reduces customer confusion. When consent happens in Marketplace lifecycle Many identity issues stem from unclear timing. A simple lifecycle helps anchor expectations: Buy – The customer purchases the offer Activate – Tenant trust is established Consent – Limited activation consent is granted Provision – Resources and configurations are created Operate – Incremental operational consent may be requested Revoke – Access and trust can be cleanly removed Making this sequence explicit in your design—and in your documentation—dramatically reduces confusion for customers and reviewers alike. How tenant linking shapes Marketplace readiness Identity tends to leave a lasting impression as it is one of the first architectural design choices encountered by customers. Strong tenant linking and consent design lead to: Faster certification (applies to SaaS offer only) Fewer conditional approvals Lower onboarding drop‑off Easier enterprise security reviews These outcomes are not accidental. They reflect intentional design choices made early. What’s next in the journey Tenant identity sets the foundation, but it is only one part of Marketplace readiness. In upcoming guidance, we’ll connect identity decisions to commerce, SaaS Fulfillment APIs, and operational lifecycle management—so buy, activate, provision, operate, and revoke will work together as a single, coherent system. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessDesigning a reliable environment strategy for Microsoft Marketplace AI apps and agents
Technical guidance for software companies Delivering an AI app or agent through Microsoft Marketplace requires more than strong model performance or a well‑designed user flow. Once your solution is published, both you and your customers must be able to update, test, validate, and promote changes without compromising production stability. A structured environment strategy—Dev, Stage, and Production—is the architectural mechanism that makes this possible. This post provides a technical blueprint for how software companies and Microsoft Marketplace customers should design, operate, and maintain environment separation for AI apps and agents. It focuses on safe iteration, version control, quality gates, reproducible deployments, and the shared responsibility model that spans publisher and customer tenants. This post is part of a series on building and publishing well-architected AI apps and agents on Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why environment strategy is a core architectural requirement Environment separation is not just a DevOps workflow. It is an architectural control that ensures your AI system evolves safely, predictably, and traceably across its lifecycle. This is particularly important for Marketplace solutions because your changes impact not just your own environment, but every tenant where the solution runs. AI‑driven systems behave differently from traditional software: Prompts evolve and drift through iterative improvements. Model versions shift, sometimes silently, affecting output behavior. Tools and external dependencies introduce new boundary conditions. Retrieval sources change over time, producing different Retrieval Augmented Generation (RAG) contexts. Agent reasoning is probabilistic and can vary across environments. Without explicit boundaries, an update that behaves as expected in Dev may regress in Stage or introduce unpredictable behavior in Production. Marketplace elevates these risks because customers rely on your solution to operate within enterprise constraints. A well‑designed environment strategy answers the fundamental operational question: How does this solution change safely over time? Publisher-managed environment (tenant) Software companies publishing to Marketplace must maintain a clear three‑tier environment strategy. Each environment serves a distinct purpose and enforces different controls. Development environment: Iterate freely, without customer impact In Dev, engineers modify prompts, adjust orchestration logic, integrate new tools, and test updated model versions. This environment must support: Rapid prompt iteration with strict versioning, never editing in place. Model pinning, ensuring inference uses a declared version. Isolated test data, preventing contamination of production RAG contexts. Feature‑flag‑driven experimentation, enabling controlled testing. Staging environment: Validate behavior before promotion Stage is where quality gates activate. All changes—including prompt updates, model upgrades, new tools, and logic changes—must pass structured validation before they can be promoted. This environment enforces: Integration testing Acceptance criteria Consistency and performance baselines Safety evaluation and limits enforcement Production environment: Serve customers with reliability and rollback readiness Solutions running in production environments, regardless of whether they are publisher hosted or deployed into a customer's tenant must provide: Stable, predictable behavior Strict separation from test data sources Clearly defined rollback paths Auditability for all environment‑specific configurations This model highlights the core environments required for Marketplace readiness; in practice, publishers may introduce additional environments such as integration, testing, or preproduction depending on their delivery pipeline. The customer tenant deployment model: Deploying safely across customer environments Once a Marketplace customer purchases and deploys your AI app or agent, they must be able to deploy and maintain your solution across all their environments without reverse engineering your architecture. A strong offer must provide: Repeatable deployments across all heterogeneous environments. Predictable configuration separation, including identity, data sources, and policy boundaries. Customer‑controlled promotion workflows—updates should never be forced. No required re‑creation of environments for each new version. Publishers should design deployment artifacts such that customers do not have to manually re‑establish trust boundaries, identity settings, or configuration details each time the publisher releases a solution update. Plan for AI‑specific environment challenges AI systems introduce behavioral variances that traditional microservices do not. Your environment strategy must explicitly account for them. Prompt drift Prompts that behave well in one environment may respond differently in another due to: Different user inputs, where production prompts encounter broader and less predictable queries than test environments Variation in RAG contexts, driven by differences in indexed content, freshness, and data access Model behavior shifts under scale, including concurrency effects and token pressure Tool availability differences, where agents may have access to different tools or permissions across environments This requires explicit prompt versioning and environment-based promotion. Model version mismatches If one environment uses a different model version or even a different checkpoint, behavior divergence will appear immediately. Publishers should account for the following model management best practices: Model version pinning per environment Clear promotion paths for model updates RAG context variation Different environments may retrieve different documents unless seeded on purpose. Publishers should ensure their solutions avoid: Test data appearing in production environments Production data leaking into non-production environments Cross contamination of customer data in multi-tenant SaaS solutions Make sure your solution accounts for stale-data and real-time data. Agent variability Agents exhibit stochastic reasoning paths. Environments must enforce: Controlled tool access Reasoning step boundaries Consistent evaluation against expected patterns Publisher–customer boundary: Shared responsibilities Marketplace AI solutions span publisher and customer tenants, which means environment strategy is jointly owned. Each side has well-defined responsibilities. Publisher responsibilities Publishers should: Design an environment model that is reproducible inside customer tenants. Provide clear documentation for environment-specific configuration. Ensure updates are promotable, not disruptive, by default. Capture environment‑specific logs, traces, and evaluation signals to support debugging, audits, and incident response. Customer responsibilities Customers should: Maintain environment separation using their governance practices. Validate updates in staging before deploying them in production. Treat environment strategy as part of their operational contract with the publisher. Environment strategies support Marketplace readiness A well‑defined environment model is a Marketplace accelerator. It improves: Onboarding Customers adopt faster when: Deployments are predictable Configurations are well scoped Updates have controlled impact Long-term operations Strong environment strategy reduces: Regression risk Customer support escalations Operational instability Solutions that support clear environment promotion paths have higher retention and fewer incidents. What’s next in the journey The next architectural decision after environment separation is identity flow across these environments and across tenant boundaries, especially for AI agents acting on behalf of users. The follow‑up post will explore tenant linking, OAuth consent patterns, and identity‑plane boundaries in Marketplace AI architectures. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessHow Microsoft Foundry and Elastic Agent Builder in Microsoft Marketplace are shaping enterprise AI
In this guest blog post, Brian Bergholm, Principal Product Marketing Manager at Elastic, covers the evolution of agentic AI and how enterprises can leverage context engineering via Microsoft Foundry and Elastic Agent Builder in the Microsoft Marketplace to operationalize agentic systems at scale.Quality and evaluation framework for successful AI apps and agents in Microsoft Marketplace
Why quality in AI is different — and why it matters for Marketplace Traditional software quality spans many dimensions — from performance and reliability to correctness and fault tolerance — but once those characteristics are specified and validated, system behavior is generally stable and repeatable. Quality is assessed through correctness, reliability, performance, and adherence to specifications. AI apps and agents change this equation. Their behavior is inherently non-deterministic and context‑dependent. The same prompt can produce different responses depending on model version, retrieval context, prior interactions, or environmental conditions. For agentic systems, quality also depends on reasoning paths, tool selection, and how decisions unfold across multiple steps — not just on the final output. This means an AI app can appear functional while still falling short on quality: producing responses that are inconsistent, misleading, misaligned with intent, or unsafe in edge cases. Without a structured evaluation framework, these gaps often surface only in production — in customer environments, after trust has already been extended. For Microsoft Marketplace, this distinction matters. Buyers expect AI apps and agents to behave predictably, operate within clear boundaries, and remain fit for purpose as they scale. Quality measurement is what turns those expectations into something observable — and that visibility is what determines Marketplace readiness. This post is part of a series on building and publishing well-architected AI apps and agents on Microsoft Marketplace. How quality measurement shapes Marketplace readiness AI apps and agents that can demonstrate quality — with documented evaluation frameworks, defined release criteria, and evidence of ongoing measurement — are easier to evaluate, trust, and adopt. Quality evidence reduces friction during Marketplace review, clarifies expectations during customer onboarding, and supports long-term confidence in production. When quality is visible and traceable, the conversation shifts from "does this work?" to "how do we scale it?" — which is exactly where publishers want to be. Publishers who treat quality as a first-class discipline build the foundation for safe iteration, customer retention, and sustainable growth through Microsoft Marketplace. That foundation is built through the decisions, frameworks, and evaluation practices established long before a solution reaches review. What "quality" means for AI apps and agents Quality for AI apps and agents is not a single metric — it spans interconnected dimensions that together define whether a system is doing what it was built to do, for the people it was built to serve. The HAX Design Library — Microsoft's collection of human-AI interaction design patterns — offers practical guidance for each one. These dimensions must be defined before evaluation begins. You can only measure what you have first described. Accuracy and relevance — does the output reflect the right answer, grounded in the right context? HAX patterns Make clear what the system can do (G1) and notify users when the AI is uncertain (G10) help publishers design systems where accuracy is visible and outputs are understood in the right context — not treated as universally authoritative. Safety and alignment — does the output stay within intended use, without harmful, biased, or policy-violating content? HAX patterns Mitigate social biases (G6) and Support efficient correction (G9) help ensure outputs stay within acceptable boundaries — and that users can identify and address issues before they cause downstream harm. Consistency and reliability — does the system behave predictably across users, sessions, and environments? HAX patterns Remember recent interactions (G12) and notify users about changes (G18) keep behavior coherent within sessions and ensure updates to the model or prompts are never silently introduced. Fitness for purpose — does the system do what it was designed to do, for the people it was designed to serve, in the conditions it will actually operate in? HAX patterns make clear how well the system can do what it does (G2) and Act on the user's context and goals (G4) ensure the system responds to what users actually need — not just what they literally typed. These dimensions work together — and gaps in any one of them will surface in production, often in ways that are difficult to trace without a deliberate evaluation framework. Designing an evaluation framework before you ship Evaluation frameworks should be built alongside the solution. At the end, gaps are harder and costlier to close. The discipline mirrors the design-in approach that applies to security and governance: decisions made early shape what is measurable, what is improvable, and what is ready to ship. A well-structured evaluation framework defines five things: What to measure — the quality dimensions that matter most for this solution and its intended use cases. For AI apps and agents, this typically includes task adherence, response coherence, groundedness, and safety — alongside the fitness-for-purpose dimensions defined in the previous section. How to measure it — the methods, tools, and benchmarks used to assess quality consistently. Effective evaluation combines AI-assisted evaluators (which use a model as a judge to score outputs), rule-based evaluators (which apply deterministic logic), and human review for edge cases and safety-relevant responses that automated methods cannot fully capture. Who evaluates — the right combination of automated metrics, human review, and structured customer feedback. No single method is sufficient; the framework defines how each is applied and when human judgment takes precedence. When to evaluate — at defined milestones: during development to establish a baseline, pre-release to validate against acceptance thresholds, at rollout to catch regression, and continuously in production to detect drift as models, prompts, and data evolve. What triggers re-evaluation — model updates, prompt changes, new data sources, tool additions, or meaningful shifts in customer usage patterns. Re-evaluation should be a scheduled and triggered discipline, not an ad hoc response to visible failures. The framework becomes a shared artifact — used by the publisher to release safely, and by customers to understand what quality commitments they are adopting when they deploy the solution in their environment. Evaluate your AI agents - Microsoft Foundry | Microsoft Learn Evaluation methods for AI apps and agents Quality must be assessed across complementary approaches — each designed to surface a different category of risk, at a different stage of the solution lifecycle. Automated metric evaluation — evaluators assess agent responses against defined criteria at scale. Some use AI models as judges to score outputs like task adherence, coherence, and groundedness; others apply deterministic rules or text similarity algorithms. Automated evaluation is most effective when acceptance thresholds are defined upfront — for example, a minimum task adherence pass rate before a release proceeds. Safety evaluation — a dedicated evaluation category that identifies potential content risks, policy violations, and harmful outputs in generated responses. Safety evaluators should run alongside quality evaluators, not as a separate afterthought. Human-in-the-loop evaluation — structured expert review of edge cases, borderline outputs, and safety-relevant responses that automated metrics cannot fully capture. Human judgment remains essential for interpreting context, intent, and impact. Red-teaming and adversarial testing — probing the system with challenging, unexpected, or intentionally misused inputs (including prompt injection attempts and tool misuse) to surface failure modes before customers encounter them. Microsoft provides dedicated AI red teaming guidance for agent-based systems. Customer feedback loops — structured collection of real-world signals from users interacting with the system in production. Production feedback closes the gap between what was tested and what customers actually experience. Each method has a distinct role. The evaluation framework defines when and how each is applied — and which results are required before a release proceeds, a change is accepted, or a capability is expanded. Defining release criteria and ongoing quality gates Quality evaluation only drives improvement when it is connected to clear release criteria. In an LLMOps model, those criteria are automated gates embedded directly into the CI/CD pipeline, applied consistently at every stage of the release cycle. In continuous integration (CI), automated evaluations run with every change — whether that change is a prompt update, a model version, a new tool, or a data source modification. CI gates catch regressions early, before they reach customers, by validating outputs against predefined quality thresholds for task adherence, coherence, groundedness, and safety. In continuous deployment (CD), quality gates determine whether a build is eligible to proceed. Release criteria should define: Minimum acceptable thresholds for each quality dimension — a release does not proceed until those thresholds are met Known failure modes that block release outright versus those that are tracked, monitored, and accepted within defined risk tolerances Deployment constraints — conditions under which a release is paused, rolled back, or progressively expanded to a subset of users before full rollout Ongoing evaluation must be scheduled and triggered. As models, prompts, tools, and customer usage patterns evolve, the baseline shifts. LLMOps treats re-evaluation as a continuous discipline: run evaluations, identify weak areas, adjust, and re-evaluate before changes propagate. This connects directly to governance. Quality evidence — the record of what was measured, when, and against what criteria — is part of the audit trail that makes AI behavior accountable, explainable, and trustworthy over time. For more on the governance foundation this builds on, see Governing AI apps and agents for Marketplace readiness. Quality across the publisher-customer boundary Clear quality ownership reduces friction at onboarding, builds confidence during operation, and protects both parties when behavior deviates. In the Marketplace context, quality is a shared responsibility — but the boundaries are distinct. Publishers are responsible for: Designing and running the evaluation framework during development and release Defining quality dimensions and thresholds that reflect the solution's intended use Providing customers with transparency into what quality means for this solution — without exposing proprietary prompts or internal logic Customers are responsible for: Validating that the solution performs appropriately in their specific environment, with their data and their users Configuring feedback and monitoring mechanisms that surface quality signals in their tenant Treating quality evaluation as a shared ongoing responsibility, not a one-time publisher guarantee When both sides understand their role, quality stops being a handoff and becomes a foundation — one that supports adoption, sustains trust, and enables both parties to respond confidently when behavior shifts. What's next in the journey A strong quality framework sets the baseline — but keeping that quality visible as solutions scale is its own discipline. The next posts in this series explore what comes after the framework is in place: API resilience, performance optimization, and operational observability for AI apps and agents running in production environments. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessMicrosoft Marketplace Partner Digest | April 2026
April kickstarts a fast-paced quarter of accelerated opportunity as partners line up new co‑sell motions and expand channel‑led sales—including resale‑enabled offers—to reach more customers across global markets, all while rapidly building and publishing transactable AI apps and agents to Microsoft Marketplace to meet growing customer demand. ✨ Microsoft Cloud AI Partner Program This month brings several important updates to Specializations and Solutions Partner designations, including revised performance criteria for the Small and Midsize Business Management specialization and new skilling options across Modern Work, Teams, and Digital & App Innovation. Microsoft is also evolving specializations to better reflect the shift toward AI—introducing the Secure AI Productivity specialization, retiring the Adoption and Change Management specialization, and preparing to merge several existing specializations into streamlined, solution‑aligned offerings. Learn more 🆕 What’s new in Partner Center MFA enforcement for Partner Center APIs Partner Center is now enforcing multifactor authentication (MFA) for all app + user API calls, with full enforcement as of April 1, 2026. Any requests made without a valid MFA token will be blocked with a 401 response and error code 900421. All APIs already support MFA, so update your systems now to avoid disruptions, strengthen security, and align with Partner Center requirements. Learn more 📈 Go-to-market with Microsoft Marketplace Microsoft has released a new collection of Azure go‑to‑market assets built specifically for SMB audiences, giving partners step‑by‑step guidance, tailored messaging, and ready‑to‑use materials to drive demand in a rapidly expanding market projected to surpass $1 trillion by 2030. This content library equips distributors, resellers, and service providers with everything needed to engage SMB customers at scale—from solution plays and sales resources to campaign‑ready materials—helping partners build pipeline, deepen customer conversations, and grow recurring cloud revenue. Partners can explore the full Azure SMB content collection to activate these assets in upcoming campaigns and accelerate their cloud practice growth. Explore resources to engage Azure SMB customers Reduced Microsoft Dragon Copilot pricing Partners can now access a full library of Dragon Copilot training and go‑to‑market resources, including sales pitch decks, messaging and positioning guides, demo materials, FAQs, data sheets, infographics, and more—each with detailed descriptions to help teams understand how and when to use them. These materials are designed to help Dragon Copilot partners confidently market, sell, and support the solution with consistent, enterprise‑ready content. Access Dragon Copilot partner assets Plus, new Microsoft Dragon Copilot partner resources Additionally, Microsoft has announced a reduced list price for the Dragon Copilot per‑user license, effective May 1, 2026, across all current geographies. This update simplifies pricing, expands competitiveness, and retires the separate Physician Practice offer, consolidating all capabilities into the standard license. A new per‑encounter consumption model for ambient and generative AI capabilities will also launch on May 1, making usage easier to understand and manage. Together, these changes create a more streamlined, cost‑effective path for partners to drive Dragon Copilot adoption and growth. Read the announcement Marketplace offer optimization recommendations in App Advisor Microsoft has introduced a new AI‑powered Marketplace listing optimization capability in App Advisor, giving partners instant, personalized recommendations to improve the clarity, quality, and discoverability of their public Marketplace listings. The tool evaluates listings across six key categories—from value proposition to grammar—and provides targeted guidance aligned with Marketplace best practices, helping partners iterate faster without manual review cycles. Available free and on demand in the US, this capability enables continuous optimization so partners can strengthen engagement, improve search visibility, and stand out in an increasingly competitive catalog. Get recommendations for your Marketplace offer 💡Stay up to date with regular Partner Center announcements 📅 Marketplace events The Marketplace trainings and events calendar is updated with new trainings, live demos, and partner‑focused sessions designed to help software companies and channel partners accelerate co‑sell, private offers, and Marketplace‑first sales growth. Catch up on recent webinars and register for upcoming events that break down proven strategies, best practices, and highlight tools and resources to strengthen your Marketplace motions. Recent events Why Azure belongs in your multi-cloud strategy April 2, 2026 This event helps Marketplace‑aligned software companies understand why incorporating Azure into their multi-cloud strategy can boost customer acquisition, deal velocity, and co‑sell success. Partners will hear how to replicate solutions for Azure, tap into Microsoft funding programs, leverage tools that speed time‑to‑market, and convert modernization efforts into sustained Marketplace growth 🎥 Watch the recording Upcoming events Seamless private offers: From creation to purchase and activation April 15, 2026 (8:30 AM PDT) Next week’s session with Stephanie_Brice and Chr_Brown will provide partners an end‑to‑end look at how to execute seamless private offers—from creating them in Partner Center to extending them across channel‑led sales motions such as multiparty private offers, CSP private offers, all the way through customer purchase and activation. With a live demo, guidance on resale enabled offers and flexible billing schedules, and time for Q&A, attendees will see exactly how private offers work in practice to streamline deal execution and accelerate Marketplace business growth. Register to attend Maximize selling with Microsoft and Marketplace ROI April 28, 2026 (8:30 AM PDT) Partners will learn how to simplify their Microsoft co‑sell motions, unlock underutilized incentives, and automate manual Partner Center tasks using WorkSpan. Drawing on workflows that have powered more than $5B in co‑sell revenue, this session covers how to apply for Azure sponsorship, earn and activate Marketplace Rewards benefits, and use WorkSpan’s AI‑powered platform to drive earlier seller actions and stronger partnership execution. It’s a practical guide to capturing more value from the Microsoft ecosystem. Register to attend Revisit past sessions and see the full calendar of Marketplace community events for partners and customers. Whether you’re expanding co‑sell motions, publishing new AI‑powered solutions, optimizing private‑offer execution, or tapping into updated programs like Dragon Copilot, the opportunities to reach more customers and accelerate growth continue to expand. As always, we welcome your insights and feedback—let us know what topics you’d like to see covered in a future post so we can continue shaping this digest around what matters most to you.
