Justin Fine, Idris Motiwala, Tushar Goyal

Microsoft Fabric Graph removes the previous hop limit for variable-length traversals, allowing graph structure to determine path depth.

Graph analysis is often about discovering how entities connect when the number of relationships between them isn’t known in advance. A message might be part of a reply chain that is three levels deep — or thirty. A component might depend on another component through an unpredictable number of intermediate services. An organizational hierarchy might vary significantly across teams.

Microsoft Fabric Graph can now query unbounded variable-length paths, enabling traversals of relationships without specifying a fixed maximum number of hops while also being able to specify very large numbers for the upper bound.

Previously, variable-length traversals supported a low number of maximum hops. That limit worked well for many scenarios, but it required developers to choose an upper boundary even when the structure of the data should determine the traversal depth. With this update, a path can continue beyond this limit until the query finds a matching destination or no valid continuation remains.

What is a graph traversal?

A graph represents entities as nodes and the relationships between them as edges. For example, a social graph might include people, messages, posts, and forums as nodes. Relationships such as replied to, belongs to, or moderates connect those nodes.

A traversal follows relationships through the graph. A single-hop traversal answers a direct question, such as which post a message replies to. A multi-hop traversal follows a chain, such as identifying the original post in a reply thread or the upstream system supplying a dataset.

These chains don’t always have predictable depth. Requiring every query to specify a maximum can produce incomplete results when the selected limit is lower than the depth of the underlying data.

From bounded traversals to data-driven traversals

Before this update, a variable-length path could traverse up to predefined number of relationships. Developers could query a range of path lengths, but every query remained subject to that maximum.

Unbounded variable-length paths remove the ceiling. Instead of deciding in advance how deep the query should search, users can express the relationship pattern they want to follow and allow the graph structure to determine the required depth.

This change applies to scenarios such as:

• Conversation analysis: Follow reply chains back to their originating post.
• Data lineage: Trace upstream or downstream dependencies across complex pipelines.
• Dependency management: Identify transitive software, service, or infrastructure dependencies.
• Organizational analysis: Navigate reporting or ownership hierarchies of varying depth.
• Knowledge graphs: Follow semantic relationships until a relevant entity is found.
• Fraud and security investigations: Explore chains of related accounts, devices, events, or transactions.
• Supply-chain analysis: Trace materials, suppliers, and distribution relationships across multiple tiers.

Queries can express the intent of retrieving unbounded paths, but not the use of unlimited system responses. They continue to operate within applicable service protections, including execution time, capacity, memory, and result-size constraints.

Following an unbounded reply chain

Consider a social network graph containing messages, posts, forums, and people. A message can reply to another message, which can reply to another message, eventually reaching the post that began the conversation.

The following query starts with a specific message and follows the REPLY_OF relationship for as many steps as needed to reach a post. It then identifies the forum containing that post and returns the forum’s moderator.

In this query, starting with this message, keep following the reply chain until you reach the original post. Then return the forum that contains the post and the person who moderates it.

:params { messageId: 206158431836 } 
 
MATCH 
 (message:Message {id: $messageId}) 
 -[:REPLY_OF]->* 
 (post:Post) 
 <-[:CONTAINER_OF]- 
 (forum:Forum) 
 -[:HAS_MODERATOR]-> 
 (moderator:Person) 
RETURN 
 forum.id AS forumId, 
 forum.title AS forumTitle, 
 moderator.id AS moderatorId, 
 moderator.firstName AS moderatorFirstName, 
 moderator.lastName AS moderatorLastName

The query contains four logical steps:

1. Find the starting message. (message:Message {id: $messageId}) identifies the message supplied through the query parameter.
2. Follow the complete reply chain. -[:REPLY_OF]->* repeatedly follows outgoing REPLY_OF relationships. The traversal isn’t restricted to a limited number of hops, so deeply nested conversations can still reach their originating post.
3. Find the containing forum. (post:Post)<-[:CONTAINER_OF]-(forum:Forum) identifies the forum associated with the post.
4. Return the forum moderator. (forum:Forum)-[:HAS_MODERATOR]->(moderator:Person) connects the forum to its moderator, whose identifying information is returned.

Bounded paths still matter

Unbounded paths expand what graph queries can express, but they don’t replace bounded traversal.

MATCH (message:Message {id: $messageId})-[:REPLY_OF]->{5,23}(reply:Message) RETURN reply

A bounded path remains the better choice when the business question has a natural maximum. For example, an application looking for professional connections within three degrees should state that limit. A query evaluating only immediate and secondary dependencies should also use a bounded range.

Use a bounded path when:

• The maximum useful depth is known.
• Connections beyond a certain depth aren’t relevant.
• Predictable query cost or latency is important.
• The graph is dense and each additional hop could produce many more candidate paths.

Use an unbounded path when:

• The required depth is unknown.
• The query must reach the end of a hierarchy or chain.
• An arbitrary upper limit could omit valid results.
• The data provides a natural termination point, such as a root node or destination label.

The best path expression is the narrowest one that completely answers the business question.

Design efficient unbounded traversals

Removing a fixed hop ceiling makes query design even more important. The number of possible paths can grow quickly in a densely connected graph, particularly when nodes have many outgoing relationships, here are some recommendations:

• Start with a selective node

Anchor the traversal to a specific entity whenever possible. In the example, the message ID provides a precise starting point and avoids scanning reply chains for every message.

• Specify relationship and node labels

A traversal that names REPLY_OF, Post, and Forum is more targeted than one that follows any relationship to any node. Expressing the intended graph structure constrains the search and makes the query easier to understand.

• Apply filters early

Place selective conditions as close as possible to the relevant node or relationship pattern. Early filtering reduces the number of candidate paths that later stages must process.

• Return only the required data

Project the properties needed by the application instead of returning every node, edge, or property encountered during traversal. Smaller results are easier to process and transfer.

• Account for cycles

Some graphs contain relationships that can lead back to previously visited entities. Model traversal patterns carefully and use supported path modes (ASYCLIC, TRAIL, WALK, etc) or predicates when the scenario requires protection against repeated nodes or edges.

• Test with representative data

A query that performs well on a small development graph can behave differently when applied to a dense production graph. Test using realistic path depths, relationship density, and result sizes. Monitor execution behavior before incorporating an unbounded traversal into a production workload.

Next steps

Explore unbounded variable-length paths with a scenario in which relationship depth varies across your data. Evaluate the query with representative graph density and path lengths before using it in a production workload.

• Graph in Microsoft Fabric overview
• GQL language guide for graph in Microsoft Fabric
• Optimize GQL query performance for graph in Microsoft Fabric

Tags: #Graph, Graph Query Language (#GQL), data relationships, graph traversal, #graphsareeverywhere

Explore deeper connections with unbounded variable-length paths in Microsoft Fabric Graph was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

January–August 2026 updates expand how users find, inspect, compose, and analyze connections.

Graph data helps organizations understand connections: how data moves between systems, how services depend on one another, how conversations develop, and how people or organizations relate. Graph Query Language (GQL) provides a standardized way to ask those questions in Microsoft Fabric Graph.

From January through August 2026, the GQL feature set expanded across path finding, traversal control, query composition, aggregation, and data handling. The result is broader analytical coverage for business users and more precise query tools for developers. This post explains each improvement and includes the associated syntax.

Find and control paths

Shortest paths with ANY SHORTEST

When several routes connect two entities, many applications need one shortest route rather than every possible route. ANY SHORTEST makes that intent explicit. This is useful for dependency analysis, recommendations, network routing, and investigations where fewer intermediate steps are preferred.

MATCH ANY SHORTEST ({id: 1})->{,2}(d) 
RETURN d.id AS dst

Quantified edge patterns

Quantified edge patterns repeat a complete relationship pattern, including conditions on intermediate entities. In the following example, the repeated pattern requires the source person at each step to use Chrome. This gives developers more control than repeating an edge alone.

MATCH p=(a:Person {id: 987})((x)-[k:knows]->() WHERE x.browserUsed = 'Chrome'){2}(b:Person) 
FOR n IN NODES(p) WITH OFFSET off 
RETURN n.browserUsed 
ORDER BY a.id, b.id, off 
LIMIT 12

Complete path modes

Path modes define whether a traversal can revisit nodes or edges.

• WALK permits repetition.
• TRAIL prevents repeated edges.
• SIMPLE prevents repeated interior nodes.
• ACYCLIC prevents any repeated node.
• DIFFERENT EDGES prevents one edge from satisfying more than one edge variable in the match.

These choices help query results reflect the meaning of a route, hierarchy, or dependency chain.

MATCH WALK (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) 
RETURN p.firstName AS name

MATCH TRAIL (:Person {firstName: "Juliana"})-[:studyAt]->(:University)<-[:studyAt]-(p:Person) 
RETURN p.firstName AS name

MATCH SIMPLE (x)->{2}(y) 
RETURN COUNT(*) AS path_count

MATCH ACYCLIC (x:`node` {id: 1})->(y)->(z) 
RETURN x.id, y.id, z.id 
ORDER BY x.id, y.id, z.id

MATCH DIFFERENT EDGES (p:Person {name: 'Keanu Reeves'})-[e:ACTED_IN]->(m:Movie) 
RETURN m.title AS movie

Unbounded variable-length path patterns

Variable-length paths previously had a limited maximum hop. Unbounded quantifiers allow the graph structure to determine depth when a chain has no meaningful fixed limit. The example follows one or more relationships while ACYCLIC prevents a node from being visited twice. Unbounded describes the path expression, not unlimited compute; selective starting points and representative performance testing remain important.

