EMEA Software Development Companies Academy articles

How to integrate your product into Microsoft 365 Copilot

gabrielecastellani — Wed, 01 Apr 2026 12:35:54 GMT

Microsoft 365 Copilot has an agent store. Users can discover first party, third party and internally built agents, install them, and use them directly inside the Copilot experience they already work in.

For an ISV, this is not just an extensibility option. It is a distribution channel.

This guide focuses on one scenario only:

An ISV / Software Development Company wants to integrate its product with Microsoft 365 Copilot and publish an agent that customer organizations can deploy through Microsoft 365.

The best official starting point is the Microsoft 365 Copilot extensibility overview.

What publishing an agent actually means

When a customer installs your agent in Microsoft 365 Copilot, they are using your product through Copilot’s interface.

Your agent can expose your instructions, your APIs, your domain logic, and your data in a Microsoft 365-native experience. At the same time, deployment still happens within Microsoft’s enterprise environment, which means admin control, governance, validation, and platform rules still apply.

For an ISV, that means publishing is not just a packaging exercise. It is the point where your product becomes a deployable Microsoft 365 extension.

Start with the publishing target, not the tool

Before you build anything, decide how you want customers to get your agent.

There are two main publishing outcomes:

Publish to a specific customer organization
This is the right route for pilots, customer-specific deployments, and managed implementations.

Publish to the Microsoft Commercial Marketplace
This is the right route if you want broad discoverability through Microsoft channels, including the Microsoft 365 Copilot Agent store.

That decision matters early because not every build path supports the same publishing options. The official publishing matrix is here: Publish Agents for Microsoft 365 Copilot.

What to build

For an ISV targeting Microsoft 365 Copilot, there are three pro-code options.

Copilot connectors

Use this when your value is mainly in the data you want to provide to Copilot.

A connector pushes content from your platform into the Microsoft 365 semantic index so Copilot can retrieve, summarize, and reason over it.

This is a good fit for knowledge bases, document repositories, catalogs, and similar scenarios where the main need is grounding rather than actions. It’s also important to note that these grounding data sources should be relatively stable and not subject to frequent changes. For example, you might use a product catalog as a grounding source, but it would not be suitable for dynamic information like the current quantity in stock, which changes often.

Reference: Copilot connectors overview

Declarative agents

This is the most common option for ISVs that want to publish an agent.

A declarative agent lives inside Copilot, uses custom instructions, can call selected APIs, and gives customers a purpose-built experience for your product. But a declarative agent does not have its own foundational model or orchestration. Instead, Copilot deals with this.

MCP (Model Context Protocol) Can be used to extend declarative agents to bring external data in the context of the agent here a great video that shows how.

If your goal is to publish an agent into Microsoft 365 for customer deployment, this is usually the best place to start.

Reference: Declarative agents overview

Custom engine agents

Use this when you need to own the runtime, orchestration, model choice, or long-running workflows. Additionally, the custom engine approach is ideal for ISVs that already have their own agents and want to integrate them into the Copilot UI, making it easier for customers to access and interact with these agents directly within the Microsoft 365 environment. This integration allows ISVs to leverage their existing investments in agent technology while providing a seamless experience for end users.

Microsoft Foundry Use this when you are building or already have an agent on Azure infrastructure and want to publish it to Microsoft 365 Copilot without manual manifest and bot registration setup. Foundry supports a no-code publishing flow from the Foundry portal directly to Microsoft 365 Copilot and Teams, with built-in governance routing through the Microsoft 365 Admin Center. This path is agent-type agnostic — it works for prompt agents, hosted agents, and workflow agents. Reference: Publish agents to Microsoft 365 Copilot and Microsoft Teams (Microsoft Learn)

Reference: Custom engine agents overview

Where Copilot Studio fits

Copilot Studio also matters in this conversation, especially because it is a great way to quickly build agents on a SaaS platform and can be integrated into Microsoft Copilot easily. Many teams assume it offers the same publishing outcome as the pro-code route. Currently, it doesn’t.

According to Microsoft’s official publishing guidance, agents built with Copilot Studio can be published to Microsoft 365 Copilot and Teams and can be shared with individuals, groups, or made available through the organization’s catalog, depending on how availability is configured and how the tenant is governed. See: - Extend Microsoft 365 Copilot with agents in Copilot Studio - Connect and configure an agent for Teams and Microsoft 365 - Key concepts - Publish and deploy your agent

