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.

Problem statement

Azure Private Endpoints let applications connect to Azure platform services through private IP addresses. They reduce public exposure, keep traffic on private networks, and support a Zero Trust architecture.

In a single Microsoft Entra tenant, Azure Policy can automatically associate a Private Endpoint with a centrally managed Private DNS zone. The problem becomes more complex when an organization uses several tenants:

• A central management tenant owns the shared Private DNS zones.
• Separate application tenants host workloads and Private Endpoints.
• Application teams cannot modify resources in the central networking subscription.
• DNS records must be created and removed automatically as Private Endpoints are created and deleted.
• Cross-tenant access must be limited, auditable, and free from long-lived shared credentials.

When an application creates a Private Endpoint, Azure must create a privateDnsZoneGroup and register an A record in the appropriate Private DNS zone. However, the Azure Policy identity in the application tenant cannot update a DNS zone in the central tenant unless it receives explicitly delegated access.

Application tenant                         Central management tenant
------------------                         -------------------------
Application workload
        |
Private Endpoint
        |
Azure Policy
        |
Policy managed identity
        |          Cross-tenant delegation
        +------------------------------------> Central Private DNS zone
                                                  |
                                                  +-- Private A record

Why not use a custom synchronization service?

A central pipeline or Azure Function could copy DNS records between tenants. That approach can work, but it introduces more credentials, custom code, retry and reconciliation logic, monitoring, hosting costs, and record-cleanup responsibilities.

An Azure-native alternative is to combine Azure Policy with a carefully scoped Azure Lighthouse delegation. Azure Policy controls the Private Endpoint DNS lifecycle, while Azure Lighthouse gives its managed identity only the access required to work with the dedicated central DNS resource group.

Note: This article describes a proposed design assembled from publicly documented Azure capabilities; it is not an official Microsoft reference architecture or a claim of production implementation. Validate it through security review, threat modeling, and a non-production proof of concept before use.

Azure resources used in the solution

Azure Private Endpoint

A Private Endpoint is a network interface with a private IP address from a virtual network. It provides private connectivity to an Azure service such as Storage, Key Vault, or Azure SQL.

Azure Private DNS Zone

A Private DNS zone resolves an Azure service name to the private IP address of its Private Endpoint. Hosting these zones centrally gives the platform team consistent ownership and allows cloud and on-premises networks to use a common DNS resolution path.

Private DNS zone group

A privateDnsZoneGroup is a child resource of a Private Endpoint. It associates the endpoint with one or more Private DNS zones. Azure then creates and removes the relevant DNS records as part of the endpoint lifecycle.

Azure Policy

A DeployIfNotExists policy detects a supported Private Endpoint and deploys the required DNS zone group when it is missing. Policy parameters identify the correct central zone for each Azure service and private-link group ID.

User-assigned managed identity

A dedicated identity in each application tenant performs policy remediation. Unlike a stored service-principal secret, a managed identity has no credential that operators need to rotate or distribute. A user-assigned identity also has a stable principal ID and an independent lifecycle.

Azure Lighthouse

Azure Lighthouse provides delegated resource management across Entra tenants. In this design, an application-tenant identity receives narrowly scoped access to DNS resources in the central tenant. In Azure Lighthouse terminology, the application tenant is the managing tenant for this specific delegation, while the central tenant owns the delegated resource group.

Terraform and GitHub Actions

Terraform creates the Lighthouse registration definition and assignment consistently for every tenant. GitHub Actions runs validation, planning, approval, and deployment. OpenID Connect workload identity federation should be used instead of a long-lived client secret.

Proposed solution

The solution gives each application tenant a dedicated policy identity and delegates that identity the Private DNS Zone Contributor role over only the required central DNS scope.

+---------------- Application tenant ----------------+
|                                                     |
|  Workload --> Private Endpoint                      |
|                    |                                |
|            DeployIfNotExists Policy                 |
|                    |                                |
|          User-assigned managed identity             |
+--------------------|--------------------------------+
                     | Azure Lighthouse delegation
                     | Private DNS Zone Contributor
+--------------------v--------------------------------+
|              Central management tenant              |
|                                                     |
|  Central Private DNS zones -- DNS resolution path   |
+-----------------------------------------------------+

The identity does not receive general access to the central networking platform. Its delegation is limited to the dedicated resource group containing the centrally managed Private DNS zones.

How the solution works