MATCH ACYCLIC ()-[]->{1,}() 
RETURN COUNT(*) AS total

Inspect paths and graph elements

NODES, EDGES, and INNER_NODES

These functions expose the contents of a matched path. NODES returns all nodes, EDGES returns its relationships, and INNER_NODES returns the intermediate nodes without the endpoints. They help applications explain lineage, dependencies, and investigative findings instead of returning only the destination.

MATCH p=({id: 1})-[]->{0,4}(z) 
RETURN NODES(p) AS res_nodes, 
 INNER_NODES(p) AS res_inner_nodes 
ORDER BY z.id

ELEMENT_ID

ELEMENT_ID returns the identity of a graph element. It is useful when an application must compare, track, or reference a specific node or edge independently of its business properties.

MATCH (x) 
RETURN ELEMENT_ID(x) AS vid, x AS actual_id 
ORDER BY x.id 
LIMIT 5

SOURCE and DESTINATION

SOURCE and DESTINATION identify the endpoints of an edge. This makes directional checks and edge-centric analysis easier, especially when a query starts from a relationship rather than a node.

MATCH (x)-[e]->() 
RETURN x.id, SOURCE(e).id AS s 
ORDER BY e.src, e.dst 
LIMIT 10

MATCH ()-[e]->(x) 
RETURN false IN COLLECT_LIST(x = DESTINATION(e)) AS no

Compose larger queries

NEXT

NEXT passes the output of one query stage into the next. Analysts can describe a multistage question in the order they reason about it: calculate a measure, filter the result, follow another relationship, and then summarize again.

MATCH (m:Message)-[:hasCreator]-(p:Person) 
RETURN p, AVG(m.length) AS avg_msg_length GROUP BY p 
NEXT 
FILTER avg_msg_length > 100u 
MATCH (p)-[:knows]->(:Person) 
RETURN avg_msg_length, COUNT(*) AS connections 
GROUP BY p, avg_msg_length

EXISTS subqueries

EXISTS answers a yes-or-no question about another graph pattern. It can filter rows or participate inside an aggregate without requiring the outer query to return the matching details.

MATCH (x) 
WHERE EXISTS { 
 MATCH (y) 
 WHERE y.id = 5 
 RETURN y 
} 
RETURN x.id AS xid 
ORDER BY xid
MATCH (x) 
RETURN COUNT(*) FILTER ( 
 WHERE EXISTS { MATCH (x)-[]->(y) RETURN y } 
) AS count_with_out

CALL subqueries

CALL runs a contained query for the current outer result. The example calculates each node’s outgoing degree in a focused block and then returns it with the node identifier.

MATCH (x) 
CALL { 
 MATCH (x)-[e]->(y) 
 RETURN COUNT(e) AS out_degree 
} 
RETURN x.id AS xid, out_degree 
ORDER BY xid

OPTIONAL CALL

OPTIONAL CALL preserves the outer row when the contained query has no match. This supports enrichment scenarios where related information is useful but not required.

MATCH (x {id: 1}) 
OPTIONAL CALL { 
 MATCH (y)-[]->(x) 
 RETURN y.id AS yid 
} 
RETURN x.id AS xid, yid 
ORDER BY yid

UNION DISTINCT

UNION DISTINCT combines compatible result sets and removes duplicate rows. It complements UNION ALL, which preserves duplicates, so the query can choose the correct set behavior.

MATCH () LIMIT 3 
RETURN 42 AS x 
UNION 
MATCH () LIMIT 3 
RETURN 100u AS x

Summarize connected data

Filtered and paged aggregates

Filtered aggregates calculate a summary over a selected subset. Paging controls such as LIMIT can be applied within the aggregate, giving developers precise control over which values contribute to the result.

MATCH (m:Movie) 
RETURN COUNT(*) FILTER (WHERE m.released < 1980 LIMIT 10) AS filtered_count

Nested aggregations

Nested aggregation supports layered questions, such as finding the minimum of averages calculated across groups or paths. This reduces the need to move intermediate results into application code.

MATCH (a:`node`)-[e:`edge`]->{1,2}(b:`node`) 
RETURN a.id AS id, MIN(AVG(e.weight)) AS min_average 
GROUP BY id

COLLECT_ONE, COLLECT_LIST, and COLLECT_ELEMENTS

Collection functions retain values or graph elements for evaluation as a group. COLLECT_ONE selects one value, COLLECT_LIST builds a list, and COLLECT_ELEMENTS gathers graph elements. They are useful for path-level checks, ordered output, and analysis across repeated relationships.

MATCH (p:`node` {id: 1})-[e]->{2}(p1:`node` {id: 1}) 
RETURN (COLLECT_ONE(e.weight) IN [e[0].weight, e[1].weight]) AS contained

MATCH ()-[e]->{1,2}() 
RETURN COLLECT_LIST(ALL e.weight) AS w 
ORDER BY w 
LIMIT 20

MATCH ()-[a:ACTED_IN]->{0,4}() 
WHERE SIZE(COLLECT_ELEMENTS(DISTINCT a.roles)) > 4 
RETURN TO_JSON_STRING(a.roles) AS r

Work with values and text

Dynamic nested data

Support for dynamic nested data lets queries work with richer values that do not fit a flat property model. This is useful when graph entities contain structured application payloads, nested attributes, or evolving schemas.

CAST

CAST converts a value to a supported target type. Explicit conversion makes comparisons and calculations more predictable when source data uses different numeric representations.

RETURN CAST(42 AS DOUBLE) AS double_res, 
 CAST(42 AS UINT) AS uint_res, 
 CAST(42.5d AS INT) AS int_res

RANGE

RANGE creates a numeric sequence. A generated sequence can support iteration, testing, bucketing, and list-oriented calculations within a query.

RETURN RANGE(0, 4) AS res

POWER

POWER performs exponent calculations. It extends the numeric expressions available for scoring, weighting, and mathematical transformations.

RETURN POWER(-2, 3) AS res

NORMALIZE and IS NORMALIZED

Unicode text can have visually identical but technically different encodings. NORMALIZE converts text to a normalization form, while IS NORMALIZED checks its current form. This supports more consistent matching and grouping across multilingual data.

RETURN NORMALIZE('cafe\u0301') AS normalized_text
RETURN 'cafe\u0301' IS NFKD NORMALIZED AS is_normalized

Regular-expression functions

The MSFT.REGEXP functions match, count, locate, extract, and replace text patterns. They help prepare identifiers, names, codes, and descriptions before those values are compared or summarized.

RETURN MSFT.REGEXP_LIKE('café', 'caf.') AS x
RETURN MSFT.REGEXP_COUNT('abcabcabc', 'abc') AS n
RETURN MSFT.REGEXP_INSTR('hello world', 'world') AS p
RETURN MSFT.REGEXP_REPLACE('a1b2c3', '[0–9]', '#') AS s
RETURN MSFT.REGEXP_SUBSTR('abc123def', '[0–9]+') AS s

Design guidance

Use the narrowest pattern that answers the question. Start from selective nodes, specify relationship and node labels, and apply filters early. Use bounded traversal when the business question has a natural maximum. When depth is unknown, combine an unbounded path with an appropriate path mode and test it against representative graph density. Return only the properties or path elements the application requires.

Feature availability can vary by environment and release stage. Confirm current support and syntax in the Microsoft Fabric Graph documentation before publishing a production query.

Next steps

Choose a connected-data scenario — such as lineage, dependency analysis, recommendations, investigations, or knowledge discovery — and identify which path, composition, and aggregation features make the question easier to express.

• Graph in Microsoft Fabric overview
• GQL language guide for graph in Microsoft Fabric
• GQL graph patterns
• GQL standard conformance for graph in Microsoft Fabric
• Optimize GQL query performance for graph in Microsoft Fabric

Tags: Graph, Graph Query Language (GQL), graph traversal, connected data, developers

Murilo Vasconcelos, Stefan Plantikow, Idris Motiwala, Eldad Hagashi, Qian Liang, Danny Navon, Michael Robson, Pau Baiget, Rajagopal Ravipati

More expressive graph analysis: GQL improvements in Microsoft Fabric Graph was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

As soon as an agent needs to touch the open internet — search, scrape, retrieve — “secure by design” stops being a slide and starts being an actual network problem.

This lab (aca-sandbox-foundry, an evolution of jkalis-MS/azure-container-apps-multi-agent-workflow) is a reference implementation for exactly that problem: an AKS-hosted, APIM-governed multi-agent system that isolates the one risky operation — web retrieval — inside disposable Azure Container Apps (ACA) Sandboxes, while everything around it stays authenticated, private, and observable.

Link to the repository and the full documentation journey at the bottom of this article.

What It Actually Does

The lab turns a single topic into a complete content package.

A Researcher agent gathers and synthesizes trusted sources into a research brief.

A Content Creator agent turns that brief into a long-form blog post and a social content package.

A Podcaster agent generates a multi-speaker script, synthesizes audio, and persists the result.

A browser-based DevUI shows the whole run: live agent health, sandbox lifecycle events, egress evidence, and the generated artifacts as they land.

Solution at a Glance

High-level architecture: the DevUI orchestrator, three framework-diverse agents, APIM, Foundry, Application Insights, and the ACA Sandbox retrieval path.

The user-facing orchestrator coordinates three framework-diverse agents on AKS. APIM governs both agent and model traffic, Microsoft Foundry supplies models and agent registration, Application Insights captures telemetry end to end, and ACA Sandboxes isolate only the research retrieval tool — the sandboxes never host the three long-running agents themselves.