However, Microsoft’s publishing matrix makes the key limitation clear:

Copilot Studio is a good path for tenant deployment, not the default ISV marketplace path

If your goal is: - deploy to a specific customer tenant - pilot with a customer - share within an organization - publish through admin-controlled organizational deployment then Copilot Studio can be a valid option.

If your goal is: - broad ISV distribution - repeatable packaged deployment across many customers - submission to the Microsoft Commercial Marketplace - visibility in the broader Microsoft commercial publishing motion, then Copilot Studio is not yet the preferred starting point.

The official Microsoft 365 Copilot publishing documentation states that, today, only declarative agents built with Microsoft 365 Agents Toolkit and custom engine agents built with the same toolchain support submission to the Microsoft Commercial Marketplace. - Publish Agents for Microsoft 365 Copilot - Microsoft 365 Copilot agents admin guide

Practical reasoning for ISVs

For an ISV, the question is not whether Copilot Studio can build a good agent. It can.

The question is whether it matches your distribution model.

Copilot Studio is strongest when: - the deployment scope is one tenant or a controlled set of users - the solution is highly customized per customer - the customer or partner team wants low-code control in a Power Platform environment - marketplace-style packaging is not the primary requirement

Microsoft 365 Agents Toolkit is usually stronger when: - the agent is part of a repeatable product offer - the ISV wants app-style packaging and versioning - submission to the Microsoft Commercial Marketplace matters - the ISV wants a cleaner productization story for broad customer deployment.

Where MCP servers fit

MCP is important because it changes the packaging discussion.

If you expose your product through an MCP server, the MCP server is usually not the commercial product by itself. It is the integration layer that lets agents access your tools, actions, and real-time data.

That distinction matters for publishing.

The practical publishing logic for MCP-based solutions:

your agent is published through the Microsoft 365 app and agent path when you want a Copilot-native experience

your core commercial offer is published in Microsoft Marketplace as a SaaS application when your value is really the external service behind the MCP server

This is a useful pattern when your MCP server is backed by a multitenant cloud product that you own and operate. In that case, the MCP server is part of your SaaS architecture, and the SaaS offer becomes the cleanest commercial package for procurement, subscription, and customer onboarding. Microsoft’s marketplace guidance explicitly supports Software as a Service (SaaS) applications as a core offer type. See: - Overview of Microsoft Marketplace - Plan a SaaS offer for Microsoft Marketplace

When this matters most

This approach is especially relevant when: - the MCP server exposes real-time tools or transactional actions - the customer needs an ongoing subscription to your hosted platform - the value is primarily in your external service, not only in the Microsoft 365 shell - you want a cleaner procurement and licensing path for your underlying product

In other words: if the agent is the experience, but the SaaS platform is the product, publish the product as SaaS and treat MCP as the integration surface.

Practical guidance for ISVs

Use MCP when: - your customers need live access to tools, actions, or operational data - your product already exists as a hosted platform - your commercial model is subscription-based - you want the Microsoft 365 agent to act as a front end to your SaaS product

In that scenario, the cleanest model is often:

SaaS application in Marketplace + MCP-powered integration + agent experience in Microsoft 365 Copilot

This is more precise than thinking of MCP itself as the thing you publish.

MCP and Copilot Studio

Copilot Studio can also connect to MCP servers. Microsoft documents MCP onboarding in Copilot Studio and even notes that you can optionally publish the MCP connector for broader reuse across tenants. That is useful for enablement and reuse, but it is still a different concern from packaging your commercial offer as a SaaS application. See Extend your agent with Model Context Protocol.

So for ISVs, the practical split is: - MCP is the technical interface - SaaS offer is often the commercial offer - agent publishing is the user experience and deployment path inside Microsoft 365.

The above can be condensed in the following decision tree:

The pro-code stack in simple terms

For this publishing scenario, the important distinction is this:

Microsoft 365 Agents Toolkit

This is the development and packaging toolchain in Visual Studio Code. It is where you scaffold the project, manage the app package, test, and publish. Additionally, you define the adaptive cards that will display your content within Microsoft 365, allowing you to customize the user interface and present information interactively to users.