1. An application deploys an Azure service and a Private Endpoint in its tenant.
2. Azure Policy evaluates the new Private Endpoint.
3. The policy identifies the service using properties such as groupId and privateLinkServiceId.
4. The policy uses its managed identity to deploy a Private DNS zone group.
5. The zone group references the appropriate Private DNS zone in the central tenant.
6. Azure registers the endpoint's private IP address in the central zone.
7. Cloud or on-premises clients resolve the service name through the central DNS path.
8. When the Private Endpoint is deleted, Azure removes the associated DNS record through the zone-group lifecycle.

Deployment sequence

Deploying this pattern is best approached as a sequence of platform onboarding phases rather than a single infrastructure deployment. Each phase establishes a dependency required by the next.

Begin with the central DNS foundation

Start in the central management tenant. Create the required Private DNS zones and connect them to the approved resolution path. Depending on the wider network design, this may include virtual network links, Azure DNS Private Resolver, forwarding rules, and integration with on-premises DNS. Completing this foundation first ensures that application tenants have a valid destination for their Private Endpoint records.

Prepare the application tenant identity

Next, create a dedicated user-assigned managed identity in the application tenant. Record its tenant ID and principal ID because these values identify who will receive delegated access. Keeping this identity dedicated to DNS policy remediation makes its purpose, permissions, and audit trail easier to understand.

Establish the Lighthouse delegation

Create the Azure Lighthouse registration definition and assignment in the central tenant. Delegate only the dedicated DNS resource group using the Private DNS Zone Contributor role. Before continuing, confirm that the managing tenant, principal, role, and scope are all correct. This step must finish before Azure Policy attempts remediation; otherwise, the identity will not be able to work with the central zones.

Introduce the policy automation

With delegation active, deploy the relevant DNS policy definitions or initiative in the application tenant. Assign the policy to the managed identity and provide the central Private DNS zone resource IDs as parameters. For Private Endpoints that already exist, start a remediation task so that they receive the same configuration as newly created endpoints.

Prove the complete lifecycle

Finally, deploy a test Private Endpoint. Confirm that Azure Policy creates the Private DNS zone group, that the correct A record appears in the central zone, and that an approved workload resolves the service name to its private IP address. Delete the endpoint and verify that Azure also removes the DNS record. This final cleanup test is important: automation is only complete when it handles both creation and deletion.

How to validate the solution

A successful deployment does not prove that name resolution and application connectivity work. Validation should cover three layers.

1. Control-plane validation

• The Lighthouse registration definition exists.
• The registration assignment references the correct definition.
• The managing tenant, principal ID, role, and scope are correct.
• The policy assignment uses the intended managed identity.
• The policy parameters contain the correct central zone resource IDs.

2. Resource validation

• The test Private Endpoint exists.
• The policy reports compliance or completes remediation successfully.
• A Private DNS zone group exists below the endpoint.
• The zone group references the intended central zone.
• The expected A record exists and matches the endpoint's private IP address.

3. Resolution and lifecycle validation

From an approved application network, resolve the service name and confirm that it returns a private IP address:

Resolve-DnsName myservice.blob.core.windows.net

Test application connectivity over the private path. Then delete the test Private Endpoint and confirm that the corresponding record is removed from the central zone.

Security considerations

• Use a dedicated identity for DNS policy remediation.
• Scope the Lighthouse delegation to only the dedicated DNS resource group.
• Separate deployment identities from runtime identities.
• Use workload identity federation instead of stored secrets.
• Require approval before applying delegation changes.
• Protect tenant configuration and Terraform state.
• Monitor Lighthouse registration assignments, policy remediation, and DNS changes.
• Test both DNS record creation and deletion.
• Review every new Private Link service before enabling its policy.

Benefits and trade-offs

This pattern can provide central DNS governance, automatic registration and cleanup, repeatable tenant onboarding, reduced custom code, and narrowly scoped cross-tenant access. Azure Lighthouse itself does not add a service charge.

The design also has trade-offs. Each application tenant requires an explicit delegation, and the central platform must govern identities originating in multiple tenants. Azure Lighthouse primarily delegates Azure control-plane access; it does not solve every data-plane authorization requirement. Policy definitions must also be maintained as new Private Link services are introduced.

When to use this pattern

Consider this architecture when workloads span multiple Entra tenants, Private DNS zones must remain centrally owned, application teams should not receive broad central-network access, and the organization prefers an Azure-native lifecycle over custom synchronization code.

A simpler design may be more suitable when all resources are in one tenant, only a few endpoints exist, or organizational policy does not permit cross-tenant delegated identities.

Conclusion

Cross-tenant Private Endpoint DNS is more than a DNS challenge. It combines networking, identity, governance, automation, and resource lifecycle management.