Three Agents, Three Frameworks, One Contract

The lab intentionally refuses to treat every agent as “the same app in a different container.” Each one uses a distinct framework and runtime suited to its job, and A2A (Agent2Agent) is the common contract that lets them interoperate anyway — a real test of the protocol, not a convenience wrapper around one SDK.

DevUI is the user-facing orchestrator, but it is deliberately dumb about security: it runs the research step first, sends the resulting brief to the creator and podcaster in parallel, and never talks to an agent directly. Every call goes same-origin to the BFF, and every BFF call goes through APIM. No agent calls another agent — each remains an independently deployable service that happens to share an interoperability contract, not a tightly coupled pipeline.

The Azure Stack, Component by Component

This is where the lab earns its keep — not by picking exotic technology, but by wiring familiar Azure services together with a consistently paranoid network posture.

Azure Kubernetes Service (AKS)

AKS is the compute backbone for all three agents and the BFF. Each agent runs on a dedicated, tainted node pool, isolated from general workloads. No agent Pod is exposed publicly: every agent is fronted by an internal Kubernetes LoadBalancer Service bound to a private VNet address rather than a public IP. loadBalancerSourceRanges on each Service restricts inbound connections to APIM’s subnet alone, and Azure CNI powered by Cilium enforces the identical restriction a second time inside the cluster’s own dataplane. That redundancy is deliberate: even a bug in DevUI or the BFF that tried to call an agent directly, bypassing APIM, would find no route to take. AKS also hosts the Sandbox Broker, which is the only component permitted to request a sandbox on the Researcher’s behalf.

Azure API Management (APIM)

APIM is the single governed front door for two very different kinds of traffic, and that is the point: it is the only path in either direction. First, it fronts A2A traffic between the BFF and the three agents, so every inter-agent request is authenticated, rate-limited, and logged in one place rather than scattered across ad hoc service-to-service calls. Second, it exposes the /openai gateway that all three agents use for Microsoft Foundry model and text-to-speech access, so no agent holds a direct Foundry endpoint or API key of its own. Because APIM is also the only subnet allow-listed by every agent’s loadBalancerSourceRanges, it doubles as the network chokepoint the whole design is built around, not just an API facade.

Microsoft Foundry

Foundry is the model and agent-registration plane. It supplies the large language models the Researcher, Content Creator, and Podcaster call for synthesis, drafting, and script generation, along with the text-to-speech models behind the podcast audio. Foundry also handles custom-agent registration, giving each agent a governed identity in the platform rather than being an anonymous caller of a shared model endpoint. Every one of those calls is routed through the APIM /openai gateway — agents never dial Foundry directly, which keeps model access inside the same audit and policy boundary as every other governed call in the system.

Azure Container Apps (ACA) Sandboxes

Azure Container Apps Sandboxes reached general availability this week — and it is not a new isolation stack. It is Microsoft externalizing the same hardware-isolated microVM fabric that already runs Cloud Sandboxes in GitHub Copilot ,Foundry Hosted Agents, Azure ARE Agents and more. During public preview it was already creating over a million sandboxes a day. That maturity is exactly why it is the right foundation for the Researcher’s retrieval path in this lab, and for running private coding agents more broadly.

The GA announcement: sandboxes execute securely by default, resume instantly from a full memory-and-disk snapshot, and burst to hyperscale in sub-second time — with Azure Container Apps, Foundry, GitHub, and Container Apps Express all building on the same foundation layer.

The topology behind that announcement is straightforward once you see it laid out. A sandbox group is the unit of governance: everything inside it shares disk images, snapshots, data volumes, secrets, and identity, while every individual sandbox still gets its own CPU, memory, disk, and network boundary.

Portal, CLI, and SDK access all converge on a sandbox group. Ingress is off by default and opt-in per sandbox and port, waking on request; egress runs through a per-sandbox proxy enforcing host allowlists and deny policies, with injected credentials that never enter the sandbox itself.

That last point is the one worth sitting with: credential injection happens at the egress proxy, outside the sandbox boundary. Code running inside — including AI-generated code — never sees the actual secret, only the effect of a request that was allowed to go through. It is the same shape as the Sandbox Broker pattern in this lab’s Researcher path, just implemented as a first-class platform primitive instead of something you wire up yourself.

What This Looks Like Running

A sandbox group in the Azure portal shows exactly what it costs to keep isolation this granular: total sandboxes, how many are actually running versus stopped, custom images, and snapshots, alongside live runtime metrics for running cores and memory.

A live sandbox group: 4 total sandboxes (one goes down), running-core and running-memory metrics over the last days, and recent sandboxes each stopped with their exact resource footprint (4 cores / 8 GiB / 80 GiB, down to 0.25 cores / 512 MiB / 5 GiB) preserved for the next resume.

Scoping sandboxes per task, rather than sharing one long-lived environment, is the pattern that keeps retrieval contained. Here five sandboxes are each labeled with the single host they were created to reach — one for azure.microsoft.com, one for learn.microsoft.com, one for github.com, and so on — all created within the same second and all running on identical 1 core / 2 GiB / 20 GiB footprints.

Five sandboxes, each scoped to a single allow-listed host and spun up simultaneously — the sub-second, burst-to-hyperscale behavior from the GA announcement, seen from the inside.

And this is the observability piece made concrete: a single running sandbox, its live terminal, and its egress network traffic panel — every outbound request logged with a timestamp, method, destination, and an explicit allowed or denied verdict, right next to real-time CPU, memory, storage, and network utilization and a live log stream.

22 requests allowed, 0 denied — every GET call to azure.microsoft.com, learn.microsoft.com, files.pythonhosted.org, and pypi.org visible with its verdict, alongside live CPU, memory, storage, and network metrics for the sandbox.

This is what “governed, closed, and observable” means in practice: nothing leaves the sandbox that was not explicitly allow-listed, nothing that does leave is invisible, and none of it costs meaningful startup latency. For a Researcher agent fetching untrusted web content, or for a private Claude or GitHub Copilot coding agent running inside a customer’s tenant, that combination — hardware isolation, default-deny egress with full request-level audit, and sub-second start — is precisely the missing piece between “agents that browse the web” and “agents you can actually run in a governed enterprise environment.”

Now let’s return to our use case and see how ACA Sandboxes provides best solution for our needs.

ACA Sandboxes exist to solve one specific problem: the Researcher’s job requires fetching content whose provenance and payload it does not control, and that is the one operation in the whole system with real blast radius. The Researcher never performs that fetch itself — it hands the task to a Sandbox Broker, which spins up a short-lived, per-task ACA Sandbox with default-deny egress (in our example we blocked bing.com on purpose), scoped to exactly the destinations that single task requires. When the task completes, the sandbox is torn down with it. If a scraped page tried to phone home or pivot toward an internal service, there would be nothing left for it to reach by the time anyone noticed. Sandboxes are strictly a retrieval tool for the Researcher — they never host the long-running agents, the BFF, or DevUI.

Identity, Storage, and Observability

A user authenticates through Microsoft Entra ID, fronted by Application Gateway for Containers and an OAuth2 Proxy sidecar pattern, so no credential — reusable or otherwise — ever lives in the browser. The Podcaster writes generated audio to private Azure Blob Storage using Workload Identity instead of a connection string or access key in a config file. And OpenTelemetry instrumentation runs through every agent and the BFF, exporting to Application Insights and Log Analytics with APIM diagnostics stitched into the same correlation IDs, so a slow or failed run can be traced end to end — from the browser click down through the sandbox that did the retrieval.

Seeing It Run: User Experience

How a Request Actually Flows

1. A user authenticates with Microsoft Entra ID through Application Gateway for Containers and OAuth2 Proxy.

2. DevUI JavaScript calls same-origin protected APIs through the BFF.

3. The BFF sends A2A requests to APIM rather than exposing reusable downstream credentials in the browser.

4. APIM reaches three source-restricted private AKS origins: research, creator, and podcaster.

5. The agents use the APIM /openai gateway for Foundry model and TTS access.

6. Research delegates isolated retrieval to the Sandbox Broker, which creates policy-controlled ACA Sandboxes.

7. Podcaster persists audio through a private Blob endpoint, while workloads and APIM export correlated telemetry to Application Insights.

Project Status and Deployment Boundary

This is a working baseline, not a proof of concept: AKS, APIM, Foundry, ACA Sandboxes, private storage, identity, ingress, and observability are all deployed and validated together as a conventional Kubernetes stack, stood up end to end with the Azure Developer CLI and Bicep.

One caveat worth flagging for anyone adapting this: the demonstration AKS API endpoint is left public for operator convenience, while the application workloads and agent origins themselves stay private. A production deployment needs a private AKS control plane, trusted TLS, production-grade identity governance, and organization-approved network controls layered on top of everything described above.

Summary

The interesting decision in this lab is not “agents can collaborate” — that part is easy to demo and easy to fake. It is that the one operation with real blast radius, unrestricted web retrieval by an LLM-driven agent, is fully contained behind default-deny, per-task sandboxes, enforced at two independent layers of the network, while the rest of the system stays governed by Entra ID, APIM, and Foundry end to end.

Resources and documentation

● Repository: lyantovski/aca-sandbox-foundry

● Azure Container Apps Sandboxes, Now Generally Available | Microsoft Community Hub

● ACA Sandboxes | ACA Sandboxes Portal Docs

Building a Governed Multi-Agent Content Factory on Azure was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tip #1 — Foundry-hosted agents and outbound traffic

