Back to Blog
Published:
Last Updated:
Fresh Content
ERP Write-Back & IntegrationChapter 10

Did the Synapse trusted-services firewall exception retire on 1 August 2026?

8 min read
1,909 words
high priority
Muhammad Mudassir

Muhammad Mudassir

Founder & CEO, Cognilium AI

TL;DR

The retirement was dated 1 August 2026. On the day, Microsoft's transition FAQ still states it in the future tense on a page revised in July, while a Microsoft Q&A answer describes a move to 2027. Here is what nine Microsoft pages say, the date each one carries, and what to check in your own tenant.

Did the Synapse trusted-services firewall exception retire on 1 August 2026?

Microsoft's published documentation says it does — today, in the future tense, on a page last revised in July. A Microsoft Q&A answer says the date moved to 2027. One of those two is documentation. Neither is the notification sent to your tenant.

The nine Microsoft pages we opened today do not settle it, and their dates are why

The retirement is Microsoft's own wording. The Power Apps transition FAQ states it directly:

"the trusted services function that allows Azure Synapse Analytics to access Azure Storage accounts and Azure Key Vault using a managed identity and firewall exception will be retired on 1 August 2026" — Azure Synapse Link transition FAQ

That sentence is future tense. The page carrying it declares ms.date: 2026-07-23 and updated_at: 2026-07-24 — the two revision stamps Microsoft publishes on every Learn article — so on 1 August 2026 it records what was true when it was written eight days earlier.

A Microsoft Q&A thread, answered on 9 July 2026 by a moderator badged Microsoft External Staff, says the retirement "has been postponed" — a new workspace-level security setting before 1 March 2027, the default changing to network-scoped access on 1 June 2027. The questioner cites a tenant notification ID, ZQ53-8KZ.

So the answer for a CIO today: those two channels disagree, and the one addressed to you is in your own tenant. Status is [DEPR] — a retirement date is published and Microsoft tells you to move — but the date itself is what is in dispute.

Every page below, and the date it carries

All nine were opened on 1 August 2026. The dates are the pages' own.

  • Azure Synapse Link transition FAQ — ms.date: 2026-07-23 · updated_at: 2026-07-24 · What it says about the retirement: States it: retired 1 August 2026, plus a three-step remediation
  • Choose finance and operations data in Azure Synapse Link — ms.date: 2026-07-06 · updated_at: 2026-07-20 · What it says about the retirement: Silent on the exception and the retirement
  • Azure Synapse connectivity settings — ms.date: 2025-03-18 · updated_at: 2026-06-02 · What it says about the retirement: Silent; covers public network access and minimum TLS
  • Managed virtual network (Azure Synapse) — ms.date: 2025-01-22 · updated_at: 2026-02-04 · What it says about the retirement: Silent; states the workspace network choice is immutable
  • Managed private endpoints (Azure Synapse) — ms.date: 2024-11-15 · updated_at: 2025-09-09 · What it says about the retirement: Silent; states these endpoints need a managed virtual network
  • Connect to a secure storage account (Azure Synapse) — ms.date: 2025-02-05 · updated_at: 2025-09-09 · What it says about the retirement: Silent; documents the resource instance route
  • Grant permissions to managed identity in Synapse workspace — ms.date: 2025-02-11 · updated_at: 2025-10-24 · What it says about the retirement: Silent
  • Azure Storage firewall rules and network access — ms.date: 2026-07-06 · updated_at: 2026-07-06 · What it says about the retirement: Silent; lists trusted service exceptions as one of four rule types
  • Trusted Azure services for Azure Storage network security — ms.date: 2025-06-24 · updated_at: 2026-05-07 · What it says about the retirement: Silent; still lists Microsoft.Synapse/workspaces as trusted

The retirement appears on one of the nine. The other eight — seven Azure Synapse and Azure Storage pages documenting the mechanism, plus the Power Apps page on choosing finance and operations data — carry no notice of it — ordinary latency between a subscription-level notification and a documentation set, and the reason a summary written from any single one of them is wrong in a different way.

