Azure News - 2026-09-18

Business Scenario

A retail organization runs multiple promotional sales events across its store network in different cities, featuring various product categories.

Data is captured from:

• Third-party systems (products, stores, sales events)
• ERP system i.e. Finance and Operations (customer data)

Customers are linked to stores based on city in the ERP system, and each store hosts specific sales events.

However, while significant investments are made in marketing campaigns, inventory allocation, and event planning, the organization needs to identify

• Which stores generate the highest revenue during events
• Which locations are having majority of customer footprint

Solution:

Rather than creating custom reports on raw data, an agent can leverage the data in Onelake and use Fabric semantic models and Fabric IQ to provide conversational analytics. The agent can intelligently normalize user inputs and return accurate results even when values such as city names are entered with spelling errors or variations.

Advantage:

Because the data comes from two disconnected worlds (third-party systems for products/stores/events, ERP for customers), the "join" between them — customer → city → store → event → product — is business logic, not a database key. Fabric Ontology captures exactly that: entity types, relationships, rules and source mappings, so agents don't have to rediscover it from raw tables each time.

A. Prerequisite:

Data Sources & Relationships Overview

• Product, store, and sales event data are sourced from third-party systems.
• Customer data is sourced from the ERP (Dynamics 365 Finance & Operations) system through Fabric lakehouse.

How the data is connected:

• Customers are linked to stores based on city alignment (customer city = store location).
• Sales events are associated with:
• The products being sold, and
• The stores where the events are conducted.

Licenses and access requirement:

B. Step by step configuration: 

1. Push the data to OneLake : Connect D365 F&O customer data to Fabric Lakehouse through PowerPlatform

Ref: Link your Dataverse environment to Microsoft Fabric and unlock deep insights - Power Apps | Microsoft Learn

2. A Lake house will be created in Fabric with the data

3. Ingest the Data for Store , Sales event and Product from third party system to Fabric using any of the methods as outlined in the documentation below (as relevant)

Ref: https://learn.microsoft.com/en-us/fabric/data-engineering/load-data-lakehouse

4. Create a semantic model and relationship between them

Ref: https://learn.microsoft.com/en-us/fabric/data-engineering/tutorial-lakehouse-build-report

5. Create Ontology using the semantic model

Ref: https://learn.microsoft.com/en-us/fabric/iq/ontology/concepts-generate

 Ref: Create an Ontology with Fabric IQ - Training | Microsoft Learn

Click on View entity type details > click on manage relationship > click on the relation

Configure the source and target entity names and connected fields. Repeat similar setup for others as relevant

6. Login to https://copilotstudio.preview.microsoft.com/ and Create Copilot studio agent with following instruction:

When processing a user query:

1. Determine whether the user input contains a city name, location name, region, state, or geographical reference.
2. If a location reference is detected:

o   Identify potential spelling mistakes, abbreviations, alternate spellings, phonetic variations, or non-standard user input using the  <<custom prompt>>.

o   Normalize the value to the most likely official city name used in the enterprise data model.

o   Examples:

• "Bombay" → "Mumbai"
• "NYC" → "New York"

3. Use only the normalized location value when querying Fabric IQ.
4. If confidence in the normalization is high, proceed automatically without asking the user for confirmation.
5. If multiple cities are equally likely matches, ask a clarifying question before querying Fabric IQ.
6. When invoking Fabric IQ MCP:

o   Replace the original user-entered city value with the normalized city value.

o   Use the normalized value consistently across all ontology searches and filters.

7. Never expose the internal normalization process unless the user explicitly asks how the result was determined.
8. Return the business result based on data retrieved from Fabric IQ, not based on assumptions.

Example: User: "Show sales for Bangaluru last quarter" Normalized City: "Bengaluru" Fabric IQ Query: "Show sales for Bengaluru last quarter"

7. Add Fabric IQ MCP tool

Click on Fabric IQ MCP and provide workspace ID and Ontology ID as retrieved from the Ontology URL in Fabric

To find the URL, follow these steps:

• Open your ontology item in Fabric.
• View the URL in the browser, in the format https://app.fabric.microsoft.com/groups/<workspace-ID>/ontologies/<ontology-item-ID>.
• Copy the values of <workspace-ID> and <ontology-item-ID> from the URL.

• Form the MCP server URL by entering the copied values into this string: https://api.fabric.microsoft.com/v1/mcp/dataPlane/workspaces/<workspace-ID>/items/<ontology-item-ID>/ontologyEndpoint.You use this MCP server URL in the next section
• Following figures explains the details once the process

     Ref: https://learn.microsoft.com/en-us/fabric/iq/ontology/how-to-create-agent-copilot-studio