When hosting your agents in Foundry, they are running into a container app environment managed by Microsoft behind the scenes. While Foundry supports the BYO subnet feature, you must make sure to:

• Use a standard setup (not basic)
• Bring not only your own subnet but also your own resources, meaning Cosmos DB, AI Search, Storage, etc.

Only bringing your own subnet will not throw any error but the agents will still fail to resolve private link resources and go to the public endpoints of any resource they try to reach.

Here is a useful repo to get started https://github.com/microsoft-foundry/foundry-samples/

Tip #2 — Using private link with Sandbox Groups

Azure Sandbox Groups are a great way to execute LLM-generated code safely. They are backed by MicroVMs, ensuring strict isolation as well as lightning speed. However, in the enterprise environment, we tend to isolate things from internet as much as possible, and here comes the tip! Sandbox Groups themselves have no private endpoints. The best you can achieve is to add network ACLs on their public endpoints. However, you can attach them to Container Apps Environments of type ‘Express’. Once attached, the Sandbox Groups can be connected using private endpoints. You can read more about this here https://sandboxes.azure.com/docs/sandboxes/private-endpoints

Tip #3 — Dealing with MCP authentication (DCR and/or CIMD)

I shared a few options to deal with MCP within the Azure and Microsoft ecosystem. You can read this here to get all the details https://medium.com/@stephaneeyskens/i-built-my-own-wine-companion-mcp-server-on-azure-and-net-it-wasnt-that-straightforward-f8e74fab8722 .

However, I recently discovered an option I wasn’t aware of, consisting of using FastMCP, a Python library. In a nutshell, FastMCP is a library that is part of your MCP server and acts as a proxy between the MCP client and your MCP server.

It supports both Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD). During the handshake, the client communicates with FastMCP rather than directly with the identity provider for registration and token acquisition. The client interacts with Entra ID only to authenticate the user.

FastMCP acquires tokens transparently and passes them to the MCP server, which can then use an on-behalf-of (OBO) flow to obtain tokens for downstream APIs. FastMCP also provides a state API that makes it easier to persist state in Redis, using a computed JTI key to link that state to upstream tokens.

Below is the sequence diagram showing the flow.

Here is a pointer to the official FastMCP web site https://gofastmcp.com/v2/servers/auth/oauth-proxy

Tip #4 — Dealing with MCP integration with SaaS platforms

Although Satya Nadella suggested that SaaS platforms would die with the rise of AI, we still see many SaaS platforms whose the core business is AI. Platforms such as Perplexity and Claude code are just examples of these. I see two ways to expose your enterprise MCP servers to the outside world:

• Use Private Link Service (PLS) whenever possible if the SaaS provider supports it.
• Expose your MCP server to Internet. In this case, you’d go for Front Door/Application Gateway ==> API Management ==> MCP server with or without FastMCP.

However, at this stage, using PLS remains not that easy because:

• As of 09/2026, PLS Direct Connect is still in preview and only available in a few regions (e.g. only Spain Central for Europe).
• The destination of a PLS cannot be a private endpoint, although it technically works (I tested it).

The Citadel approach consists in using an AI gateway (API Management) as a central policy enforcement point. However, as of 09/2026, we cannot use Private Link Service (PLS) with API Management’s load balancer because PLS does not recognize it as an Azure Load Balancer. A private endpoint for APIM might seem like an alternative, but that scenario is not supported either. PLS requires a standard Azure Load Balancer, such as the one used by AKS.

For now, the only supported approach appears to be proxying the AI gateway through a gateway API hosted on AKS, although that feels like a dirty workaround. Hopefully, Microsoft will make PLS Direct Connect generally available across all regions soon and support private endpoints as destinations, enabling a wider range of integration scenarios.

Tip #5 — Writing stateful agents

There are many ways to orchestrate agents, but fewer options for running stateful orchestrations. As of 09/2026, I consider Dapr workflows to be one of the best options. Additionally, Dapr makes it easy to run ambient agents, which are nothing else but agents responding to events/commands, and Dapr particularly excels in building distributed systems.

Sharing a few tips and tricks about AI on Azure, that Claude itself isn’t always aware of! was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

As organizations build more AI powered applications, choosing the right model for every request becomes increasingly important. Not every prompt requires a large and expensive reasoning model, while more complex workloads often benefit from advanced models with higher capabilities. Microsoft Foundry Model Router addresses this challenge by automatically selecting the most appropriate model for each request based on factors such as complexity, quality requirements, latency, and cost. Instead of maintaining custom routing logic, developers can interact with a single endpoint while the routing decisions happen behind the scenes..

In this article, we will deploy Microsoft Foundry Model Router using Bicep and explore how Infrastructure as Code can simplify the deployment and management of intelligent AI routing workloads on Azure.

The main.bicepparam template defines our input parameters, such as the Landing Zone, Environment, Location.

using 'main.bicep'

//////////////////////////////////
param parAlzName = 'sln'
param parEnvironment = 'prod'
param parLocation = 'swedencentral'
/////////////////////////////////

The main.bicep template serves as the entry point for our Bicep configuration and defines the parameters and variables used across the Azure AI Foundry module.

metadata name = 'Cognitive Services Account with Model Router'
metadata description = 'This is a Bicep template to deploy a Cognitive Services Account with the Model Router deployment.'
metadata owner = 'Brian Veldman'
metadata version = '1.0.0'

/* TARGET SCOPE */
targetScope = 'subscription'

@description('Defining our input parameters')
param parEnvironment string
@allowed([
  'swedencentral'
])

param parLocation string 
param parAlzName string

@description('Defining our variables')
var shortEnvironmentMapping = {
  swedencentral: 'sdc' // Supported for Model Router in Foundry
}

var shortEnvironment = shortEnvironmentMapping[parLocation] ?? parLocation
var resourceGroupName = 'rg-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'

@description('Deploying our resourcegroup')
resource rg 'Microsoft.Resources/resourceGroups@2025-04-01' = {
  name: resourceGroupName
  location: parLocation
}

@description('Deploying our AI module')
module ai 'modules/ai.bicep' = {
  params: {
    parAlzName: parAlzName
    parEnvironment: parEnvironment
    parLocation: parLocation
    shortEnvironment: shortEnvironment
  }
  scope: rg
}

The ai.bicep module automates the deployment of an Azure AI Foundry environment by provisioning an Azure AI Services account, an AI Foundry project, and a Model Router deployment. It creates a centrally managed AI platform with project management capabilities enabled, configures a dedicated AI Foundry project with a system assigned managed identity for secure resource access, and deploys a Model Router endpoint using the Global Standard SKU. The module also applies a consistent naming convention based on the landing zone, environment, and location parameters, enabling standardized and scalable AI service deployments across Azure environments. ❤️

param parEnvironment string
param parLocation string 
param parAlzName string
param shortEnvironment string

@description('Deployment of Foundry')
resource aif 'Microsoft.CognitiveServices/accounts@2025-12-01' = {
  name: 'aif-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
  location: parLocation
  kind: 'AIServices'
  sku: {
    name: 'S0'
  }
  properties: {
    allowProjectManagement: true
    customSubDomainName: 'sub-aif-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
  }
}

@description('Deployment of Foundry Project')
resource aip 'Microsoft.CognitiveServices/accounts/projects@2025-12-01' = {
  name: 'proj-aif-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
  parent: aif
  location: parLocation
  identity: {
    type: 'SystemAssigned'
  }
}

@description('Deployment of Foundry Model Router')
resource router 'Microsoft.CognitiveServices/accounts/deployments@2025-12-01' = {
  name: 'model-router'
  parent: aif
  sku: {
    name:  'GlobalStandard'
    capacity: 499 //1 capacity unit = 1000 tokens per minute, took the standard capacity
  }
  properties: {
    model: {
      name: 'model-router'
      format: 'OpenAI'
      version: '2025-11-18' // Last supported version
      
    }
    routing: {
      mode: 'balanced'
    }
  }
}

Customize the code to align with your specific requirements, then execute it. After a few minutes, all the necessary resources will be deployed. This can be done using: New-AzSubscriptionDeployment -Name deploymentName -TemplateFile .\main.bicep -TemplateParameterFile .\main.bicepparam -Location swedencentral.

After deployment, you can use the standard Chat Completions API against the Model Router endpoint. Simple prompts are typically routed to smaller and cheaper models, while more complex reasoning tasks are automatically directed to larger models. This allows organizations to optimize both cost and performance without modifying application logic.

Within the Microsoft Foundry portal, navigate to Deployments and verify that the Model Router deployment is present and successfully provisioned.

We can see the model-router deployment. For this demo, I will use the Open in Playground option, which allows us to test the Model Router directly from within the browser.

When I ask “What is Azure?”, the request is routed to the GPT-5 Mini model by the Model Router, which selects the most appropriate model based on the prompt and routing configuration. For this query, the GPT-5 Mini model is chosen to generate the response.

However, when I ask, “Can you write an Azure Bicep template based on Azure Verified Modules to deploy an Azure Virtual Machine?”, the Model Router selects the GPT-5.3 Chat model. This is because the request involves more advanced reasoning, code generation, and knowledge of Azure infrastructure patterns, making GPT-5.3 Chat the more suitable model for generating an accurate and comprehensive response.

We can also use the Completions API to call the Model Router endpoint directly. With this approach, every request is automatically routed to the most suitable model based on the complexity and requirements of the prompt. This allows applications to benefit from optimized model selection without having to manually choose between different models, helping to balance performance, capability, and cost.