Reference: Microsoft 365 Agents Toolkit overview

Microsoft 365 Agents SDK

This is relevant mainly for custom engine agents. It is the communication layer between your agent runtime and Microsoft channels. As note this is the evolution of Bot Framework

Reference: Microsoft 365 Agents SDK overview

Microsoft Foundry provides a platform for building, testing, and publishing intelligent agents using the Agent Framework SDK (formerly Semantic Kernel).

For most ISVs building a declarative agent, the toolkit is the key piece.

The development flow before publishing

The standard pro-code flow is straightforward.

Scaffold
Use Microsoft 365 Agents Toolkit in VS Code to create the agent project and app package structure.
Configure
Define instructions, capabilities, and the APIs or actions you want to expose. If you have an OpenAPI definition, you can use it to shape the callable surface.
Test
Validate the experience in a development tenant before thinking about external distribution.
Package
Generate the Microsoft 365 app package that will be used for publishing.

A useful hands-on resource is Copilot Camp.

Publishing path 1: deploy to a specific customer organization

This is the fastest way to get an agent in front of a customer.

It is the right path for: - pilots - proof of concepts - customer-specific deployments - managed implementations

In this model, you build and package the app, then publish it to the customer tenant. The customer admin still has to approve and enable it.

This route does not mean “skip validation.” Responsible AI and platform checks still apply.

The relevant admin-side path is described here: Publish your app to your org.

Publishing path 2: publish to the Microsoft Commercial Marketplace

This is the path for broad distribution.

If you want your agent to be discoverable through Microsoft channels, including the Microsoft 365 Copilot store experience, you need to go through Partner Center.

The process is more formal and includes business, technical, and listing requirements.

Step 1 — Set up Partner Center early

Create and prepare your publisher account well before submission.

Reference: Partner Center for marketplace offers

Step 2 — Prepare the app package

Your package must be valid, complete, and aligned with the latest requirements for Microsoft 365 app publishing.

Helpful references: - Publish Agents for Microsoft 365 Copilot - Microsoft 365 app manifest reference

Step 3 — Prepare the store listing

You will need listing content, screenshots, support details, privacy documentation, and other materials required for store submission.

Helpful references: - Teams Store validation guidelines - Submission checklist

Step 4 — Submit and validate

Once submitted, the offer goes through Microsoft validation. Feedback may include issues that must be fixed before approval.

Reference: Publish to the Teams Store

What usually blocks publishing

For ISVs, the common blockers are not only technical.

Weak product value

If the agent looks like a thin wrapper around generic Copilot behavior, it may struggle in review.

Poor packaging quality

Manifest issues, inconsistent naming, broken metadata, or incomplete assets can stop a submission quickly.

Weak store readiness

Bad screenshots, vague descriptions, or incomplete privacy and support information create avoidable friction.

Unsafe or unclear actions

If the agent triggers actions in external systems, the experience must be clear, well-scoped, and safe.

Validation and policy issues

Marketplace and store requirements still apply, and they should be reviewed early.

Core references: - Microsoft Commercial Marketplace certification policies - Teams Store validation guidelines

What an ISV should have ready before submission

Before you submit, you should have these basics in place:

a clear use case and target user

a clear reason the agent adds value beyond generic Copilot chat

a stable API or product surface behind the agent

a valid app package

listing assets and store copy

support, privacy, and ownership information

a testing setup that covers the full end-to-end flow

A practical reference for readiness is the Microsoft 365 app publishing checklist.

Final takeaway

For an ISV or Software Development Company, publishing an agent into Microsoft 365 Copilot is not just about building an agent.

It is about packaging your product as a deployable Microsoft 365 extension, choosing the right publishing path, and meeting the requirements that let customers install it with confidence.

CPOR, DIPOR with a bit of DIOR - Microsoft Cloud usage attributions for Partners - EXPLAINED

OliverDMSFT — Mon, 09 Mar 2026 15:50:06 GMT

As a valued Microsoft Partner you most likely noticed, that there are several types of options (CPOR, CUA, DPOR, MBS, PAL and PRACR) to get recognized and rewarded for your impact in the Microsoft ecosystem.
Given their different purpose, you should always choose the option which suits your business needs best and represent the impact recognition you want to drive most.
This article intends to provide clarity on the best possible usage for your scenario, so you are backed by a data driven approach.