8. Add a tool Prompt to ensure normalised search for any user input (e.g. City)

Put the following instruction in a custom prompt :

You are a location normalization expert.

 Your task is to identify the most likely city name from the user's input, even when:

- The city name contains spelling mistakes.

- The city name is partially entered.

- The city is entered using an old or alternate name.

- The city contains abbreviations or phonetic spellings.

Rules:

1. Determine the most likely official city name.
2. Correct spelling mistakes using geographic knowledge.
3. Expand abbreviations where appropriate.
4. Return only the normalized city name.
5. If confidence is below 80%, return "AMBIGUOUS".
6. Never invent a city when multiple equally likely matches exist.

 Examples:

 Input: Banglore

Output: Bengaluru 

Input: Mumbi

Output: Mumbai

Input: BNG

Output: Bengaluru 

Input: Londn

Output: London 

City input: {{CityName}}

Output format:

{

"normalizedCity": "Bengaluru",

"confidence": 0.95

}

9. Test the agent

• Open the Test pane using the Test button in the top right corner of the screen. Enter NL query
• Allow the MCP tool when prompted

Test case 1: What is the top product revenue across all stores?

Test case 2: Intelligent Location Normalization with Fabric IQ

When a user submits a query such as "Compare the customer footfall between city Blr and Hyd", the agent first applies an AI-powered normalization layer before querying enterprise data.

The normalization prompt analyses abbreviations, alternate spellings, phonetic variations, and non-standard location references, mapping them to their canonical business values. In this example:

Blr → Bengaluru (Bangalore)

Hyd → Hyderabad

The normalized city names are then passed to Fabric IQ for semantic retrieval against the ontology and underlying data sources. This approach improves query accuracy, reduces dependency on exact user input, and enables a more natural conversational experience while ensuring consistent reporting and analytics results.

Process Flow :

User Query

 → AI Prompt Normalization

 → Canonical City Resolution (Bengaluru, Hyderabad)

 → Fabric IQ Semantic Search

 → Data Retrieval & Comparison Results

Business Scenario

A retail organization runs multiple promotional sales events across its store network in different cities, featuring various product categories where Data is captured from third-party systems (products, stores, sales events) and D365 Finance and Operations (customer data)

Customers are linked to stores based on city, and each store hosts specific sales events.

To figure out the store generating highest revenue, store event driving the best outcome, majority customer footprint, the organization has implemented copilot studio agent using Fabric IQ, Ontology and ERP MCP.

New Business Challenge

Beyond understanding past performance, the retailer wants the system to answer:

• Are there procurement risks impacting promotional sales?
• Which cities should receive additional marketing spend?

Solution

Create a foundry agent using Foundry IQ including Fabric IQ, Web IQ, Web IQ as knowledge source.

Foundry IQ is not the source of data. Its primary role is the reasoning, orchestration, and decision-making layer that connects insights from Fabric IQ, Work IQ, and Web IQ , sharepoint, blob, custom agents etc and generates business recommendations. It is backed by Azure AI search to get an indexed search with accurate result.

A. Prerequisite:

Data Sources & Relationships Overview

• Product, store, and sales event data are sourced from third-party systems .
• Customer data is sourced from the ERP (Dynamics 365 Finance & Operations) system through Fabric.

How the data is connected:

• Customers are linked to stores based on city alignment (customer city = store location).
• Sales events are associated with:

o   The products being sold, and

o   The stores where the events are conducted.

• Country specific marketing policy documents stored in sharepoint

• WebIQ Setup for getting real time information from web (Web IQ is the key enabler for the supplier-news scenario. It can help with Real-time supplier news, market disruptions, geopolitical events, regulatory changes, competitor activity)

Ref: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/web-iq

• Finance and Operations data connected toFabric Lakehouse

Ref: Link your Dataverse environment to Microsoft Fabric and unlock deep insights - Power Apps | Microsoft Learn

• Store, event , Product data ingested to lakehouse using any of the methods as outlined in the documentation below

Ref: https://learn.microsoft.com/en-us/fabric/data-engineering/load-data-lakehouse

• Fabric Ontology created combining the F&O customer, store, product and event data (sample screenshot below)

• A Microsoft Foundry project with an LLM deployment, such as gpt-4.1-mini.
• Authentication and permissions on your search service and project.

B. Architecture Pattern

C. Step by Step Configuration 

1. Goto Azure portal and add a search service (as that runs in the background of foundry IQ for an indexed search)

Ref: https://learn.microsoft.com/en-us/azure/search/search-create-service-portal