That’s all for today. As you could see, Azure AI Foundry Model Router simplifies the way applications interact with AI models by automatically selecting the most suitable model for each request. Whether you are handling simple questions, complex reasoning tasks, or code generation scenarios, Model Router helps optimize performance, capability, and cost without requiring manual model selection. This makes it easier to build intelligent applications that can adapt to a wide range of user requests while taking full advantage of the latest AI models available in Azure AI Foundry. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story and let me know if you have any feedback. I look forward to seeing you in the next session. Until then, take care! ❤️

Deploy and use the Foundry Model Router using Azure Bicep was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I started blogging, one of my first articles was about configuring Microsoft Entra ID authentication for Azure SQL Database. At that time, everything was done manually through the Azure portal using ClickOps. While that worked perfectly fine, it wasn’t exactly the Infrastructure as Code approach that I prefer. Recently, I was asked how to deploy Azure SQL with Microsoft Entra ID authentication entirely using Azure Bicep. That question inspired me to revisit the topic and build a fully automated solution that not only deploys the Azure SQL Server and database, but also creates the required Microsoft Entra groups and configures the Entra administrator. In this blog, I’ll walk you through building a complete end to end Azure Bicep solution, allowing you to provision Azure SQL with Microsoft Entra ID authentication from scratch without relying on manual configuration in the Azure portal.

The main.biceptemplate serves as the entry point for our Infrastructure as Code solution. It defines the parameters, variables, and module orchestration required to deploy the complete Azure SQL environment.

metadata name = 'Deploy Azure SQL Server with Entra ID Authentication'
metadata description = 'Deploys an Azure SQL Server with Entra ID authentication enabled for administrators.'
metadata owner = 'Brian Veldman'
metadata version = '1.0.0'

/* TARGET SCOPE */
targetScope = 'subscription'
/* EXTENSIONS */
extension 'br:mcr.microsoft.com/bicep/extensions/microsoftgraph/v1.0:0.1.8-preview'

@description('Defining our input parameters')
@allowed([
  'canadacentral'
  'westus'
  'westus2'
  'eastus'
  'eastus2'
  'westeurope'
])
param parLocation string = 'canadacentral'
param parEnvironment string
param parAlzName string

@description('Defining our variables')
var varShortEnvironmentMapping = {
  canadacentral: 'cnc'
  westus: 'wus'
  westus2: 'wus2'
  eastus: 'eus'
  eastus2: 'eus2'
  westeurope: 'weu'
}

var shortEnvironment = varShortEnvironmentMapping[parLocation] ?? parLocation
var resourceGroupName = 'rg-sql-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
var sqlServerName = 'sql-entra-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'
var sqlDatabaseName = 'sqldb-test-${parAlzName}-${parEnvironment}-${shortEnvironment}-001'

@description('Resource Group Deployment')
resource sqlResourceGroup 'Microsoft.Resources/resourceGroups@2023-07-01' = {
  name: resourceGroupName
  location: parLocation
}

@description('Creating Entra ID Group for SQL Administrators')
resource groupAdministrators 'Microsoft.Graph/groups@v1.0' = {
  displayName: 'SQL Administrators'
  mailEnabled: false
  mailNickname: 'sqladministrators'
  securityEnabled: true
  uniqueName: 'sqladministrators'
  members: [
    deployer().objectId
  ]
}

@description('Creating Entra ID Group for SQL Readers')
resource groupReaders 'Microsoft.Graph/groups@v1.0' = {
  displayName: 'SQL Readers'
  mailEnabled: false
  mailNickname: 'sqlreaders'
  securityEnabled: true
  uniqueName: 'sqlreaders'
}

@description('Deploying Azure SQL Server with Entra ID Authentication')
module server 'br/public:avm/res/sql/server:0.21.3' = {
  params: {
    name: sqlServerName
    administrators: {
      azureADOnlyAuthentication: true
      login: groupAdministrators.displayName
      principalType: 'Group'
      sid: groupAdministrators.id
    }
    location: parLocation
    databases: [
      {
        name: sqlDatabaseName
        availabilityZone: -1
        collation: 'SQL_Latin1_General_CP1_CI_AS'
        maxSizeBytes: 53687091200
        zoneRedundant: false
        sku: {
          name: 'S1'
          tier: 'Standard'
        }
      }
    ]
  }
  scope: resourceGroup(resourceGroupName)
  dependsOn: [
    sqlResourceGroup
  ]
}

Customize the code to align with your specific requirements, then execute it. You can do this by using: New-AzSubscriptionDeployment -Name deploymentName -Location canadacentral -TemplateFile .\main.bicep. After a few minutes, all the necessary resources will be deployed. We can see the Azure resources deployed within the resource group.

When checking Microsoft Entra ID, we can see that the SQL Administrators group has been created successfully, with me added as a member through the deployer().objectId function, which is exactly the expected behavior.

We can also see that the SQL Administrators Microsoft Entra ID group has been configured as the Microsoft Entra administrator for the Azure SQL Server. 😍

Now using the Query Editor we can access the Azure SQL Database since we have succesfully access to it using the Microsoft Entra Authentication.

What about the SQL Readers group? For this group, I chose to create the Microsoft Entra ID group as part of the Bicep deployment. However, I grant it access manually by using the following T-SQL statement to create the contained database user: CREATE USER [SQL Readers] FROM EXTERNAL PROVIDER;

We can also grant the SQL Readers group the db_datareader database role by using the following T-SQL statement: ALTER ROLE db_datareader ADD MEMBER [SQL READERS];. From now on, any user who is added to the Microsoft Entra ID group SQL Readers can connect to the Azure SQL Database using SQL Server Management Studio, provided they have network access to the database. Because the group is a member of the db_datareader role, its members can read data from all user tables and views in the database.

From this point, you know how to deploy an Azure SQL environment by using Azure Bicep and securely grant users access to Azure SQL databases through Microsoft Entra ID authentication. By adopting Infrastructure as Code, you can build repeatable, scalable, and consistent Azure SQL environments while minimizing manual configuration, reducing deployment time, and improving security. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story. That’s all for today. I’d love to hear your feedback, and I look forward to our next session. Until then, take care. ⭐️

Configuring Microsoft Entra ID Authentication for Azure SQL Database using Azure Bicep was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

A vessel is crossing the Strait of Hormuz. Its AIS signal updates in real time. A few minutes later, the vessel enters a high-risk zone.

For a maritime insurer, that single movement can trigger a chain of business questions:

Is the vessel still covered?
Does the policy include a war-risk exclusion?
Is there a warranty breach?
Which company operates the vessel?
What cargo is onboard?
What is the financial exposure right now?

Traditionally, answering those questions requires people to stitch together multiple systems: live vessel telemetry, geospatial boundaries, policy contracts, customer and cargo data, dashboards, and operational alerts.

This is exactly the kind of problem where enterprise AI needs more than retrieval. It needs business context.

In this post, I’ll show how I built a maritime risk “Company Brain” on Microsoft Fabric: an ontology-driven AI experience that connects live operational signals, semantic business relationships, and trusted policy documents so a Fabric Data Agent can answer risk questions in real time.

The disconnect between dynamic risk and static rules

Maritime insurance risk is constantly changing. A vessel’s location, speed, route, AIS status, nearby weather, cargo, and geopolitical exposure can all shift while the policy language governing that risk remains locked inside static PDF or Word documents.

That creates a practical gap for underwriters and risk analysts.

They may have the data, but the meaning is scattered across different systems:

- live AIS telemetry
- geospatial risk boundaries
- policy contracts and warranty clauses
- vessel, company, cargo, and policy master data
- analytical dashboards and operational alerts

Each system can answer part of the question. None of them, on its own, can answer the business question that matters:

Is this vessel exposed right now, what does the policy say, and what should we do about it?

That is the gap this demo is designed to close.

The solution: a geospatial Company Brain

The core idea behind the demo is simple: the AI agent should not guess, and it should not treat every question as a document search problem.

Instead, it should understand which source of knowledge is responsible for each part of the answer.

In this solution, Microsoft Fabric becomes the foundation for a maritime risk Company Brain: a connected intelligence layer that combines live vessel state, geospatial risk context, business relationships, and trusted policy language.

The result is an AI experience that can answer business questions such as:

- Where is this vessel right now?
- Is it inside a high-risk zone?
- Which company operates it?
- What cargo is it carrying?
- Which policy applies?
- What does the policy say about this situation?
- Is there a coverage issue or warranty breach?
- What action should the risk team take?

That is the shift: from a dashboard that shows live data to an agent that explains what live data means for the business.

High-level architecture

End-to-end architecture for the maritime risk Company Brain, built with Microsoft Fabric and Azure AI Search.

The architecture is centered on Microsoft Fabric, with Azure AI Search connected as the external knowledge retrieval layer for policy documents.

At a high level, the flow works like this:

1. Live AIS telemetry is received from AisStream.io and published into Fabric Eventstream.
2. Eventhouse stores the real-time vessel stream and uses KQL functions, update policies, and materialized views to enrich each position with geospatial risk context.
3. Lakehouse stores the business master data: vessels, companies, cargo, policies, and maritime risk zones.
4. GeoJSON risk-zone files define polygons such as Red Zone and Yellow Zone boundaries. These are transformed into structured tables that Eventhouse can use for geospatial enrichment.
5. Power BI semantic model and Fabric ontology describe the business relationships between vessels, operators, cargo, policies, and live vessel position.
6. Azure AI Search indexes policy documents so the agent can retrieve coverage, exclusion, warranty, deductible, and war-risk language.
7. Fabric Data Agent orchestrates the answer by routing each part of the question to the right source.
8. Fabric Map and Activator provide the visual and operational layers: live geospatial monitoring and alerting when a vessel enters a critical zone.