*KPI*	*What gets tracked?*	*Where does the consumption occur?*	*Who creates it?*	*When to use it?*
*CPOR*	Consumption influenced by the servicing partner	Customer tenant	Partner via Partner Center	Impact tracking for Modern Work or Dynamics365 workloads for several partners on subscription level
*CUA*	Consumption of a Deployment impact from a Partner Solution	Customer tenant	The resource deploying ARM/Terraform Template from the Partner	Microsoft internal recognition of the influenced Azure Consumption through a Partner Solution which is deployed using an Infra-as-Code approach. Does NOT count towards a Software Designation.
*DPOR*	Consumption influenced by the servicing partner	Customer tenant	The Customer in his tenant	Impact (consulting and consumption) tracking across all three Microsoft Clouds: Azure, Modern Work or Dynamics365 for ONE Partner on subscription level.
*MBS*	Sales in Marketplace for a Partner solution	Partner or Customer Tenant	The Marketplace	The partner wants to claim Microsoft Benefits and incentives tied to Marketplace application sales
*PAL*	Consumption influenced by the servicing partner	Customer tenant	Permission‑based	Reflect Azure consumption which has been influenced by consulting efforts and operational impact through a System Integrator. Fine granular definable down to an Azure resource level.
*PRACR*	Azure Consumption created by and end-customer who makes use of a SaaS offering which is hosted in the Partners Azure Tenant	Partner tenant	Manual reporting through uploaded CSVs by the Partner in Partner Center	Track the ACR which is driven by an end-customer in the Partner Tenant.

Let´s quickly summarize all of those insights the overview table shows above:

CPOR / CUA / DPOR / PAL: Those KPIs are needed when you want to answer “Who influenced or delivered Azure consumption in the customer tenant?”
PRACR : This KPI answers “How does a Partner report consumption that has been created by an end customer, but in the partner Azure tenant. ”
MBS: answers “How much total sales did a partner create for a solution no matter in which tenant it will be deployed, while Microsoft is responsible for collecting the payments.”

As always, those are just the high level comparisons and it is highly recommended to scroll further down to understand the details of the differentiation of each KPI, so that finally the best possible informed decision can be made.
Let’s dive right into it.

CPOR - Claiming Partner of Record

What it is

CPOR is a claims‑based model where one or more partners can claim servicing ownership of a Modern Work or Dynamics 365 subscription/workload via Partner Center.

Why CPOR exists

Reduces dependency on customer actions
Compared to DPOR, it gives the power of reporting to the partner

Key characteristics

One partner per workload/subscription
Claim‑based, not permission‑based
Separate from Azure infrastructure attribution

CUA - Customer Usage Attribution

What it is
CUA attributes Azure consumption to a Systems Integrations partner based on deployment‑level, using an Infrastructure-as-Code approach. It requires that the Partner creates a unique GUID for each solution per customer which should get tracked. This GUID has to be properly registered via Partner Center. Lastly, this GUID needs to be injected in the customers Azure Tenant via the deployment ARM/Terraform Script for the partner solution to successfully close the correct reporting cycle. This method is beneficial to influence the Microsoft internal statistics a Partner drives, but has not impact on his Software Designations he might want to achieve. Besides this, it counts towards Co-Sell visibility and other incentives like e.g. Azure Credits.

Key characteristics

Scenarios where Azure resources are deployed through an Infrastructure-as-Code approach in the end-customer Azure tenant.
Individual end customer usage tracking

Why and when is CUA preferred

High granularity
Durable attribution
Strong reporting quality for ACR and Microsoft’s internal analytics that highlight partner impact on an end customers Azure environment

CUA should NOT be used for

Azure Virtual Machine offers à Instead use the regular Marketplace Azure Virtual Machine offer option
Offers that make use of Azure Kubernetes Services, VM Scale Sets or Azure Batch, since it does not correctly measure the impact.

DPOR -Digital Partner of Record

What it is
DPOR associates one servicing partner to an Azure / Modern Work / Dynamics365 subscription.

Key points