2. Goto Azure foundry portal (https://ai.azure.com/) and add an agent with ERP MCP as a tool:

3. Goto knowledge (Foundry IQ) and select the AI Search

4. Create a knowledgebase and add the following options: Fabric IQ , Web , SharePoint. Use the knowledge base for the Retail growth Intelligence agent

5. Working with the agent

The agent can be published in the channel of choice (M365, teams, copilot studio using A2A  etc).

Ref: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/publish-copilot

The question "Are there procurement timeline or any other risks impacting promotional sales?"

is exactly the type of cross-domain reasoning scenario where the agent combines:

• Fabric IQ Ontology → understands relationships between Store, Product, SaleEvent, Customer.
• F&O ERP MCP → retrieves operational procurement data such as PO status, Confirmed Delivery Date, Vendor performance, Inventory levels.
• SharePoint Policy Repository → validates country-specific marketing investment rules and campaign approval constraints.
• Foundry IQ/Web Intelligence (if enabled) → checks supplier news, disruptions, external market events.

D. Conclusion

The approach transforms disconnected operational and market information into a unified decision-support experience using the process flow as: Business Question → Understand Context → Retrieve Live ERP Data → Validate Policies → Check External Risks → Correlate Insights → Recommend Business Action

It is helping business stakeholders to take proactive, AI-driven decisions ensuring the following business advantage

• Faster decisions: reduces manual reconciliation across multiple systems and documents.
• Higher-quality recommendations: connects operational facts with business context and external signals.
• Scalable access: makes cross-domain intelligence available through a reusable, conversational agent.
• Proactive risk detection identifies supply, inventory, policy, and market risks before promotions are affected

Solution at a glance 
Source image  →  Packer build  →  Azure Compute Gallery  →  Validation VM  →  Evidence  →  Controlled promotion 

Introduction 

Maintaining enterprise virtual machine images manually can lead to configuration drift, inconsistent builds, slow remediation and limited release traceability. A stronger pattern is to treat each image as a versioned build artefact: create it from a controlled source, configure it deterministically, validate the published image and promote only an explicitly identified version. 

This article presents a generic implementation using HashiCorp Packer and Azure DevOps. The examples intentionally use non-production placeholders and avoid customer-specific names, subscriptions, networks, credentials, repositories, gallery names, certificate material, package sources and internal promotion topology. 

What this article demonstrates 

• Consolidate a layered image process into a parameterised Packer build. 

• Preserve image metadata and Azure Marketplace lineage through publication. 

• Validate the published image version rather than only the temporary build VM. 

• Publish validation evidence and make promotion decisions traceable. 

Solution overview 

Reference architecture 

The pipeline separates image creation, validation, security scanning and promotion. This separation makes each release decision explicit and preserves evidence for the exact image version that downstream workloads consume. 

Azure DevOps  Orchestration

Packer  Image build

Compute Gallery  Versioned artefact

Validation VM  Runtime checks

Release gate  Promotion

Important  A successful Packer build proves that the build completed. It does not prove that the published gallery image behaves correctly when consumed. Validate the published version independently. 

Designing the image build 

Why use a single reproducible build? 

Layered pipelines can be useful, but multiple sequential image builds create intermediate artefacts and dependencies that complicate remediation. Where the complete configuration can be reproduced from source, use one ordered flow: select the source image, configure the operating system, apply the chosen hardening profile, install the runtime, configure trust, run smoke checks, clean up and capture the result. 

Parameterise the pipeline 

Keep environment-specific values outside the reusable image logic. Typical queue-time parameters include runtime version, image flavour, build region, optional security scanning and the image version to validate. 

Queue-time pipeline parameters (YAML) 

Define the Packer builder and provisioning order 

Use a single template with an explicit provisioning sequence. Fail the build for conditions that make the image unusable; keep advisory checks separate when the release process intentionally treats them as non-blocking

Generic Azure builder and inputs (HCL) 

variable "location" { type = string } variable "image_name" { type = string } variable "image_version" { type = string } variable "runtime_version" { type = string } variable "image_flavour" { type = string }

source "azure-arm" "base" { use_azure_cli_auth = true location = var.location os_type = "Linux" vm_size = "Standard_D4s_v5" image_publisher = "RedHat" image_offer = "RHEL" image_sku = "8-lvm-gen2" image_version = "latest" managed_image_resource_group_name = "rg-image-build" managed_image_name = "${var.image_name}-${var.image_version}" }

Deterministic provisioning sequence (HCL)

provisioner "shell" { script = "scripts/os-update.sh" } provisioner "shell" { script = "scripts/configure-system.sh" } provisioner "shell" { environment_vars = [ "RUNTIME_VERSION=${var.runtime_version}", "IMAGE_FLAVOUR=${var.image_flavour}" ] script = "scripts/install-runtime.sh" } provisioner "shell" { script = "scripts/configure-trust.sh" } provisioner "shell" { script = "scripts/image-smoke-test.sh" } provisioner "shell" { script = "scripts/image-cleanup.sh" } }

