Braintree Insights | 20 August 2026
Fabric changes a default on Sunday
From 23 August 2026, Microsoft Fabric enables Item Recovery by default for tenants that never configured it, with a three-day window. Microsoft’s documentation states a seven-day default and a seven-to-ninety-day range, so the two pages disagree and the reliable move is to set an explicit value.

What changed
Microsoft’s notice, published on 10 August 2026, states that from 23 August 2026 Fabric will enable Item Recovery by default for tenants that have not explicitly configured the setting, and that supported item types will have a three-day recovery window by default. The setting is administered in the Fabric admin portal under Tenant settings, Item Recovery. This is a scheduled change rather than a new announcement, and it is covered here because the date falls three days after publication.
The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.
What the term means in plain language
Item Recovery is a Fabric tenant setting that governs soft delete for individual items. When it is on, a deleted supported item enters a retention period during which workspace contributors, members and admins can restore it from the workspace recycle bin. When it is off, Microsoft states that Fabric does not retain a deleted item at all.
This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.
Why this matters to a South African organisation
South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.
The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.
The hidden exposure
From 23 August 2026, Microsoft Fabric enables Item Recovery by default for tenants that never configured it, with a three-day window. Microsoft’s documentation states a seven-day default and a seven-to-ninety-day range, so the two pages disagree and the reliable move is to set an explicit value.
Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.
Decision path
The change is protective in net terms, because the current behaviour for an unconfigured tenant is that an individually deleted item is not retained at all. The decision it forces is about the number rather than the feature. Microsoft’s notice states a three-day default for tenants without an explicit setting, while the current Learn documentation states that turning the setting on gives a seven-day default and permits any value from seven to ninety days. Braintree does not reconcile the two pages and does not predict which value a given tenant will receive. Setting an explicit, approved retention value removes the ambiguity entirely and makes the tenant’s recovery window a decision on record rather than an inherited default.
Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.
Technical test plan
Configuring the setting requires the tenant admin role. Restoring a deleted item requires at least Workspace Contributor; permanently deleting a recoverable item requires Workspace Admin. Restore is available through the workspace recycle bin or the REST API at POST /v1/workspaces/{workspaceId}/recoverableItems/{itemId}/recover. Microsoft records an important restore constraint: if a new item with the same name as the soft-deleted item exists in the same workspace, the recovery fails until the existing item is renamed. Microsoft also states that after a permanent deletion OneLake retains the data for a further seven days during which it cannot be restored. Recovery applies to supported item types only, and Microsoft states that recovered items retain their original properties, settings and permissions.
Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.
Primary owner
Primary owner: Fabric tenant admin with the data platform owner.
The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.
Action within seven days
Action within seven days: Before 23 August, open Tenant settings, Item Recovery, and set an explicit approved retention value rather than inheriting a default. Then delete and restore one non-production supported item to prove the path works.
Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.
Evidence to retain
Evidence to retain: Before-and-after capture of the tenant setting, the approved retention value and who approved it, the test item ID and the restore result.
Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.
Frequently asked questions
What happens on 23 August?
Microsoft states that Fabric will enable Item Recovery by default for tenants that have not explicitly configured the setting, and that supported item types will have a three-day recovery window by default.
Is the window three days or seven?
Microsoft’s notice says three days for unconfigured tenants. Microsoft’s documentation says seven days when an administrator turns the setting on, configurable from seven to ninety. The two pages differ; setting an explicit value makes the question moot.
What happens today if the setting is off?
Microsoft states that when the Item Recovery setting is off, Fabric does not retain deleted items when an individual item is deleted.
Why would a restore fail?
Microsoft states that if a new item with the same name exists in the same workspace, recovery fails until the existing item is renamed.
The Braintree view
Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.
Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.