The power of control is on the customer side, since only the customer can change the ID on the subscription level, necessary for the correct DPOR association.
Initially created for Enterprise Agreement (EA) contracts, but now also available with Microsoft Customer agreement (MCA) contracts
Needs to be re-entered when workloads are moving from an EA to a MCA contract.

MBS (Marketplace Billed Sales)

What it is

Marketplace Billed Sales (MBS) is the value of partner solutions that customers purchase and are invoiced for directly by Microsoft through the Microsoft commercial marketplace.

Key characteristics

The solution is sold through Microsoft Marketplace and with that, the Partner does not need to go through the procurement vendor onboarding process
The customer receives one Microsoft invoice which contributes to a lean procurement process for them
Applies to SaaS, virtual machines, managed applications, and other transactable partner offers
Depending on the offer, the hosting location can change. Either the partner Tenant (SaaS), or the customers tenant (Non-SaaS). Read more about the different offer types here: Azure Marketplace offer types
Indicates a real commercial adoption, not just a listing on a publicly accessible marketplace
For partners starting their commercial marketplace journey, it marks important milestones to achieve the status of IP Co-Sell eligibility. Once achieved, their purchasing end-customers can retire the whole amount of Azure consumption from their MACC. This creates a Win-Win for both involved parties (the partner and the end-customer), later down the road.
Leveraging MBS the right way, unlocks more benefits for the partner described in the Marketplace Rewards (like Azure Credits, Go-to-market support, Signature Event attendance like BUILD or IGNITE, and many more). Read more about this here: Marketplace Rewards
Shaping the pricing of the offers in the Marketplace is essential, in order to gain the best possible values for the next stage in the Marketplace rewards journey.

PAL - Partner Admin Link

What it is
PAL is an automated Azure‑native attribution mechanism that links a partner’s MPN ID to Azure resources in the customer Azure tenant, where the partner is delivering and operating services.

PAL tracks partner’s influence on Azure consumption, based on permissions and scope (subscription, resource group, resource) in the customers tenant.
To enable the automatic tracking, the partner needs to have an account or service principal in the end customers tenant. That identity needs to be associated with the partners MPN-ID.
Lastly, this identity needs to get assigned RBAC permissions on Subscription, resource group or resource level at the end customers tenant in order to get the automatism kicking off and tracking the right impact.
It works across Microsoft Customer Agreement (MCA), Web Direct, and EA contracts.

Key characteristics

No manual reporting
Durable (survives EA → MCA transition)
Recommended default for system integration partners delivering services in customer tenants
Power of control is on the end customer. His collaboration is required in order to correctly set up the process end to end.

Read more:

PRACR - Partner Reported Azure Consumed Revenue

What it is
PRACR is a KPI where partners report Azure consumption on behalf of a customer for workloads which run in the partners Azure tenant, but utilized by an end customer.

Why it exists
Standard Azure Consumed Revenue (ACR) is tied to a customer and as such, only sees consumption in customer tenants.
Many SaaS ISVs run their solutions entirely in their own tenant, which would otherwise make that Azure usage invisible to be deducted from the real end-customers Microsoft Azure consumption commitment (MACC) and also to Microsoft sales and incentives.
PRACR is the solution for that commercial and reporting issue.

Key characteristics

Partner reported and manually collected, monthly reported (currently not auto‑detected)
Applies to SaaS offer which are hosted in the Partner Azure tenant
IP Co‑Sell benefit

What PRACR is NOT

A billing mechanism
A customer‑tenant attribution
Used for SI/consulting services

Getting Started with the Microsoft Commercial Marketplace (for SaaS and AI Agents)

gabrielecastellani — Tue, 03 Mar 2026 13:29:42 GMT

If you build software—whether you’re an early‑stage startup or a seasoned ISV—the Microsoft Commercial Marketplace is one of the fastest ways to reach millions of customers globally, simplify procurement, and enable transactable offers directly inside Microsoft purchasing channels.

This post is a simple, public guide to help you understand what the Marketplace is, why it matters, and how to get your first offer live—whether that’s a SaaS app or an AI agent.

Why the Microsoft Commercial Marketplace?

Reach and trust: Sell where customers already buy, leveraging Microsoft’s commerce infrastructure and enterprise relationships.
Frictionless procurement: Enable private offers, custom terms, and procurement through existing Microsoft agreements.
Flexible business models: Support free trials, flat or tiered pricing, usage‑based (metered) billing, and both public and private plans.

