Microsoft 365 Copilot Brand Kits: Making On-Brand Content Easier to Create
Creating a presentation should begin with the message, not with searching for the latest logo, confirming the correct font, or finding a slide deck that looks close enough to the corporate standard. AI can accelerate content creation, but speed alone does not solve brand consistency. Without the right assets and guidance, the result can still require significant cleanup before it is ready to share. Microsoft 365 Copilot Brand Kits bring approved brand assets and guidance into the content creation experience. Employees gain a clearer starting point, while brand managers and IT can control which organizational branding is available and who can manage it. The opportunity is straightforward: make approved branding easier to use, reduce avoidable rework, and help people focus on what they want to communicate. This article explains what Brand Kits include, how personal, shared, and official kits differ, how templates and organizational asset libraries affect PowerPoint results, and what administrators should configure before a pilot. Readers who are evaluating the experience can begin with the PowerPoint and template sections; administrators can start with setup, governance, and storage. What is a Copilot Brand Kit? A Brand Kit is a managed collection of approved brand assets and guidance—such as logos, colors, fonts, imagery, templates, and tone—that helps people create content aligned with an organization’s identity. In Microsoft 365 Copilot, Brand Kits provide a consistent starting point for branded content while allowing organizations to control how those assets are created, shared, and published. A Brand Kit brings together the elements that define an organization’s visual and verbal identity. Depending on how it is configured, that can include: Logos: Primary, secondary, and approved variations. Colors and fonts: Brand palettes and typography. Images and icons: Approved photography, illustrations, and visual assets. Templates and layouts: Reusable structures for creating content. Brand voice: Guidance on tone, terminology, and communication style. Usage guidelines: Rules for how brand elements should—and should not—be used. These elements help connect content creation to the organization’s standards rather than leaving each employee to assemble their own interpretation. For organizations with multiple brands, business units, or product identities, separate kits can help keep the right assets associated with the right content. Think of a Brand Kit as a managed starting point, not a guarantee that every generated result will be publication-ready. Personal, shared, and official: Understanding the three kit types Brand Kits support three different scopes of use. Personal Brand Kits: Personal kits are available only to their creator. They support individual work without exposing those assets across the organization. Creation rights still depend on organizational policy. “Personal” describes the kit’s audience—not an exemption from administrative controls. Shared Brand Kits: Shared kits make assets available to selected people based on the permissions assigned by the creator. They can support a department, project, or other defined group. Giving someone edit permission on a shared kit does not bypass the organization’s restrictions on who may create or edit kits. Official Brand Kits: Official kits are managed by designated brand managers and made available across the tenant. They provide an organization-wide option for approved corporate branding. This distinction matters: a kit shared with a team is not automatically an official organizational kit. How Brand Kits help in PowerPoint For PowerPoint, a Brand Kit provides access to approved assets and presentation templates that help guide generated content. Users can select an available Brand Kit when creating content and ask Copilot to incorporate relevant brand imagery. They can also start from an approved presentation or template. A practical approach is to: Choose the appropriate published Brand Kit. Use an approved template suited to the presentation. Describe the audience, purpose, and desired structure. Generate the content. Review the result for accuracy, readability, accessibility, and brand alignment. Selecting a Brand Kit does not automatically restyle existing slides. If the goal is to update an existing presentation, explicitly request or apply the branding changes. Copilot supports PowerPoint on Windows, Mac, and the web; availability also depends on licensing and organizational settings. Your template is as important as your assets A complete logo library cannot compensate for a weak PowerPoint template. Templates must show how the organization presents information, not merely define a color palette. Representative slides demonstrate how titles, text, images, charts, and other objects work together in realistic layouts. Include representative sample slides You do not need one sample slide for every possible layout. Instead, provide examples that reflect common and specialized presentation needs. A practical collection might include: A title slide and section divider. A straightforward content slide. An image-led slide. A chart or table. A process or timeline. A summary and next-steps slide. Choose examples that reflect how people actually communicate in your organization. A sales presentation and a technical briefing may need different patterns. Make placeholders intentional Copilot uses placeholder type, position, and size to understand the layout. Placeholder text is not a hidden instruction channel. Writing “Insert an executive summary here” inside a placeholder does not make that wording a semantic instruction to Copilot. Use the prompt to explain the communication goal. Use the template to demonstrate the presentation structure. Prepare for varying amounts of content Copilot does not resize the font or placeholder when generated text needs more space. Instead, it may add design elements to accommodate the content. That makes review important. Check for overcrowded slides, awkward text flow, and content that would be clearer if split across multiple slides. Keep instructions separate where possible Instructional slides can remain when they use reusable layouts, but mixing template guidance with normal presentation content can produce unintended results. A better practice is to keep reusable sample slides focused on the desired output and maintain detailed authoring instructions separately. Both .pptx and .potx files are supported as Brand Kit templates. Administrative setup Microsoft’s setup guidance directs administrators to configure the brand manager policy in the Microsoft 365 Apps admin center (config.office.com) using a tenant-wide policy and the designated security group. The setting appears as Elevated role for Brand Managers. Allow up to 24 hours for policy changes to take effect before treating a missing capability as a configuration failure. Restricting kit creation does not prevent users from accessing and using published official kits. Group membership matters Official editing and publishing rights are granted to members of the configured mail-enabled security group. Being a group owner is not enough. If an owner also needs to manage official Brand Kits, ensure that person is a member as well. Governance: Two permission checks, not one One of the most important administrative details is the relationship between two controls: Restrict brand kit creation governs who can create and edit kits. Enterprise Brand Manager governs publishing and management of official kits. When creation restrictions are enabled, a user needs the appropriate permissions under both controls to create and publish an official kit. For example, a person with Enterprise Brand Manager rights who is not in the permitted creation group cannot create or edit kits under that restriction. Conversely, someone allowed to create kits does not automatically have permission to publish an official kit. Storage and organizational asset libraries The implementation guidance supplied with this article describes Brand Kit data as stored in SharePoint Embedded containers: Personal and shared kits use user-based containers. Official kits use the official Brand Kit container. Organizations should verify which governance, labeling, retention, and access controls apply to their SharePoint Embedded containers and configuration. SharePoint Embedded storage does not by itself establish that every policy used for a conventional SharePoint site applies in the same way. An organizational asset library, or OAL, has a related but different role. An OAL can hold approved assets that a Brand Kit references. This lets organizations reuse an established asset collection rather than treating every kit as a separate collection of uploaded files. For PowerPoint, the important distinction is: In PowerPoint, users select the published Brand Kit, while the organizational asset library can supply assets referenced by that kit. Referencing assets also makes source accessibility important. If an asset cannot be found, check that the referenced OAL content remains accessible. Uploading the asset into the kit may be an alternative where appropriate. A practical way to get started Start with a focused pilot rather than loading every brand asset your organization owns into the first kit. Choose one presentation scenario Select a common use case, such as customer updates, internal briefings, or project reviews. This gives the team a concrete way to assess whether generated content meets real needs. Agree on ownership Identify who approves the assets, who maintains the template, who publishes the kit, and who manages the supporting permissions. A clear owner makes it easier to keep the kit current after launch. Prepare the template Review sample slides, placeholders, theme colors, fonts, and reusable layouts. Remove outdated examples and separate instructional material from production-ready samples where possible. Assemble the assets and guidance Include the approved logos, imagery, colors, fonts, and brand guidance needed for the pilot. Use compatible asset formats and sensibly sized images. Avoid unnecessarily large files—particularly images over 10 MB—as a performance precaution, not as a stated product upload limit. Configure permissions and publish Confirm both creation/editing permissions and official publishing rights. Check actual group membership rather than assuming that ownership or another administrative role provides access. Test with realistic prompts Evaluate more than whether the logo appears. Check layout selection, content density, imagery, readability, tone, and factual accuracy. Use the results to improve the kit and template before expanding adoption. An example prompt After selecting the appropriate Brand Kit, try a prompt such as: Create a presentation introducing our proposed customer onboarding approach to business stakeholders. Use the selected Brand Kit and its approved presentation template. Include the business problem, proposed approach, implementation stages, responsibilities, and next steps. Keep each slide focused on one main idea, use approved brand imagery where relevant, and add speaker notes. Do not invent metrics or customer examples; identify any missing information. The prompt explains the audience, purpose, and structure. The selected kit supplies the approved brand context. Four reliable ways to apply branding Choose the method that matches the task: use the organization theme for standard defaults, begin with a seed file when the presentation needs established structure, apply a named theme when that theme is available, or select a brand directly in PowerPoint. Frequently asked questions Do we need a sample slide for every layout? No. Prioritize representative examples across the slide types and specialized scenarios your organization actually uses. Can placeholder text tell Copilot what to generate? Not as semantic guidance. Placeholder type, position, and size inform layout; placeholder wording can influence styling but is not treated as an instruction. What happens when text does not fit? Copilot does not change the font size or placeholder size. It may add design elements. Review the result and simplify or split content where needed. Which template formats are supported? Both .pptx and .potx. Can instructional slides stay in the template? They can, when they use reusable layouts. However, keeping instructions separate reduces the risk of guidance appearing as presentation content. Can existing OAL assets be used? Yes. A Brand Kit can reference approved OAL assets. For PowerPoint Brand Kit selection, publish the kit rather than relying on the OAL alone. Why can a brand manager not create or publish an official kit? Check both permission controls. When creation restrictions are enabled, Enterprise Brand Manager rights alone are insufficient if the person is outside the permitted creation group. Also confirm that the person is a member, not only an owner, of the relevant group. Does selecting a kit update an existing presentation? No. Explicitly request or apply branding to existing slides. What should we check when assets are missing? Confirm that the kit is published, the expected assets are included, and referenced OAL content is accessible. Where appropriate, upload the assets directly into the kit. What most affects the quality of the output? The completeness of the kit and the quality of its template—especially representative sample slides, usable placeholders, and consistent theme settings. The bottom Line Microsoft 365 Copilot Brand Kits can make approved branding easier to use in everyday content creation. The strongest approach combines three things: a well-prepared kit, a well-designed template, and clear ownership. Start with a focused scenario, test realistic output, and refine the underlying assets and guidance. Human review remains essential, but a stronger starting point lets people spend less time correcting formatting and more time communicating clearly. References Create and manage official Brand kits in the Microsoft Copilot app | Microsoft Support Edit with Copilot in PowerPoint | Microsoft Support Use branded templates in the Microsoft Copilot app | Microsoft Support Enterprise brand manager policy setup | Microsoft Learn Set Up the Restrict Brand Kit Creation Policy in Microsoft Copilot | Microsoft Learn Keep your presentation on-brand with Copilot | Microsoft SupportBuild a Tenant-Wide Microsoft Foundry Model Operations Dashboard
As AI projects move from pilots to production, model deployments often spread across subscriptions, regions, and application teams. A practical operations dashboard gives platform, engineering, governance, and finance teams one shared view of what is deployed, how it is used, what it costs, and where quota or capacity risk is forming. The operating problem Microsoft Foundry brings agents, models, tools, monitoring, tracing, evaluations, RBAC, networking, and policy controls under a unified platform surface. That is a strong foundation, but enterprise operations still need a view that cuts across the way Azure is usually organized: multiple subscriptions, resource groups, regions, business units, and application teams. The goal is not to replace product dashboards. The goal is to add a management-group or tenant-wide operating layer that answers simple but urgent questions: Which models are deployed? Which teams own them? Which deployments use Standard, priority, batch, or provisioned throughput? Where are token usage and PTU utilization rising? Which subscriptions are approaching quota pressure? Which costs should be allocated to which product or environment? Design principle: keep the dashboard about deployment and operations metadata. Do not collect prompts, completions, customer data, or other application payloads unless a separate privacy, security, and compliance design explicitly requires it. A practical reference architecture Use three data planes. First, build the inventory plane with Azure Resource Graph, because Resource Graph is designed for efficient, large-scale querying across subscriptions and tenants. Combine account-level resource data with deployment-level data from the Azure AI Services deployments API, which lists deployments associated with a Cognitive Services account. Normalize subscription, resource group, region, account, deployment name, model name, model version, deployment type, SKU or capacity, tags, owner, environment, and business unit. Build the telemetry plane with Azure Monitor. Public Azure OpenAI monitoring guidance describes dashboards for HTTP requests, token-based usage, PTU utilization, and fine-tuning. Azure Monitor supported metrics and resource log references provide the authoritative place to check what is available for each resource type and how exportability works. For exploratory operations views, Azure Workbooks are a good fit because they combine logs, metrics, parameters, Azure Resource Graph, Azure Resource Manager, JSON, and other data sources in one interactive report. Build the finance plane with Cost Management APIs or exports. Cost Management automation guidance supports retrieving and managing cost data, including for larger datasets that need offline analysis. The Cost Management Query API supports usage queries at scopes such as subscription, resource group, billing account, management group, billing profile, and invoice section, subject to permissions. Power BI can be useful for leadership reporting, but the Cost Management connector has agreement constraints; direct connector support is documented for Enterprise Agreement and direct Microsoft Customer Agreement customers, while unsupported agreements should use exports. Separate inventory, usage, cost, and quota Do not treat every signal as the same kind of data. Inventory is mostly current-state metadata. Usage is time-series behavior. Cost is billing-scope data that may lag and must be joined carefully by resource identity, meter, and tags. Quota is a capacity-control signal, not a spend signal. Azure OpenAI quota is not enforced at tenant level; Microsoft Learn states that the highest quota restriction is scoped at the Azure subscription level. That means an executive dashboard can summarize quota posture broadly, but engineering views should still preserve subscription, model, region, and deployment-type detail. Provisioned throughput deserves a dedicated view. Microsoft documents PTU as dedicated model processing capacity for predictable throughput and latency, billed per PTU per hour or through reservations. That makes PTU utilization, idle capacity, traffic predictability, and latency requirement visible design inputs rather than after-the-fact finance questions. Dashboard views that matter Start with a few durable views rather than a large reporting program. The most useful first version usually includes: Executive summary: deployment count, model families, regions, monthly cost trend, and quota risk. Inventory: deployments by subscription, resource group, region, model, version, deployment type, owner, and environment. Operations: request volume, token trends, errors, latency indicators, and PTU utilization where available. Cost allocation: spend by owning team, application, environment, and deployment type. Governance hygiene: missing tags, ownerless deployments, old model versions, and regional concentration. Decision guidance Choose the reporting surface by audience. Platform engineers usually need Workbooks because they support operational drill-down and can combine Azure Monitor and Resource Graph. Finance teams often need Power BI because it supports broader cost modeling and distribution. Application owners need a small scorecard: their deployments, their usage, their costs, their quota posture, and their next required action. Production considerations and limitations Require tags before reporting on ownership. Dashboards cannot create accountability if resources do not carry owner, application, environment, and cost-center metadata. Use least-privilege access. Cost, inventory, and telemetry sources may require different permissions and scopes. Check portal-version language. Some public monitoring guidance is explicitly marked for the Foundry classic portal, so avoid assuming identical behavior in every new portal experience. Verify regional availability. Model availability varies by region, and deployment lifecycle settings such as automatic model updates should be reviewed before making standardization claims. Respect metric export limits. Azure Monitor notes that some metrics have export constraints, especially around multidimensional metrics and diagnostic settings. Implementation checklist Define the dashboard audience and the decisions it must support. Inventory Foundry and Azure OpenAI resources across subscriptions with Azure Resource Graph. List deployments per account and normalize deployment metadata. Route or query Azure Monitor metrics and logs needed for usage and PTU views. Add Cost Management queries or exports at the correct billing scope. Join by resource ID and tags; flag missing ownership metadata. Publish an Azure Workbook for operations and a Power BI model only where agreement support and permissions fit. Review model versions, quota posture, and PTU utilization on a fixed cadence. Conclusion A tenant-wide model operations dashboard is a practical bridge between AI experimentation and AI platform management. It does not need to be complex on day one. Start with inventory, usage, cost, quota, and ownership. Keep application content out of scope. Preserve subscription-level quota detail. Then evolve the dashboard into a repeatable operating rhythm for model lifecycle, cost control, capacity planning, and governance.On the Next Fabric Engineering Connection
🚀 On the Next Fabric Engineering Connection: AMA with Amir Netz! Fresh from European Microsoft Fabric + SQL Community Conference with questions, feedback, or a few “wait, tell me more about that…” moments? 👀 The next Fabric Engineering Connection is the perfect place to bring them. 🎤 AMA (Ask Me Anything) with Amir Netz, Technical Fellow & CTO This is our first Quarterly AMA of FY27, and partners will have the opportunity to ask questions directly about: ✨ The announcements and product updates coming out of FabCon Europe 💡 What those updates mean for customers and partner practices 🧭 Fabric’s direction and where partners should be focusing 💬 Your own technical questions, feedback, and real-world customer scenarios One of the best parts of the Fabric Partner Community is getting this kind of direct access to the people shaping the product, so come ready with your questions! 📅 Americas & EMEA: Wednesday, October 21 | 8:00–9:00 AM PT 📅 APAC: Thursday, October 22 | 12:00–1:00 AM UTC 🔒 Fabric Engineering Connection is exclusively for members of the Fabric Partner Community. If you’re a Microsoft partner and haven't joined yet, this is a great reason to jump in. 👉 https://aka.ms/JoinFabricPartnerCommunity See you there. I have a feeling this is going to be a good one! 🔥This week on Fabric Engineering Connection
🚀 On the Next Fabric Engineering Connection: What’s New in OneLake There’s a lot happening in Microsoft OneLake, and this week we’re bringing the OneLake team directly to partners to unpack some of the latest capabilities across open data, security, APIs, and sharing. We’ll dig into: 🔐 OneLake Security updates, including lifecycle policies, resource instance rules, enhanced diagnostics, and simplified policy management 🤖 The new Read API, enabling governed access to OneLake data from applications and AI agents 🌐 Catalog federation, connecting Iceberg and Delta tables across AWS, Google, Databricks, and Snowflake 🤝 IQ Sharing, designed to securely share tables, files, and business context between enterprises and partners If you’re helping customers build secure, AI-ready, multi-cloud data architectures, this is one you’ll want on your calendar. 📅 Americas & EMEA: Wednesday, October 14 | 8:00–9:00 AM PT 📅 APAC: Thursday, October 15 | 12:00–1:00 AM UTC 🔒 Fabric Engineering Connection is exclusively for members of the Fabric Partner Community. If you’re a Microsoft partner and haven’t joined us yet, now’s a great time! 👉 https://aka.ms/JoinFabricPartnerCommunity Come ready with questions and hear directly from the team building what’s next for OneLake. 🚀Fabric and Databricks Together
Fabric and Azure Databricks overlap, but optimize different operating experiences. Fabric integrates OneLake, engineering, warehousing, real-time analytics, and Power BI as SaaS. Databricks combines Spark and SQL engineering, Unity Catalog, and a mature ML lifecycle. Delta Lake and ADLS Gen2 enable coexistence; Fabric metadata mirroring and OneLake shortcuts can expose Databricks tables without copying their files. The hard work is assigning ownership, security, compatibility, and service objectives at every handoff. Place workloads by operating responsibility Use Fabric where the product is a governed analytical experience—especially T-SQL marts, semantic models, Direct Lake, and Power BI. Use Databricks where the product is an engineering or ML execution system—especially complex Spark estates, feature engineering, training, and Unity Catalog-governed pipelines. Both can do more; this is a starting boundary, not an exclusivity rule. Add the second platform only when a clear handoff avoids duplicated work. A common brownfield pattern keeps Bronze, Silver, and Gold engineering in Databricks and mirrors selected, BI-ready Gold schemas to Fabric. Fabric then owns its SQL endpoint, semantic model, reports, and consumer permissions. Create a physical Fabric Gold copy only when it changes the contract: security minimization, star-schema reshaping, incompatible Delta features, source isolation, recoverable snapshots, or measured performance value. Use metadata mirroring with precise expectations The mirrored Azure Databricks catalog capability is GA. Fabric represents selected Unity Catalog metadata, creates a read-only SQL analytics endpoint, and reaches the existing Delta files through shortcuts; it does not replicate the table data or create a write path. Supported additions and deletions can appear from seconds to minutes, and endpoint synchronization adds another clock. Mirroring is analytical access, not event transport or a guaranteed-latency replication service. Treat prerequisites as security gates. Unity Catalog must be enabled; a metastore administrator must enable external data access, which is off by default. The connection principal needs explicit USE CATALOG, USE SCHEMA, SELECT, and EXTERNAL USE SCHEMA. EXTERNAL USE SCHEMA is not included in ALL PRIVILEGES or automatically granted to a schema owner. Use a non-personal identity, mirror the minimum useful Gold surface, and run post-deployment discovery, row-count or watermark, SQL, semantic, and deny-user probes. Keep security and catalog boundaries separate Unity Catalog permissions, row filters, column masks, and ABAC policies do not carry into Fabric. Configure Fabric workspace, item, and OneLake permissions independently, and map business-intent Entra groups into both systems. If required policy cannot be reproduced safely, publish a physically curated table whose rows and columns already satisfy the consumer contract. Preserve both lineage domains and record the handoff; public documentation does not promise automatic end-to-end stitching. For firewall-protected external ADLS Gen2, separate two identities. OAuth or a service principal authorizes Databricks and Unity Catalog discovery. Fabric Workspace Identity traverses the storage firewall through trusted workspace access and needs least-privilege data-plane authorization. Trusted workspace access is GA but requires F capacity, is unavailable on Trial, and uses an Azure Storage resource-instance rule. The documented path does not support generalizing mirroring to Databricks workspace storage behind a firewall. Make Delta and BI compatibility a release gate A shared Delta format is a contract, not universal compatibility. Test column mapping, deletion vectors, liquid clustering, type widening, protocol versions, names, and data types through every intended engine. The Fabric SQL analytics endpoint supports name-mode column mapping but not ID mode. Fabric Runtime 1.3 is GA; Runtime 2.0 is public preview with newer Spark and Delta versions. Pin producers and block unreviewed protocol upgrades. Direct Lake still requires semantic design, well-maintained tables, capacity, and concurrency testing. Verify grain, keys, relationships, measures, row-level security, file layout, framing after changes, cold and warm latency, and the selected Direct Lake mode. Zero-copy avoids one storage copy and replication pipeline; it does not eliminate Fabric capacity, source reads, producer compute, network, monitoring, or governance cost. Coexistence decision checklist One owner should accept each producer, consumer, network, security, semantic, incident, and cost contract. Deploy definitions, bind environment-specific connections, start the mirrored item, and verify runtime state; a successful pipeline deployment alone does not prove data is serving. Decision Production evidence Placement Primary platform and one-sentence handoff rationale; authoritative Gold contract named Security Least-privilege principals, firewall rule, Fabric policy mapping, allow and deny personas tested Data Runtime/protocol manifest; every engine passes schema evolution and feature tests Consumption SQL and Direct Lake readiness, semantic ownership, scale, concurrency, and fallback verified Operations Start/probe release steps, lag and failure telemetry, rollback, cost owner, and copy review date Conclusion Fabric and Databricks coexist cleanly when shared data does not blur platform boundaries. Start with a small set of curated Gold tables. Prove identity, denial, metadata freshness, Delta compatibility, Direct Lake behavior, monitoring, deployment, and rollback. Expand by owned data product, not catalog volume. The goal is to minimize duplicate work while giving every workload, policy, service objective, and bill a clear owner.FinOps for Data and AI Workloads
A VM-only review misses the unit economics of managed data and AI services. A useful review asks what it cost to produce one reliable outcome, then includes DBUs, capacity units, activity runs, integration-runtime compute, tokens, storage operations, data movement, and shared platform cost. Make spend attributable first; remove idle demand and unnecessary work; protect the service-level objective (SLO); and buy commitments only against a stable, measured baseline. FinOps is a continuous engineering loop, not a one-time savings exercise. Measure the complete workload Choose a denominator that reflects value: cost per successful pipeline run, terabyte promoted through a quality gate, business refresh, million events, or 1,000 accepted AI outcomes. Keep failed work, retries, and shared-cost allocation in the numerator. A lower hourly rate is a false saving if runtime doubles, freshness slips, quality falls, or spend moves to another team. Tag workload, owner, environment, product, region, and SLO class. Allocate shared Fabric capacity, Databricks compute, integration runtimes, monitoring, and networking directly when reliable telemetry exists; otherwise publish a transparent proxy and retain an unallocated bucket. Budgets notify rather than stop services, and cost data can lag, so pair budgets and anomaly alerts with operational telemetry and an owned triage process. Match the execution contract to demand For Azure Databricks, keep interactive exploration separate from scheduled jobs. Enforce auto-termination, tested VM families, practical autoscaling ranges, and required allocation tags. Compute policies are GA but require the Premium plan; lowering a policy limit does not retroactively terminate existing resources. Benchmark Photon, pools, spot capacity, and serverless on real workloads. Small files and poor clustering turn storage design into compute spend; predictive optimization is GA for eligible Unity Catalog managed tables, while VACUUM LITE remains Public Preview and needs an explicit preview exception. Azure Data Factory meters orchestration, copy DIU-hours, data-flow execution and debug, and integration-runtime choices. Fabric Data Factory is GA and consumes capacity units, with OneLake storage considered separately. Prefer incremental movement, stop debug sessions, consolidate tiny activities only when retry and ownership boundaries remain clear, and count retry cost per successful run. For ADLS Gen2, model capacity, read/write/list operations, tier transitions, retrieval, redundancy, retention penalties, and transfer. Cool, cold, and archive economics include minimum residence periods; archive is offline and rehydration can take hours. A lifecycle rule is not valid until restore, legal-hold, retention, and recovery objectives still pass. Right-size shared capacity and AI requests Fabric capacity must be managed at the timepoint and workspace level. Bursting and smoothing can consume future capacity, so monthly averages can hide interactive delays and throttling. Use the Capacity Metrics app with workload telemetry; isolate incompatible demand and pause nonproduction F capacity only after checking queued work and smoothed usage. Spark Autoscale Billing is a separate pay-as-you-go behavior, not part of bursting and smoothing. For Foundry model deployments, compare Standard, priority processing, provisioned throughput, and Global Batch against the request shape. Provisioned throughput and Global Batch are GA where supported, but PTU quota does not guarantee capacity, and model, region, minimum, and reservation constraints apply. Use the smallest model that passes task-specific quality and safety tests; cap output and retries; batch asynchronous work; and meter search, storage, code, functions, and observability separately from tokens. Protect performance with controlled experiments State the expected meter reduction and freeze the comparison boundary: demand, data volume, model or runtime version, region, quality checks, and SLO. Record baseline cost, latency, freshness, failures, retries, and allocation. Change one major lever where practical, canary it, observe a representative peak and business cycle, and accept or roll back using both cost and SLO evidence. Map the actual network path; private endpoints improve isolation but add DNS, topology, and processing considerations and do not make every cross-region transfer free. Operate on a regular rhythm: triage material anomalies daily, review idle and unallocated spend weekly, assess unit-cost and SLO evidence monthly, and revisit lifecycle, recovery, and commitments quarterly. Re-baseline after a model, runtime, capacity, region, retention, redundancy, or architecture change. This prevents an optimization that was valid for yesterday’s workload from becoming today’s reliability defect. Production decision checklist Commitments come last. Recheck current prices, status, region, quota, networking, and reservation terms at implementation time; none should be copied as a timeless constant. Gate Required evidence Ownership Workload, owner, denominator, SLO, and at least 95% allocation coverage Demand Idle time, retries, execution mode, file/request shape, and peak behavior measured Guardrail Quality, p95 latency, freshness, recovery, and rollback thresholds pass Status GA/Preview, plan, region, quota, capacity, and fallback recorded Commitment Only the post-optimization stable floor is reserved; renewal owner named Conclusion Durable FinOps joins the meter, owner, useful outcome, and SLO in one evidence chain. Start with visibility and allocation, choose the right execution model, remove waste, improve data and request shape, and right-size from peaks rather than averages. Apply rate optimization only afterward, then repeat whenever demand, architecture, model, region, or service behavior changes.Governance Boundaries in Microsoft Foundry
Microsoft Foundry governance works best when teams separate broad Azure controls from Foundry resource controls, project access, model deployment configuration, and agent endpoint permissions. This article provides a practical boundary map for production decisions, with public references and a checklist for implementation. Use Azure subscription and resource group scope for enterprise-wide policy, allowed regions, tagging, budgets, and inherited access. Use the Foundry resource as the administrative, security, networking, monitoring, and shared deployment boundary. Use projects for team and workload organization, not as the only place to enforce enterprise controls. Use model deployments to govern runtime model version, deployment type, capacity, filters, and rate behavior. Use agent-scope access for narrow endpoint consumption, and prefer Microsoft Entra ID over API keys for production. Why this matters Microsoft Foundry is becoming the shared place where teams build agents, deploy models, connect tools, evaluate behavior, and operate AI systems. That consolidation is useful, but it also creates a practical governance question: should a control live at the Azure subscription, the Foundry resource, the project, the model deployment, or the agent endpoint? The answer matters because each boundary enforces a different kind of decision. A five-boundary mental model Start with the broadest boundary and move inward. The subscription or resource group is where enterprise Azure governance usually begins: allowed regions, required tags, cost grouping, resource locks, inherited role assignments, and Azure Policy initiatives. The Foundry resource is the administrative and security boundary for a Foundry environment. Microsoft describes it as the single management plane for agents, models, and tools, with unified RBAC, networking, and policies. Separate control plane from data plane The cleanest design conversations separate management actions from runtime actions. Control-plane decisions include creating resources and projects, assigning roles, configuring networking, creating connections, and deploying models. Data-plane activity includes inference, agent interaction, evaluation jobs, content safety calls, tracing, and monitoring. A role or lock that protects a resource from deletion does not automatically govern every runtime action. Production governance should deliberately combine Azure RBAC, Foundry RBAC, Azure Policy, network controls, deployment settings, and application logic. RBAC guidance Use Microsoft Entra ID for production wherever possible. Microsoft states that API keys are convenient for prototyping but coarse-grained, hard to audit per user, and not recommended for production least-privilege scenarios. Foundry roles are designed for Foundry-specific workflows: for example, builders, project managers, account owners, and agent consumers. Azure roles still matter for subscription, resource group, and role-assignment authority. Be conservative: check the current role table for the exact operation because model deployment, project building, agent publishing, and inference can use different permission surfaces. Deployment governance is runtime governance A model deployment is not just a model choice. It is where runtime posture becomes concrete. Deployment type affects where inferencing data can be processed: Global deployments may process in any Azure region, Data Zone deployments keep processing within the Microsoft-specified US, EU, or APAC data zone, and Standard deployments process in the deployment region. That makes deployment type a compliance and architecture decision, not only a performance or price decision. Policy, preview, and availability Azure Policy can enforce or audit important Foundry-adjacent requirements, including key access, customer-managed keys, private link, network restrictions, managed identity, model eligibility, and content filtering. Several AI/model-specific policy definitions are marked Preview, so treat them as promising controls rather than production defaults unless your organization accepts preview terms. Foundry also documents a tag to hide preview surfaces and custom RBAC patterns to block selected preview operations. Recommended operating pattern Use resource groups and subscriptions for enterprise policy, cost, and environment separation. Use separate Foundry resources when environments need different networking, keys, quotas, or administrative ownership. Use projects for team and workload separation inside a governed resource. Use model deployments to isolate runtime configuration, model version, data-processing posture, filters, and capacity. Use agent-scope access only when a consumer needs one agent endpoint, not the whole project. Prefer Entra ID and managed identities, and disable or tightly govern local key access where production controls require it. Decision guide Production checklist Which boundary owns this control: Azure scope, Foundry resource, project, deployment, or agent endpoint? Is the action control plane or data plane? Is the model or feature generally available or Preview? Where can inferencing data be processed for the chosen deployment type? Which role grants only the needed permission at the narrowest useful scope? Is enforcement handled by RBAC, Azure Policy, network isolation, deployment configuration, or application code? Have region, quota, model availability, dependent services, Marketplace terms, and cloud environment been verified? Conclusion Governance in Microsoft Foundry is not a single switch. It is a layered design. Put enterprise constraints at Azure scope, shared platform controls at the Foundry resource, team workflows in projects, runtime posture in deployments, and consumer permissions at the agent endpoint. That separation keeps governance understandable, auditable, and easier to change as models, regions, deployment types, and platform features evolve.Identity at Every Hop
Use delegated On-Behalf-Of access only when a downstream service must enforce the signed-in user's permissions. Use a managed or agent identity for unattended work. At every hop, obtain a token for the intended audience instead of forwarding one issued for another service. Model every hop as a boundary A Teams request can involve a user, Teams app or bot, application backend, Foundry project or agent, MCP server, and protected API. Each component may use a different principal, token audience, permission model, and consent boundary. Decide whose authority each downstream resource should evaluate, then grant that principal only the required access. For a Teams tab, getAuthToken() returns a JWT whose audience is the application's client ID. Send it to the backend over HTTPS and validate signature, issuer, audience, expiry, and tenant. It is not a general-purpose Microsoft Graph token. Bot SSO uses the Bot Framework token service; documented SSO supports one-to-one and group chats, not channel scope. Do not authorize from a display name, email, or client-parsed claim. The backend must establish the trusted principal first, then apply application authorization. Teams SSO gets identity into the application; it does not grant automatic access to Foundry, a tool, Graph, or business data. Exchange tokens when user authority must travel OAuth 2.0 OBO is for a middle-tier API calling another API under a signed-in user's delegated authority. The backend validates Token A, authenticates as a confidential client, and exchanges Token A at the tenant-specific Entra endpoint. Entra returns Token B for the downstream audience and scopes. Present Token B only to that resource. OBO requires a user principal and delegated scopes. An app-only token cannot be used as the OBO assertion; use client credentials or managed identity when no user is present. Never relay the backend token to Graph, MCP, or another API. Relay breaks audience enforcement and can conflict with Conditional Access. Surface interaction-required claims challenges back to the client instead of hiding them as generic server failures. Assign the correct Foundry identity An agent identity is a specialized Entra service principal. Unpublished agents share a project-level development identity; publishing creates a distinct production agent identity. Permissions do not transfer automatically, so assign downstream roles to the published identity. At runtime, Agent Service obtains a scoped token for the target service; the audience is that service's resource identifier, not necessarily the MCP endpoint URL. Apply Foundry RBAC at the narrowest useful scope. Foundry Agent Consumer is for invocation, Foundry User is for building and testing, and Foundry Project Manager supports project management and publishing. Prefer Entra authentication: resource keys provide coarse access and bypass these role distinctions. Role names may still appear under older Azure AI labels during rollout. Treat MCP authorization as an explicit design MCP defines tool discovery and invocation; it does not make a server trusted. For remote servers, choose no authentication only for intentionally public services. Otherwise use custom keys, custom OAuth, a user Entra token, project managed identity, or agent identity according to who must be authorized. A configured connection does not grant downstream permission by itself. Toolbox can centralize credential injection, refresh, versioning, and policy behind an MCP-compatible endpoint. Allow-list required tools, require approval for risky writes, and log tool names, authorization outcomes, and approvals without logging tokens. Prefer managed identities or federated credentials to stored secrets. For user-owned mail, files, or other delegated resources, choose supported user passthrough or OBO. For background jobs, use workload identity. When every published agent needs distinct permissions and audit, use its distinct agent identity. Use project managed identity only when all agents in that project should share the same Azure access after explicit risk review. Practical identity checklist Multitenant sign-in does not make every downstream exchange cross-tenant. Customer consent creates a service principal in the customer tenant, but Foundry's built-in OAuth identity passthrough requires the user's tenant to match the Foundry project tenant. Define tenant placement, administrator consent, issuer validation, and offboarding; use a validated custom OAuth design when built-in passthrough cannot meet the requirement. Troubleshoot from the resource that rejected the request. A 401 usually points to a missing, expired, malformed, or wrong-audience token. A 403 usually means the identity is recognized but lacks permission, although service firewalls can also return 403. DNS failures, TCP timeouts, and private-endpoint routing errors are not repaired by adding RBAC. Question Production decision Whose authority? User: delegated OBO. Workload: managed or agent identity. Correct token? Validate issuer, audience, tenant, lifetime, scopes, and claims. Correct principal? Reassign target RBAC after publishing creates a new identity. Tool governance? Allow-list tools; approve side effects; broker shared credentials. Cross-tenant? Design consent and offboarding; built-in passthrough requires matching user and Foundry tenants. Failure class? Separate 401, 403, consent, DNS, firewall, routing, and timeout evidence. Conclusion Design identity before connecting tools. Ask who the downstream service should authorize, exchange tokens for the correct audience, and scope RBAC to the resulting principal. Validate consent, renewal, revocation, tool approval, and network reachability one hop at a time.
The hardest part of modernizing enterprise BI is NOT the dashboard
For my team, a whole lotta enterprise BI modernization discussions start with the visualization layer, mostly around: Which dashboard should be rebuilt? Should the reports use Direct Lake? Should the organization move to a Lakehouse? How should Power BI capacity be configured? Those are important questions, but there is another one that tends to surface later: Where should the business logic live? In a multi-source environment, the same KPI can be derived from SAP, operational systems, spreadsheets, or application databases. If each report implements the calculation independently, moving the data into a modern platform doesn't automatically create consistent reporting. A more maintainable pattern is to separate the responsibilities: Ingestion: bring source data into the platform with appropriate batch or event-based patterns. Transformation: clean, conform, and standardize data before it reaches reporting. Business layer: define reusable measures and business rules in the semantic model. Security: apply access rules at the appropriate data or semantic layer rather than duplicating them across individual reports. Visualization: keep reports focused on analysis and user experience rather than embedding large amounts of transformation logic. Microsoft Fabric, in that same environment, makes it feasible to bring several of these capabilities into one unified platform, but the architecture still needs clear boundaries between them. I have found this distinction especially important when upgrading reporting environments that have accumulated years of spreadsheet logic and report-specific calculations. For those working on enterprise BI modernization, where do you draw the line between data transformation logic and semantic-model/business logic? And what has worked best for keeping KPI definitions consistent across multiple Power BI reports?On the Next Fabric Engineering Connection
Fresh off European Microsoft Fabric + SQL Community Conference, we're kicking off the next chapter of Fabric Engineering Connection with a session focused on one of the biggest opportunities for partners helping customers modernize their data estates and embrace AI-powered development. 🎤 Upgrade to Fabric Data Factory: Your Path to a Unified, AI-Ready Data Integration Experience Presented by: Mark Kromer — Lead Principal PM Manager Sindhu Bharadwaj — Senior Product Manager Join us to learn how Microsoft is helping Azure Data Factory customers discover, assess, and upgrade their existing investments into Fabric through a phased modernization journey. You'll also get a look at emerging AI-powered experiences that are transforming how developers build and manage data integration solutions, including: ✅ Skills for Fabric ✅ Model Context Protocol (MCP) ✅ GitHub Copilot ✅ VS Code integration Whether you're guiding customers through migration decisions, modernizing integration workloads, or exploring how AI can accelerate developer productivity, this is a session you won't want to miss. 🗓️ Live call times Americas & EMEA: Wednesday, October 7 | 8:00–9:00 AM PT APAC: Thursday, October 8 | 12:00–1:00 AM UTC 🔒 Fabric Engineering Connection is hosted exclusively in the Fabric Partner Community. Microsoft partners can join at https://aka.ms/JoinFabricPartnerCommunity Looking forward to another great discussion and keeping the post‑FabCon momentum going! 🚀🔥