Authentication  Use Azure DevOps service connections or workload identity. Do not place client secrets in Packer templates or ordinary YAML parameters, and do not write sensitive values to logs or image artefacts. 

Marketplace lineage  When the selected source image includes purchase-plan metadata, preserve the required plan information and verify the gallery definition before promotion. 

Version images independently 

Maintain a separate incrementing version stream for each runtime and image-flavour combination. This keeps versions meaningful within the corresponding image definition. 

Version key concept 

Validate the published image 

After publication, deploy a temporary VM from the exact gallery image version, run validation remotely, publish the results and always remove temporary resources. 

Create and validate a VM from the published version (YAML) 

Validation coverage 

• Operating-system baseline and expected distribution/version. 

• Runtime version and required environment variables. 

• Required packages, services and cloud-agent readiness. 

• Truststore existence and basic integrity. 

• Expected hardening state for the selected image flavour. 

Minimal in-guest validation script (Bash) 

check() { local name="$1"; shift if "$@"; then printf '%s\tPASS\n' "$name" | tee -a "$report_dir/result.txt" else printf '%s\tFAIL\n' "$name" | tee -a "$report_dir/result.txt" return 1 fi }

check os-baseline grep -q '^ID="rhel"' /etc/os-release check runtime-version java -version check java-home test -n "${JAVA_HOME:-}" check truststore test -s "${JAVA_HOME}/lib/security/cacerts" check cloud-agent systemctl is-active --quiet waagent

Publish evidence and enforce the gate 

• bash: jq -e '.result == "PASS"' validation-results/result.json displayName: Enforce validation gate

The report should identify the image definition and version and provide an explicit result for every check. Correlate build logs, validation artefacts, scan outputs and promotion records with the pipeline run.

Promotion and release controls 

Bake once, then promote the same identified image version rather than rebuilding independently for each environment. If validation or scanning is required for a production release, represent that requirement as a pipeline dependency or approval gate. 

Promotion dependency and approval boundary (YAML) 

Failure handling and clean-up 

• Revoke temporary disk access before deleting staging resources. 

• Use the pipeline run or image version in temporary resource names. 

• Do not overwrite a successfully published image version. 

• Define retention for gallery versions and capture intermediates. 

• Rollback by directing new deployments to a previous known-good version. 

Production considerations 

Release gates 

Stable validation contract 

Use a small, predictable report schema so the pipeline, release approvers and downstream automation interpret the same top-level result. 

Example validation report (JSON) 

Operational checklist 

• Verify source-image terms and permissions before each bake. 

• Pin Packer and plug-in versions; test upgrades deliberately. 

• Give build and promotion identities only the scopes they require. 

• Confirm validation targets the same subscription, gallery, definition and version produced by the build. 

• Define promotion, retention, retry, notification and ownership policies before production handover. 

• Keep a build summary, validation report, scan output, promotion record and cleanup record for each released version. 

Consumer rollout 

The image pipeline ends at a versioned, validated gallery artefact. Consumers such as Virtual Machine Scale Sets should reference an explicit version during controlled rollout, validate health after deployment and move new deployments to a previous known-good version when rollback is required. 

Conclusion 

Image baking becomes easier to operate when it is treated as a software-delivery problem: source-controlled configuration, deterministic builds, explicit metadata, versioned outputs, independent validation, published evidence and controlled promotion. Packer supplies the repeatable image build, Azure DevOps supplies orchestration and governance, and Azure Compute Gallery supplies the distribution boundary. 

The most important addition is validating the image after publication so release decisions are based on the same artefact that downstream workloads will consume. 

Adapt before use  The examples are intentionally generic. Replace placeholder names and policy thresholds for the target environment; keep secrets in protected variables or an approved secret store. 

References 

• Azure Pipelines runtime parameters: https://learn.microsoft.com/azure/devops/pipelines/process/runtime-parameters 

• HashiCorp Packer Azure ARM builder: https://learn.microsoft.com/azure/devops/pipelines/process/runtime-parameters

• Create Linux Azure VM images with Packer: https://learn.microsoft.com/azure/devops/pipelines/process/runtime-parameters

• Azure Infrastructure Blog: https://learn.microsoft.com/azure/devops/pipelines/process/runtime-parameters

• Deploying custom images and implementing CI/CD for Azure Virtual Machine Scale Sets: https://techcommunity.microsoft.com/blog/azureinfrastructureblog/deploying-custom-images-and-implementing-cicd-for-azure-virtual-machine-scale-se/4556902