Explore the public catalog here: https://azuremarketplace.microsoft.com/

Step 1: Set up your publisher account

Before you can list and transact, complete the publisher onboarding steps. This establishes your identity, payouts, tax profile, and the basics needed to publish offers.

Guide: https://learn.microsoft.com/en-us/partner-center/marketplace-offers/transacting-commercial-marketplace

Tip: Treat onboarding like opening a storefront—once complete, adding offers and plans becomes straightforward.

Note: you will need to be a Global Admin on your Entra ID tenant to be able to enroll your company into Microsoft AI Partner Program (MAICPP)

Step 2: Choose the right offer type

The Marketplace supports multiple offer types (SaaS, virtual machines, containers, managed apps, professional services, and more). Pick the model that best matches how customers consume your solution.

Overview by offer type: https://learn.microsoft.com/en-us/partner-center/marketplace/marketplace-offers-overview

Step 3: SaaS offers 101 (plans, pricing, and provisioning)

For SaaS publishers, you’ll define your offer once and attach one or more plans (e.g., Free, Pro, Enterprise). You can combine public plans for self‑serve purchase and private plans and private offer for negotiated deals.

How to plan a SaaS offer: https://learn.microsoft.com/en-us/partner-center/marketplace-offers/plan-saas-offer
Usage‑based (metered) billing: If your product usage varies (e.g., API calls, seats, storage), you can add metered dimensions to bill for what customers consume—both in public and private plans.
https://learn.microsoft.com/en-us/partner-center/marketplace-offers/saas-metered-billing

Step 4: Accelerate your SaaS integration

Provisioning, activation, and subscription lifecycle events are part of any SaaS listing.

Microsoft provides a reference implementation to speed this up:

Open‑source accelerator: https://github.com/Azure/Commercial-Marketplace-SaaS-Accelerator
This jump‑starts the technical integration (fulfillment, subscription events, webhook handling, and more).

Prefer a ready‑made service? Some third‑party providers offer a SaaS fulfillment layer as a managed service:

Example provider: https://www.wetransact.io/ (third‑party)

Note: Third‑party solutions are optional and independently operated—evaluate them like any other vendor.

You can keep both the Marketplace side and your product onboarding manual: publish your SaaS offer (including paid plans and private plans/offers) and route purchases to the SaaS Accelerator landing/admin portal, where new subscriptions appear so your team can manually activate and fulfill them; as order volume grows, you can add automation later using the Accelerator’s webhook/external‑notification features without changing your initial flow. The same manual‑first pattern applies if you prefer a third‑party fulfillment layer.

Mastering the Marketplace is a great resource to go deeper on this integration.

Step 5: Publish AI agents

If you’re building AI agents, you can publish them in the Microsoft Marketplace as well. The process is similar to other offer types, with additional guidance specific to agent capabilities and compliance.

How to publish AI agents: https://learn.microsoft.com/en-us/partner-center/marketplace-offers/ai-agent-overview

Step 6: Unlock go‑to‑market benefits

Publishing is just the beginning. The Marketplace comes with programs and benefits designed to help you grow awareness, generate demand, and accelerate sales.

Go‑to‑market benefits: https://learn.microsoft.com/en-us/partner-center/marketplace-offers/gtm-your-marketplace-benefits
Early‑stage accelerator: Consider ISV Success for Software Development Companies—it can speed up your Marketplace journey and overall product readiness.

Practical next step: Publish your MVP offer with a clear value proposition and one to two simple plans, then layer in GTM benefits once you’re live.

Often asked:

A simple launch checklist

SignUp to ISV Success link
Complete publisher onboarding (accounts, tax, payouts).
Select your offer type (SaaS, AI agent, etc.).
Define plans and pricing (public and/or private).
Implement fulfillment (use the SaaS Accelerator or your own stack).
Configure legal, images, and listing content (clear benefits, screenshots, pricing table).
Test end‑to‑end (trial purchase, provisioning, seat changes, cancellation).
Publish and activate GTM benefits (listing promotions, demand generation, co‑sell alignment).

Final tips