The key design choice is the vessel entity. The vessel, identified by MMSI, becomes the bridge between the operational world and the business world. Its latest position comes from Eventhouse, while its operator, cargo, policy, and coverage context come from the semantic model and ontology.

That lets the Data Agent answer questions that require both real-time state and business meaning.

How the solution works

After the architecture is in place, the implementation follows a simple flow: ingest live vessel telemetry, enrich it with geospatial risk context, connect it to business entities, and ground policy answers in indexed documents.

The live vessel data comes from AisStream.io, which provides a high-frequency feed of real-world AIS telemetry broadcast by ships across the world’s oceans. Each vessel is identified by an MMSI, or Maritime Mobile Service Identity: a unique 9-digit identifier that works like a digital license plate for a ship. In this solution, MMSI is the key that connects live telemetry in Eventhouse to the vessel entity in the ontology.

A Fabric notebook connects via WebSocket to AisStream.io and publishes live AIS events into Fabric Eventstream. Eventstream lands the telemetry in Eventhouse, where the raw maritimeAIS table stores vessel position, speed, heading, MMSI, ship name, and ingestion time.

Inside Eventhouse, KQL functions enrich each incoming position with geospatial risk context. The solution evaluates whether a vessel is inside a defined polygon using geo_point_in_polygon, then adds fields such as IsInZone, ZoneName, RiskLevel, and PremiumMultiplier. The enriched stream is stored in maritimeAIS_Enriched.

To make current-state questions fast and reliable, the solution creates the LatestShipPositionsEnriched materialized view. This view keeps only the most recent enriched position for each vessel, keyed by MMSI.

In parallel, the Lakehouse stores the business master data: vessels, companies, cargo, policies, and maritime risk zones. The risk zones are defined as GeoJSON files, transformed into a structured maritimezones table, and used by Eventhouse for geospatial enrichment.

The semantic model and Fabric ontology then connect the vessel to the business context around it: operator, cargo, policy, and latest live position.

Finally, policy documents are indexed in Azure AI Search so the Data Agent can retrieve relevant language about coverage, exclusions, warranties, deductibles, and war-risk conditions.

Together, these components allow the agent to move from a live vessel position to a business-level risk answer: where the vessel is, whether it is inside a risk zone, who operates it, what cargo it carries, which policy applies, and what the policy says about the current situation.

Why Ontology matters

One of the most important lessons from this demo is that enterprise AI needs more than retrieval.

RAG is powerful, but document search alone does not know which document matters. A policy clause may look relevant, but the agent still needs to know which policy belongs to which vessel, who operates that vessel, what cargo it carries, and whether the vessel is currently inside a risk zone.

That is where the ontology becomes critical.

In this architecture, the vessel is the central business entity. It connects the real-time operational world to the business and contractual world:

- latest vessel position from Eventhouse
- operator from the company master data
- cargo from the cargo master data
- policy from the insurance master data
- risk-zone status from geospatial enrichment

For example, if a user asks:

Is EAST_SIMULATED_TANKER_02 covered while crossing the Red Zone?

The agent should not start by searching all documents. It should reason through the business graph:

1. Find the vessel’s latest location in Eventhouse.
2. Check whether IsInZone is true and identify the RiskLevel.
3. Resolve the vessel to its company, cargo, and policy through the ontology.
4. Retrieve the relevant policy clauses from Azure AI Search.
5. Synthesize a grounded answer.

This is the difference between an AI assistant that can search and an AI agent that can understand context.

Building the Data Agent

The Fabric Data Agent is the orchestration layer for the experience.

In this demo, the agent is grounded in three complementary sources of knowledge:
- Eventhouse answers live operational questions: where the vessel is, whether it is inside a risk zone, and what the current risk state is.
- Fabric ontology and semantic model answer business-context questions: who operates the vessel, what cargo it carries, and which policy applies.
- Azure AI Search answers policy-evidence questions: what the insurance documents say about coverage, exclusions, warranties, deductibles, and war-risk conditions.

If the user asks where a vessel is, the agent should use Eventhouse.
If the user asks who owns a vessel or which policy applies, it should use the ontology.
If the user asks whether something is covered, excluded, or subject to a deductible, it should use Azure AI Search.
For complex questions, it should chain all three.

For example:

Is MV Ocean Voyager covered for a drone strike right now?

The expected reasoning path is:

1. Query LatestShipPositionsEnriched to find the vessel’s current location and zone status.
2. Use the ontology to find the policy linked to that vessel.
3. Search the policy index for drone strike, war exclusion, and high-risk zone language.
4. Return a grounded answer that cites both the live zone and the relevant contract clause.

The important point is that the agent is not inventing geospatial boundaries or legal interpretations. It is grounded in the live KQL materialized view, the ontology, and the indexed policy documents.

Real-time risk in action

For the demo, I used both real AIS data and simulated vessels.

The real AIS stream demonstrates live ingestion into Eventhouse. The simulation notebooks create controlled vessel itineraries that intentionally cross defined risk zones, which makes it easier to demonstrate how the risk state changes over time.

Two simulated vessels are included:

- SIMULATED_TANKER_01
- EAST_SIMULATED_TANKER_02

Each simulated vessel is enriched with demo insurance context such as company, cargo, hull value, and policy ID. One vessel is associated with a Hull & Machinery policy, while another is associated with a War Risk policy.

As the simulated vessels move through the Strait of Hormuz scenario, the Data Agent’s answers change.

When a vessel is outside a risk zone, the agent can report standard coverage and no active breach. When the same vessel enters the Red Zone, the agent can flag elevated exposure, identify the critical zone, apply the premium multiplier, retrieve the relevant policy language, and explain the potential warranty or coverage impact.

This is the key experience: the same business question receives a different grounded answer because the operational reality changed in real time.

That is what makes the pattern powerful. The agent is not just answering from static knowledge; it is reasoning over the current state of the business.

Visualizing live maritime risk with the Fabric Map item

The Fabric Map item provides the spatial operating picture for the demo.

While the Data Agent answers natural-language business questions, the map lets users see the same risk scenario visually: live vessels moving across geographic boundaries, risk-zone polygons, and changing exposure over time.

In this solution, the map brings together three layers:

- live vessel positions from Eventhouse
- maritime risk-zone polygons from Lakehouse GeoJSON data
- business context from the ontology, where each vessel connects to operator, cargo, policy, and current location

This is especially useful for real-time risk monitoring. An underwriter can inspect vessels approaching a high-risk polygon, filter by operator or cargo type, zoom into a corridor such as the Strait of Hormuz, and then ask the Data Agent a grounded follow-up question about coverage, warranties, or financial exposure.

In other words, Fabric Map provides the spatial view, while the ontology and Data Agent provide the business meaning behind what the user sees.

From dashboard to decision

Dashboards are still valuable. They show what is happening.

But the Data Agent adds a different interaction model. It helps users ask what the situation means.

A dashboard can show that a vessel is in a particular location. An ontology-driven agent can connect that location to the vessel’s operator, cargo, policy, current risk zone, and relevant contractual language.

That distinction matters for underwriters and risk teams. They do not only need to see that something happened; they need to understand whether it creates a coverage issue, whether the cargo changes the severity, whether the operator has a high-risk profile, and whether the policy includes a relevant exclusion or warranty condition.

With the ontology-driven approach, the agent can connect those dots and turn live telemetry into a business-level risk explanation.

Adding operational alerts with Activator

The solution also includes an Activator scenario, represented in the repository as a Reflex item called RedAlertActivator.

This adds an operational layer to the pattern. Once live data is enriched with geospatial and business meaning, it can trigger action rather than only support analysis.

For example, when a vessel enters a critical zone, the system can move beyond passive monitoring and activate an alerting flow.

That creates a practical enterprise pattern:

1. Eventstream ingests live data.
2. Eventhouse enriches the data in real time.
3. Materialized views expose the latest risk state.
4. Power BI and Fabric Map visualize the fleet.
5. Data Agent explains the business meaning.
6. Activator triggers operational action.

This is where the Company Brain becomes more than a question-answering interface. It becomes part of the operating model.

Example questions for the Data Agent

Here are some of the prompts I used to demonstrate the solution:

Where is SIMULATED_TANKER_01 right now, and is it in a risk zone?

What is the total risk assessment for EAST_SIMULATED_TANKER_02?

Is this vessel in breach of any policy warranty?

Which of my ships are currently inside a high-risk zone?

What does the policy say about war-risk zones for this vessel?

Who operates this vessel, what cargo is it carrying, and which policy applies?

These prompts demonstrate different agent behaviors.

Some are pure live telemetry questions. Some are ontology traversal questions. Some are policy retrieval questions. The most interesting ones require the agent to orchestrate all three.

What I learned building it

The biggest learning from this demo is that the value of enterprise AI does not come only from the model.

It comes from grounding the model in the right architecture.

A strong enterprise AI architecture needs:

Live operational context

For this demo, that context came from AIS telemetry streaming through Eventstream into Eventhouse.

Semantic business context

The ontology gave the AI a way to understand relationships between vessels, companies, cargo, policies, and zones.

Trusted knowledge

Azure AI Search gave the agent access to policy documents and legal clauses without forcing the user to manually read through dense contracts.

Clear routing and orchestration

The Data Agent needed explicit instructions about when to use Eventhouse, when to use the ontology, and when to use AI Search.

Real-time state