What the exception is, and what loses its route without it

Azure Storage offers four kinds of network rule: virtual network rules, IP network rules, resource instance rules, and trusted service exceptions (Microsoft Learn).

The last is the one in question. It exists because, in Microsoft's words, "Synapse operates from networks that can't be included in your network rules" (Microsoft Learn).

Azure Synapse Analytics is still on that list as Microsoft.Synapse/workspaces (Microsoft Learn).

This reaches Dynamics 365 estates because Azure Synapse Link for Dataverse with finance and operations data [GA] writes into your storage account (Microsoft Learn).

Firewall that account, reach it on a managed identity plus the exception, and the feed rests on a network allowance rather than on anything inside Finance and Operations. A change here stops an ERP data feed without touching the ERP.

Microsoft's remediation begins with the word "Create"

The FAQ's three steps look like configuration. Step one is not.

  • Managed virtual network — Microsoft's wording: "Create a Synapse workspace with a managed virtual network" · What it costs you: A workspace, not a setting — see below
  • Managed private endpoint — Microsoft's wording: "Create a managed private endpoint for your storage account (ADLS Gen 2)" · What it costs you: An approval workflow on the storage owner's side
  • Two network switches — Microsoft's wording: Allow Azure services and resources to access this storage account, and the same setting on the workspace · What it costs you: "Both settings must be enabled for Azure Synapse Link to connect successfully"

Step one says create for a reason:

"You can't change this workspace configuration after the workspace is created. For example, you can't reconfigure a workspace that doesn't have a Managed workspace Virtual Network associated with it and associate a Virtual Network to it." — Managed virtual network

And managed private endpoints "are only supported in Azure Synapse workspaces with a Managed workspace Virtual Network" (Microsoft Learn).

So for a workspace built without one, the documented path is a new workspace and a new Synapse Link profile — Microsoft states that changing the data lake associated with a profile, or its configuration options, isn't supported. That is a change window, not a Tuesday afternoon. Which is the best reason there is to establish the real date first.

The narrower route, and the question these nine pages leave open

Microsoft documents a second way in, and prefers it: "We recommend that you use resource instance rules to grant access to specific resources" (Microsoft Learn). The steps name one workspace rather than a service class:

"In the Resource instances section, select Microsoft.Synapse/workspaces as the Resource type and enter your workspace name for Instance name." — Connect to a secure storage account

Whether that narrower rule therefore sits outside the retirement is the obvious question, and none of the nine pages above answers it either way.

Worse, that same secure-storage page files those steps under a heading calling it access "as a trusted Azure service" — so the two terms are not cleanly separated even in Microsoft's own prose. Do not assume the narrower rule survives because it is narrower.

The counter-argument: "the Q&A answer is clear enough"

Fair. It is specific, names a mechanism and three dates, and is badged by a Microsoft moderator on a Microsoft property. If it is right, checking is the only action most estates need today.

But it is one of two replies in a support thread, not a revision to the documentation. The other, from a volunteer moderator, says the notification can't be verified against public documentation and advises treating the published date as authoritative until Microsoft confirms otherwise in writing. And the transition FAQ still carried 1 August 2026 when this was written. And its timeline traces back to a tenant notification, so the authoritative copy went to your subscription and your own admins can retrieve it. Nobody needs a stranger's summary of a message addressed to them.

What to check today

  1. Find the notification. Azure portal → Service Health → Health advisories, then search your notification history for the Synapse transition message. The Q&A questioner cites ID ZQ53-8KZ for the later one.
  2. Establish whether you are in scope. Microsoft's scope is narrow: a workspace reaching Azure Storage or Azure Key Vault on a managed identity and a firewall exception on the target. Open the storage account's Networking → Firewalls and virtual networks and check whether an exception is on, and whether a resource instance rule already names the workspace.
  3. Check the workspace for a managed virtual network. Its Overview blade shows it, and the answer decides whether remediation is a setting or a rebuild.
  4. Test the path instead of reasoning about it. If a Synapse Link profile carrying finance and operations tables is live, confirm today's delta landed. A network cut surfaces as a sync failure, not as a Dynamics 365 error.
  5. Record the date you found, with its source. Whichever one governs, the next person to ask should not have to repeat this.