Start simple: One clear offer, one to two plans, crisp messaging.
Make pricing obvious: Customers should instantly understand value vs. cost.
Operational readiness: Test provisioning, suspension, upgrades, and cancellations before you go live.
Leverage benefits: Use Marketplace GTM and programs like ISV Success early—they compound over time.

Multi-tenancy in Agentic AI – session recap

bovrhovn — Tue, 24 Feb 2026 10:35:55 GMT

Software as a Service (SaaS) enables software development companies (SDCs) to deliver their products as managed services to customers. Whether offered business to business (B2B) or business to consumer (B2C), the way a product—new or existing—is designed to support multiple tenants (such as customers, user groups, or internal departments) can vary based on many factors. ‑to‑business (B2B) or business‑to‑consumer (B2C), the way a product—new or existing—is designed to support multiple tenants (such as customers, user groups, or internal departments) can vary based on many factors.

Multi-tenancy on Microsoft Learn - SaaS and Multitenant Solution Architecture - Azure Architecture Center | Microsoft Learn

To help you with architectural considerations (questions like “how will you define tenant”, “how will you deploy your infrastructure to support multitenancy”, “how will you monitor, automate, scale”, etc.), we have an assessment (available here) to guide you step by step through that. We’ve even built a checklist (more here) as a starting point to help you design and build your multitenant solution with ease.

In general, most common ways / perspectives we can handle multi-tenancy are:

Application (do we have shared apps for all customers, or we create apps specific for customers, …)
Data (do we use one data storage, do we multiple, how do we effectively query through data, how do we scale / partition, when do we scale …)
Infrastructure (do we handle one region, do we handle multiple, how do we do multiple customers across multiple regions, …)
Agents (how we align agent with tenants, do we create agent per tenant, or load tenant-based tools, prompts, data in shared ecosystem, …)

In the session (video available here, slides here, demos here) we were focusing on 2 things (with concrete examples):

Application and data perspective with proposed architecture patterns (stamp pattern, circuit breaker)
Agent usage with different techniques and patterns (semantic caching, agent id)

Starting with a clean multi-tenant design is ideal, but we recognize that this is often not the reality in the field. With that in mind, the demos we are presenting in the session are built with:

having web (UI) and API (backend business logic and agent usage) applications, which are not multi-tenant, and then go step by step and transform, highlighting what it takes to change the app and backend from single to multi customer usage.
Continuing with focusing on how to handle agent usage with different approaches (semantic caching, loading tools / prompts based on tenant identifier, etc.) to server multiple tenants efficiently.

Recording of the session

After you watch the video, you’ll notice that multi-tenancy comes with many considerations, challenges, and different ways to approach it, locally and on Azure.

Azure—and our team—are here to simplify this journey for you and your customers.

p.s.

Check also other webinars and recordings from our SDC academy.

SDC Academy live Webcast and Recordings

gabrielecastellani — Tue, 03 Mar 2026 08:03:44 GMT

We’re excited to introduce our live webcast series,

designed to help Software Development Companies (SDCs) succeed by providing consolidated resources and expert-led sessions.

Why Join?

Stay Ahead of the Curve: Gain insights into the latest Microsoft technologies and marketplace strategies.
Learn from Experts: Access practical guidance and best practices directly from technical specialists.
Boost Your Business: Explore how to extend and enhance your applications and harness Agentic AI to deliver scalable, intelligent solutions for your customers.
Engage & Network: Participate in live Q&A sessions and connect with peers in the SDC community.

Each session includes 45 minutes of technical content plus 15 minutes of live Q&A and will be delivered in English.

Marketplace series

To be announced soon

Technical Deep Dive

Data Science with Fabric - Tuesday, March 10, 2026 15:00 - 16:00 Berlin Time - Registration Link
Code to Cloud Confidence: How CNAPP + CSPM + MSEM Strengthen Your Security Posture - Tuesday, March 17, 2026 15:00 - 16:00 Berlin Time - Registration Link

Recordings of past events

Model Context Protocol: Building Agent‑Ready Platforms - Video
How to Extend Copilot as an Software Development Company - Video
Agentic AI Multitenancy - Video content https://aka.ms/mtoa-demos - post
Marketplace Hero for Software Development Companies - Video

Introducing the EMEA SDC Academy: A Centralized Hub for Deep Technical Enablement