The LatestShipPositionsEnriched materialized view was essential because risk assessment depends on the latest vessel position, not historical telemetry.

Together, these pieces create something much more useful than a generic chatbot.

They create an AI agent that can reason over the business.

Why this pattern matters

Although this demo focuses on maritime insurance, the pattern applies to many industries.

In manufacturing, the central entity might be a machine or production line.

In healthcare, it might be a patient journey.

In retail, it might be a product, supplier, or store.

In energy, it might be an asset, grid node, or maintenance event.

The common pattern is the same:

1. Capture live operational signals.
2. Enrich them with domain-specific logic.
3. Model business entities and relationships.
4. Ground the AI in trusted documents.
5. Expose the experience through a natural-language agent.
6. Trigger alerts or actions when business conditions change.

That is the essence of the Company Brain.

It is not just an AI assistant connected to data. It is an AI layer that understands how the business is connected.

Final thoughts

The Fabric IQ demo at the Microsoft AI Tour was a great opportunity for me to show how Microsoft Fabric can bring together real-time analytics, semantic modeling, ontology, document intelligence, and AI agents into a single architecture.

The most exciting part is the shift in user experience.

Instead of asking analysts to manually inspect telemetry, dashboards, policies, and risk rules, we can let them ask business questions directly:

“Which vessels are exposed right now, why, and what does the policy say?”

That is the promise of ontology-driven AI.

When your data platform understands your business entities, your AI agent can do more than retrieve information. It can reason across live events, business relationships, and trusted knowledge.

That is how we start building the Company Brain.

Resources

The full demo repository is available here:

https://github.com/dorirabin/fabricdemo/tree/fabriciq-maritimedemo

The repo can be automatically deployed in your Fabric Workspace using the fabric cicd python library
The full demo repository includes the Fabric assets, notebooks, ontology, Data Agent configuration, sample policy documents, reports, maps, and Activator scenario used to build the solution.

From Live Signals to Smarter Risk: Building a Company Brain on Microsoft Fabric was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

As organizations roll out AI coding assistants like GitHub Copilot, engineering leaders quickly run into a blind spot:

How do we actually measure adoption, performance, and cost efficiency?

Thanks to recent enterprise capabilities, GitHub Copilot natively supports OpenTelemetry (OTLP) export for client apps (like VS Code and the Copilot CLI). This means you can funnel telemetry directly to an OpenTelemetry Collector and visualize everything from token consumption to response latency.

Depending on your organization’s compliance, scale, and infrastructure goals, there are three primary paths to route this data. This guide provides clean, production-ready configurations for each approach.

Link to repository and official documentation on the bottom of this article.

The Architecture at a Glance

The setup relies on a standard push observability pattern:

[ Developer Machines ] ──(OTLP/HTTP)──> [ OTel Collector ] ──> [ Observability Backend ] ──> [ Grafana ]
  - VS Code Extension                                            - Local: Prometheus / Tempo
  - Copilot CLI                                                  - Azure: Azure Monitor / App Insights + OTLP support

• The Clients: VS Code and CLI capture runtime metrics (input/output tokens, time-to-first-token, exceptions).
• The Bridge: An OpenTelemetry Collector-Contrib deployment acts as the central router, parsing metrics, handling authentication, and injecting user metadata.

Step 1: Enable OTel on the Client

To force the GitHub Copilot extension to emit telemetry, developers (or platform teams using enterprise-managed settings) need to configure their client settings.

Add the following to your VS Code settings.json:

{
  "github.copilot.chat.otel.enabled": true,
  "github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318",
  "github.copilot.chat.otel.exporterType": "otlp-http",
  "github.copilot.chat.otel.captureContent": false
}

Security Note: Keep captureContent set to false in production to ensure actual prompt/response code snippets are not bundled into the telemetry attributes.

Step 2: Choose Your Collector Pipeline

Here are the three distinct configuration options depending on your hosting environment.

Option A: The Local Validation Stack

For quick, self-contained local testing and evaluation, route your telemetry straight into local Prometheus and Tempo instances.

Otel Collector configuration YAML with local Tempo instance:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  otlp/tempo:
    endpoint: "tempo:4317"
    tls:
      insecure: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/tempo]

Option B: Route to Application Insights via Connection String

This is the standard, generally available configuration. The Collector leverages the official azuremonitor exporter to ship telemetry directly to your Application Insights workspace using its unique connection string.

Otel Collector configuration YAML with azuremonitorexporter connected to Application Insights instance:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024

exporters:
  azuremonitor:
    connection_string: "InstrumentationKey=<YOUR-KEY>;IngestionEndpoint=https://<region>.in.applicationinsights.azure.com/;LiveEndpoint=https://<region>.livediagnostics.monitor.azure.com/"

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [azuremonitor]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [azuremonitor]

Option C: Ingest OTLP Data into Azure Monitor with Entra ID Authentication

This enterprise-grade setup targets Azure Monitor’s cloud native OTLP ingestion pipeline. By utilizing Microsoft Entra ID (azure_auth) to secure transport and custom processors to stamp individual developer identities onto each metric, you can route your logs, traces, and converted delta metrics securely over direct Azure endpoints.

Otel Collector configuration YAML with otlphttp/azuremonitor exporter connected to Application Insights instance and leveraging azure_auth extension:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  # Stamping specific user identifiers onto telemetry fields
  resource/user_identity:
    attributes:
      - key: enduser.id
        value: ${COPILOT_USER_EMAIL}
        action: upsert
      - key: github.copilot.user.email
        value: ${COPILOT_USER_EMAIL}
        action: upsert
        
  attributes/user_identity:
    actions:
      - key: enduser.id
        value: ${COPILOT_USER_EMAIL}
        action: upsert
      - key: github.copilot.user.email
        value: ${COPILOT_USER_EMAIL}
        action: upsert

  memory_limiter:
    check_interval: 1s
    limit_mib: 512
    spike_limit_mib: 128

  # Converts cumulative metrics to delta formats required by Azure Monitor
  cumulativetodelta:

  batch:
    timeout: 5s
    send_batch_size: 1024

extensions:
  health_check:
  azure_auth:
    use_default: true
    scopes:
      - https://monitor.azure.com/.default

exporters:
  otlphttp/azuremonitor:
    traces_endpoint: ${AZURE_MONITOR_TRACES_ENDPOINT}
    logs_endpoint: ${AZURE_MONITOR_LOGS_ENDPOINT}
    metrics_endpoint: ${AZURE_MONITOR_METRICS_ENDPOINT}
    auth:
      authenticator: azure_auth

service:
  extensions: [health_check, azure_auth]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resource/user_identity, attributes/user_identity, memory_limiter, batch]
      exporters: [otlphttp/azuremonitor]
    logs:
      receivers: [otlp]
      processors: [resource/user_identity, attributes/user_identity, memory_limiter, batch]
      exporters: [otlphttp/azuremonitor]
    metrics:
      receivers: [otlp]
      processors: [resource/user_identity, memory_limiter, cumulativetodelta, batch]
      exporters: [otlphttp/azuremonitor]

Note: on Option B and C we enriched metadata with user info, and it will propagate to span attributes of our traces (as enduser.id).

Step 3: Visualize with Grafana

Once the telemetry starts landing in your designated backend, you can visualize the data in Grafana. If you run your stack on Azure (either via Option B or Option C), you can leverage Azure Managed Grafana to directly query Log Analytics workspaces or Application Insights endpoints.

Key Dashboards to Build:

1. Token Efficiency: Track input vs. output tokens over time, broken down by model (e.g., GPT-4o vs. Claude 3.5 Sonnet).
2. Model Latency: Analyze Time to First Token (TTFT) alongside overall response durations.
3. Developer Engagement: Group active calls by the injected enduser.id or github.copilot.user.email attributes to map organizational usage.
4. Reliability: Keep an eye on API throttling, rate limits, timeouts, or extension exceptions.

Summary & Next Steps

Setting this up ensures that your organization’s AI investment isn’t a black box. You gain immediate visibility into performance bottlenecking, developer adoption, and detailed LLM metrics.

For a complete working setup — including pre-packaged Docker Compose environments, ready-to-import Grafana dashboards, and deployment scripts — head over to the companion repository:

👉 GitHub Repository: lyantovski/github-copilot-otlp-grafana

Important: While this guide provides the foundational blueprints for local and Azure-native pipelines, API endpoints, schema mappings, and authentication scopes (especially regarding Azure’s OTLP preview endpoints) are subject to change.

For advanced configurations, network hardening, or troubleshooting edge cases, always cross-reference your implementation with the official documentation.

Microsoft and Github official docs reference:

Monitor AI coding agents with Grafana | Microsoft Learn

Ingest OTLP Data into Azure Monitor with OTel Collector — Azure Monitor | Microsoft Learn

Collect and analyze OpenTelemetry data with Azure Monitor (Preview) — Azure Monitor | Microsoft Learn

Enterprise-managed OpenTelemetry export for VS Code and CLI — GitHub Changelog

Monitoring GitHub Copilot at Scale with OpenTelemetry (OTLP) and Grafana was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Azure API ManagementでAnthropic Messages APIのプロンプトログを取得する

Query from a customer

The client, who had enquired in the past, asked me about the following topic.

I understand that Anthropic models are now available via Microsoft Foundry. If we were to deploy an Anthropic model as a backend service for API Management, would it be possible to collect logs and track token consumption? I understand that this is possible with OpenAI-compatible APIs, but I’d like to know the current status of support for the Native API.

Fail to capture prompt logs for LLM APIs deployed behind Azure API Management