Where we would draw the line

We would not rebuild a Synapse workspace this week on the strength of a forum answer, and we would not dismiss the retirement on one either. Same error, opposite directions: acting on a summary instead of the record addressed to you.

We would also not take this decision at all. Network topology, private endpoints and storage firewall policy belong to your platform team and your implementation partner, and that layer is precisely where we stay out.

What we own is the consequence. An optimizer whose features arrive through a lake is only as current as the network allowance underneath it, so the question we ask before any build is which path the data takes and who controls it.

Dynamics 365 stays the system of record; the Optimizer is the system of intelligence beside it. And the optimal decision is worthless if the feed behind it went quiet in July because a notification went unread.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If an Optimizer of yours reads Dynamics 365 data through a lake, the network path underneath it is part of its uptime. Book a fifteen-minute call and we will walk your data path with you — which surface it reads, who controls the allowance, and what breaks quietly. No deck. https://cognilium.ai

Sources

Sources

Share this article

The work behind this series
AI optimization apps for Dynamics 365

The write-back mechanism every optimizer shares — read the system of record, compute the decision, return it behind an approval step.

Muhammad Mudassir

Muhammad Mudassir

Founder & CEO, Cognilium AI

Mudassir Marwat's argument is that ERP systems record decisions they never optimise.

Founder & CEO of Cognilium AI; 37 AI agents in production across four products; 4 production AI products built and operated; three clouds in production (AWSGCPAzure)
Agentic AIRAG → GraphRAG retrievalVoice AIMulti-Agent Orchestration
ContactView Profile
Next in this series
Fabric link or Synapse Link — which analytics path for Dynamics 365 data?
Chapter 11 · 11 min
In short

Key takeaways

  • On the day a retirement is dated, the announcing page's own ms.date is part of the answer, not metadata. A future-tense sentence on a page revised days or weeks earlier records what was true when it was written.
  • Microsoft's published remediation for the Synapse trusted-services firewall exception starts by creating a Synapse workspace with a managed virtual network, and Microsoft's managed virtual network page states this configuration can't be changed after a workspace is created — so for some estates the remediation is a new workspace rather than a setting.
  • A tenant notification and a public documentation page are different channels with different latencies. Where they disagree, the notification delivered to your subscription is the copy addressed to you, and your admins can retrieve it from Service Health.
  • Azure Synapse Link for Dataverse writes into a storage account you own, so an analytics feed from Dynamics 365 can be cut by an Azure Storage network change that touches no Finance and Operations configuration at all.
  • Of the nine Microsoft pages opened for this article, the retirement appears on the transition FAQ alone; the Azure Synapse and Azure Storage pages documenting the mechanism carry no notice of it.
What goes wrong

Common mistakes to avoid

  • Restating a knowledge base's future tense as today's fact. "Retires on 1 August 2026" published on 1 August 2026 is either stale by hours or simply wrong.
  • Treating a Microsoft Q&A reply as a revision to the documentation. It is a moderator's answer on a support thread; the transition FAQ still carried the original date when this article was written.
  • Rebuilding a Synapse workspace before confirming the estate is in scope. Microsoft's scope is a managed identity combined with a firewall exception on the target Storage or Key Vault, which is narrower than every workspace that talks to storage.
  • Filing this as a Dynamics 365 change. It is an Azure Storage and Azure Key Vault network change; the ERP data feed sits downstream of it and surfaces as a Synapse Link sync failure rather than a Dynamics 365 error.