rodanthi — Wed, 04 Feb 2026 16:27:08 GMT

Software Development Companies (SDCs) across EMEA are building faster, smarter, and more scalable solutions than ever before. To support this momentum, we’re excited to introduce the SDC Academy - a new technical content hub designed to help SDCs accelerate innovation and bring high‑quality solutions to market.

This blog and webinar series brings together expert‑led deep dives, architectural guidance, and applied best practices across the Microsoft ecosystem, including Azure, AI, Marketplace, and multi‑tenant design patterns. It also provides clear pathways for startups to engage with Microsoft programs such as Microsoft for Startups | Microsoft and benefit from technical, business, and go‑to‑market support.

Why the SDC Academy?

SDCs often face similar challenges - scaling architectures, building secure multi‑tenant SaaS, optimizing AI latency, or navigating Marketplace enrollment. Yet technical guidance is often scattered across repositories, documentation, and isolated experiences.

The SDC Academy consolidates these learnings into a central, openly accessible space built for SDCs of every shape and maturity level. Sessions and posts will:

Focus on deep technical scenarios rather than introductory content
Highlight proven architectural patterns, trade‑offs, and real‑world best practices
Combine technical depth with practical business guidance, including Marketplace strategy
Provide clear next steps for engaging with Microsoft experts, resources, and partner programs

What You Can Expect

The Academy publishes content in a predictable ongoing cadence, including

blog posts
webinars

Topics include:

Architecting Agentic AI: Best practices in multi‑agent orchestration, latency management, and integrating MCP (Model Context Protocol) into production solutions.
Extending Microsoft Copilot for SDC Scenarios: How to build and extend agents using Copilot Studio and pro‑code toolkits.
Multi‑Tenant and Scalable SaaS Architectures: Patterns for resource design, isolation, API management, and scaling strategies on Azure.
Marketplace Readiness and Monetization: Practical guidance on listing, transacting, and benefiting from Marketplace programs.

As Agentic AI moves from experimentation to real-world adoption, SDCs are uniquely positioned to lead. The Academy will dedicate a significant portion of its content to Agentic AI best practices - this focus reflects direct partner demand as seen across our technical webinars and planning sessions.

The blogs will be released gradually over the coming weeks as we build out the full public library of content! Follow us on this journey!

EMEA Software Development Companies Academy articles

How to integrate your product into Microsoft 365 Copilot

What publishing an agent actually means

Start with the publishing target, not the tool

What to build

Copilot connectors

Declarative agents

Custom engine agents

Where Copilot Studio fits

Where MCP servers fit

The above can be condensed in the following decision tree:

The pro-code stack in simple terms

Microsoft 365 Agents Toolkit

Microsoft 365 Agents SDK

The development flow before publishing

Publishing path 1: deploy to a specific customer organization

Publishing path 2: publish to the Microsoft Commercial Marketplace

What usually blocks publishing

What an ISV should have ready before submission

Suggested reading order

Final takeaway

CPOR, DIPOR with a bit of DIOR - Microsoft Cloud usage attributions for Partners - EXPLAINED

CPOR - Claiming Partner of Record

What it is

Why CPOR exists

Key characteristics

CUA - Customer Usage Attribution

Key characteristics

Why and when is CUA preferred

CUA should NOT be used for

DPOR -Digital Partner of Record

MBS (Marketplace Billed Sales)

What it is

Key characteristics

PAL - Partner Admin Link

Key characteristics

PRACR - Partner Reported Azure Consumed Revenue

Key characteristics

What PRACR is NOT

Getting Started with the Microsoft Commercial Marketplace (for SaaS and AI Agents)

Why the Microsoft Commercial Marketplace?

Step 1: Set up your publisher account

Step 2: Choose the right offer type

Step 3: SaaS offers 101 (plans, pricing, and provisioning)

Step 4: Accelerate your SaaS integration

Step 5: Publish AI agents

Step 6: Unlock go‑to‑market benefits

Often asked:

A simple launch checklist

Final tips

Multi-tenancy in Agentic AI – session recap

SDC Academy live Webcast and Recordings

Marketplace series

Technical Deep Dive

Recordings of past events

Introducing the EMEA SDC Academy: A Centralized Hub for Deep Technical Enablement