Azure Policy and Azure Lighthouse provide a promising Azure-native pattern: policy manages the endpoint-to-zone association, Azure manages the DNS record lifecycle, and Lighthouse supplies only the cross-tenant permission required for the operation.

Grant the smallest required DNS scope, automate the complete lifecycle, and validate the result from policy evaluation through application connectivity.

Further reading

• What is Azure Lighthouse?
• Azure Private Endpoint DNS configuration
• Private Link and DNS integration at scale
• DeployIfNotExists policy effect
• Use OpenID Connect with GitHub Actions and Azure
• Azure Lighthouse architecture and delegation scopes
• Azure Lighthouse tenants, principals, and supported roles

Azure Functions already gives you a familiar way to build event-driven apps. A queue message, HTTP request, timer, or event triggers the code that handles the work.

Azure Functions hosted skills (formerly Serverless Agents) add AI reasoning to that model. A hosted skill can read a request, use the regular tools you give it to inspect context, and choose the next step, while your triggers, tools, and business logic stay in place.

When the work needs to keep going

Consider an insurance policy servicing request. A hosted skill can use its regular tools to understand the requested change, look up the policy, and inspect the submitted documents. If the information is ready and the request can finish now, the normal tool loop, where the model calls a tool, reads the result, and decides the next step, is a good fit.

That changes when the work must continue after the initial request. An insurance policy servicing request may need to inspect several documents in parallel, wait for a configured delay before checking again for missing information, and build a review packet after the checks it depends on complete. In a normal tool loop, each result returns to the model before the skill can decide what happens next. The application must keep the job alive, save its progress, and deliver the final result.

At that point, the work needs to keep running independently of the original interaction instead of relying on the model and application to coordinate every step. For a queue or other non-HTTP trigger, the final result also needs to be written or sent somewhere useful because there is no response channel.

Introducing Dynamic Workflows

Dynamic Workflows is a Durable Functions-backed way to run a hosted skill's multi-step plan outside the original request. It separates planning from execution. At run time, the AI model generates a structured plan from the workflow-safe tools and subagents you explicitly allow. The hosted skill calls start_workflow with that plan. The runtime validates it, starts a Durable Functions orchestration, and runs each task when its dependencies are ready.

That separation addresses the limits of the normal tool loop: the workflow store keeps state and intermediate results out of the model's context, independent checks can run in parallel, and durable timers resume waits without holding a worker open. Because a Durable Functions orchestration handles execution, the work can continue after the original request or a Functions worker restart.

To test the difference, we ran the same structured multi-step task with the regular tool loop and with Dynamic Workflows, using a Foundry gpt-5.4-mini deployment. We ran it with inputs for one service and then ten services. In the Dynamic Workflows version, the model made the plan once, while the runtime kept intermediate tool results in the workflow store instead of sending them back to the model after every tool call. Dynamic Workflows used 56% fewer total model tokens for the one-service run and 93% fewer for the ten-service run, while producing the same final reports. Results will vary by workload and model, and small jobs can have planning overhead. The savings are largest when intermediate tool results would otherwise return to the model after every tool call.

How it works

Enable workflows in the hosted skill's Markdown front matter. The runtime then adds the management tools: start_workflow, get_workflow_status, list_workflows, cancel_workflow, and terminate_workflow. You do not implement those tools. You choose the workflow-safe tools and subagents that a plan can use.

At run time, the AI model uses the hosted skill's instructions to generate a structured plan, limited to the workflow-safe tools and subagents you explicitly allow. The hosted skill calls start_workflow with that plan; the runtime validates it, starts a Durable Functions orchestration, and returns a workflow ID right away.

Put workflow-safe handlers under tools/ and decorate them for use in a workflow. Each handler must run synchronously, accept one dict argument, return JSON-serializable data, and be idempotent. A worker failure can cause a handler to run more than once, which is why that last point matters. Ordinary tools retain their existing behavior unless you explicitly make them available to a workflow.

return {
    "position": args["position"],
    "document_id": document["document_id"],
    "type": document["type"],
    "file_name": document["file_name"],
    "evidence_state": evidence_state,
}

Dynamic Workflows runs on Durable Functions. You can configure Durable Task Scheduler in host.json and use its dashboard to see per-instance task state, retry history, and controls for work that is still running. Durable timers let a workflow wait without keeping a worker busy, then resume the steps that are ready. The workflow stays visible and durable instead of depending on an open request or a best-effort background task.

Get started

Build your first Azure Functions hosted skill dynamic workflow with the quickstart, then use the overview and sample to go deeper:

• Follow the Dynamic Workflows quickstart.
• Read the Dynamic Workflows overview.
• Browse the insurance policy review sample for an end-to-end implementation.