It appears that the prevailing opinion is that, given the extended period since the models’ initial release, and their subsequent availability via Foundry, the necessary adjustments must have been made. It is true that the situation has changed, so it would be advisable to check.

Supportability

It is explicitly stated in the documentation that the Messages API of the Anthropic model is supported in API Management v2 as part of the AI Gateway feature of the same system.

Use the AI gateway to manage a wide range of AI endpoints, including:
Language model APIs that conform to one of the following API schemas:
- OpenAI Chat Completions or Responses API
- Anthropic Messages API (currently supported in API Management v2 tiers)
- Google Vertex AI API (rebranded into Gemini Enterprise Agent Platform)

AI gateway capabilities in Azure API Management

The term ‘Vertex AI API’ refers to the native Gemini inference API format that has been migrated to the Gemini Enterprise Agent Platform, rather than the full suite of models currently available on the Gemini Enterprise AI Platform.

While the feature appears to be operational from this document, this investigation aims to verify its functionality.

Environment

I would like to confirm that the environment remains unchanged since the previous occasion. On this occasion, however, I opted for Haiku instead of Opus. All other conditions remain unchanged.

APIM: Standard V2
- This can also be achieved with other V2 SKUs
- Diagnostic settings are already configured

LLM: Claude Haiku 4.5 (20251001)
- Messages APIs are used.

Messages - Claude API Reference

As before, since Anthropic has not published the OpenAPI Spec, I have manually registered the Messages APIs with APIM. The API key can be configured in either the ‘Backends’ or the ‘Policies’ section. Please be advised that the ‘Header key’ differs when configuring the API key.

This concludes the environmental setup.

Let’s try it!

For this project, I chose to utilise the following requests. Please note that I have sent one request with streaming enabled and another with streaming disabled (by changing "stream": false in the request below, or by removing stream). As the primary objective is to verify the collection of logs, I did not conduct an evaluation of the output results.

{
  "model": "claude-haiku-4-5-20251001",
  "max_tokens": 64000,
  "stream": true,
  "system": "You have an expertise in Azure architecture. Your responsibility is to articulate and elaborate queries and provide the best architecture following Azure Well-architected Framework.",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "SharePoint OnlineからファイルをBoxに移送する手段として、一番コストが安い方法を提示して。"
        }
      ]
    }
  ],
  "thinking": {
    "type": "enabled",
    "budget_tokens": 63999
  }
}

Verification

In Log Analytics Workspace, I checked whether any logs had been recorded in ApiManagementGatewayLlmLog.

When streaming is enabled

When streaming is disabled

It is evident that in both cases, the logs and token consumption are being written to the log without any issues. When streaming is enabled, it is also evident that IsStreamCompletion is set to true.

The follow-up enquiry arrives

As always, the follow-up enquiry was received. I can understand why they would like to know.

Could you kindly confirm whether token usage is logged in relation to Prompt Cache? It would be appreciated if the item could be included in the logs. However, should this not be possible, it would be satisfactory to retrieve it via custom metrics.

The log snippet below, which is from approximately the third to the seventh line, shows cache-related token usage. If streaming is enabled, a message similar to the one below should be sent in the final delta. Their primary concern is whether this information can be verified in any way.

"usage": {
    "input_tokens": 3,
    "cache_creation_input_tokens": 184,
    "cache_read_input_tokens": 10564,
    "cache_creation": {
        "ephemeral_5m_input_tokens": 184,
        "ephemeral_1h_input_tokens": 0
    },
    "output_tokens": 160,
    "service_tier": "standard",
    "inference_geo": "not_available"
}

Verification

1. Does it appear in the logs?

Unfortunately, the answer is no. As previously stated, ApiManagementGatewayLlmLog does not contain this field, therefore it is not stored in the log table (we hope this will be addressed in future updates).

2. Can it be captured via custom metrics?

The llm-emit-token-metric policy permits the transmission of custom metrics to Application Insights. However, the question remains as to whether token usage can be verified via the customMetrics table in Application Insights. The answer to this is ‘some information is available’. However, please note that certain details are missing, specifically cache_creation_input_tokens and related information.

When streaming is enabled

Please find below a summary of the contents of the table customMetrics. The data contained within the red rectangle illustrates the delta values as at 09:54:01 (UTC) on 17 June 2026.

The following comparison reveals that cache_creation_input_tokens has not been retrieved, but cache_read_input_tokens has.

When streaming is disabled

Similarly, I checked this when streaming was disabled. Please find below a summary of the contents of the table customMetrics.

The following details are provided in relation to token usage at 10:26:01 (UTC) on 17 June 2026.

Although the values for ephemeral_5m_input_tokens and ephemeral_1h_input_tokenswhich cache_creation_input_tokens consists of have not been captured, the rest remain unchanged and captured even when streaming was enabled.

Please note that ...

The llm-emit-token-metric policy is designed to send metrics each time an event occurs. However, it should be noted that the resolution of Application Insights is 60 seconds. Therefore, please be aware that Application Insights are only able to output data at intervals of at least 60 seconds, i.e. every minute. Consequently, if the same dimension is used, all metrics received within that 60-second period will be aggregated. To keep things simple, I have created a test application that cycles through each turn every 60 seconds to verify the behaviour.

Using Azure API Management to obtain Anthropic Messages APIs logs was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the release of Azure Bicep v0.43.1, two new functions have been introduced: like() and distinct(). In this blog, I will explain how these new functions work and showcase several useful real world scenarios where you can use them in your Bicep deployments. 💪🏻

Like Function

The like() function in Bicep is used to compare a string against a pattern. It returns true when the value matches the specified pattern and false when it does not. Let’s start with a simple example:

param parInput string = 'Hello, World!'
 
output outOutput bool = like(parInput, '*World*')

In this example, the like() function checks whether the value of parInput contains the word World. The wildcard character *means that any characters before or after World are allowed. Since the string Hello, World! contains the word World, the output will return true.

In this example, the like() function is used to check whether the workloadName variable contains the value prod. The workloadName is dynamically created by combining the string xyz- with the value of the parEnvironment parameter. The result of this comparison is stored in the applyLock variable. If the workload name contains prod, the expression evaluates to true. As a result, the resource lock is deployed.

param parEnvironment string

var workloadName = 'xyz-${parEnvironment}'
var applyLock = like(workloadName, '*prod*')

resource lock 'Microsoft.Authorization/locks@2020-05-01' = if (applyLock) {
 name: 'cannot-delete'
 properties: {
  level: 'CanNotDelete'
  notes: 'Production protection'
 }
}

We can see that the output is true because our parEnvironment variable has been assigned the value prod.

In this example, we use the like() function to determine whether the parEnvironment parameter contains the value prod. The parameter is limited to the values prod, test, and acc by using the allowed decorator.

@allowed([
  'prod'
  'test'
  'acc'
])
param parEnvironment string

module appi 'br/public:avm/res/insights/component:0.7.1' = if (like(parEnvironment, '*prod*')) {
  params: {
    name: 'appi-${parEnvironment}'
    workspaceResourceId: 'idHere'
  }
}

Distinct Function

The next function is distinct(). This function can be very useful when working with arrays that may contain duplicate values. The distinct() function returns a new array that contains only the unique elements from the input array. Any duplicate values are removed automatically.

Let’s start with a simple example:

param fruits array = [
 'apples'
 'bananas'
 'apples'
]

var normalizedFruits = distinct(fruits)

output ouFruits array = normalizedFruits

In this example, the fruits array contains the value apples twice. The distinct() function filters out the duplicate value and creates a new array that only contains unique entries. This function is especially useful when processing tags, role assignments, IP ranges, or any other configuration where duplicate values should be avoided.

In this example, the distinct() function is used to remove duplicate IP ranges from an array of IP groups. Each IP group contains a name and a list of IP addresses. First, a new array called ipAddresses is created using a for expression. This extracts the first IP address from each IP group object. Next, the distinct() function filters out duplicate IP ranges and stores only the unique values in the normalizedIpGroupsvariable.

param ipGroups array = [
  {
    name: 'ipGroup1'
    ipAddresses: [
      '192.168.10.0/24'
    ]
  }
  {
    name: 'ipGroup2'
    ipAddresses: [
      '192.168.5.0/24'
    ]
  }
  {
    name: 'ipGroup3'
    ipAddresses: [
      '192.168.10.0/24'
    ]
  }
]

var ipAddresses = [for ipGroup in ipGroups: ipGroup.ipAddresses[0]]
var normalizedIpGroups = distinct(ipAddresses)

module ipGroup 'br/public:avm/res/network/ip-group:0.4.0' = [
  for ipGroup in normalizedIpGroups: {
    params: {
      name: ipGroup.name
      ipAddresses: ipGroup.ipAddresses
    }
  }
]

This can be very useful in scenarios where multiple teams or workloads provide overlapping IP ranges. By removing duplicate entries before deployment, you can avoid unnecessary resources and keep your configuration cleaner and easier to maintain.

That’s all for today. As you could see, the new Azure Bicep functions help you create cleaner, more flexible, and easier to maintain deployments. Whether you are validating naming conventions with like() or removing duplicate values with distinct(), these functions can simplify many real world deployment scenarios. The Azure Bicep code is available in my GitHub repository: GitHub — brianveldman/azure-bicep. Feel free to star the repository and clap for this story and let me know if you have any feedback. I look forward to seeing you in the next session. Until then, take care! ❤️

The NEW Bicep Like and Distinct Functions ✨ was originally published in Microsoft on Medium, where people are continuing the conversation by highlighting and responding to this story.