Business Central 29 Adds In-App SIFT Index Controls for Performance Tuning

The AI at Work roadmap record for item 573316 lists the feature as Launched, with October 2026 general availability for the Web platform in Worldwide Standard Multi-Tenant environments. Those are the roadmap record’s stated boundaries; they should not be interpreted as confirmation that every customer environment already exposes the control.

What SIFT indexes actually do​

SIFT stands for SumIndexField Technology. Microsoft’s developer documentation explains that Business Central implements SIFT totals using SQL Server indexed views: calculations that are computed and stored so the database can retrieve aggregates efficiently. Business Central creates an indexed view for each enabled SIFT key and maintains its contents as the underlying table changes.

Think of it as keeping a running subtotal rather than recounting the entire pile whenever someone asks for the total.

Microsoft’s example uses an account-and-posting-date key. The database stores an aggregate for each account on each date, allowing a broader total to be assembled from those daily aggregates rather than necessarily summing every underlying transaction. The documentation also establishes that disabling the corresponding SIFT structure through the existing developer property drops its indexed view and stops maintaining those totals.

The new feature changes who can access the control and where. Microsoft’s wave 2 description explicitly places SIFT on/off administration inside Business Central, although it does not explain how that administrative action interacts with extension metadata. It therefore does not establish that the action rewrites AL source code.

The tradeoff: faster sums versus maintenance work​

Microsoft’s MaintainSiftIndex documentation describes the underlying balance clearly. SIFT structures accelerate summing operations, particularly across large record sets, but table modifications require additional work because those structures must also be maintained. The property applies to a table key and defaults to true.

Importantly, disabling SIFT maintenance is not the same as removing the associated calculation definition. Microsoft documents that SumIndexFields can remain necessary for FlowField calculations even when maintaining a SIFT structure is undesirable. It identifies infrequent calculations or small data sets as situations where disabling maintenance can avoid slowing table modifications.

The practical interpretation is workload-dependent:

• Frequently requested totals across large data sets are a reason to be cautious about disabling their supporting structures.
• Infrequently requested totals are candidates for investigation, not automatic removal.
• Any evaluation should consider both transaction processing and the calculations users depend on.

These are operational recommendations derived from Microsoft’s documented tradeoff, not guaranteed performance outcomes or a published procedure for roadmap item 573316.

Why the older index-management guide needs care​

There is a documentation distinction administrators should not overlook. Microsoft’s general Manage database index usage guide, scoped to Business Central 2026 release wave 1 and later, still states that SIFT indexes are protected and cannot be disabled through the controls it describes. Its switch-off guidance concerns eligible nonunique indexes.

That page also describes per-company actions and scheduled re-enablement. Those details cannot safely be carried over to the new SIFT capability: the earlier guide explicitly excludes SIFT, while the wave 2 feature description does not establish its navigation, company scope, or activation timing.

Likewise, the update 29.0 preview overview applies to online sandbox environments, not production or on-premises deployments. It corroborates the feature’s inclusion in wave 2, but does not independently prove universal production availability.

The administrator’s takeaway​

Business Central’s new SIFT control is a useful addition to performance governance. The sensible approach is to document the affected business processes, establish baseline timings, and evaluate a narrowly scoped change in a representative test environment before considering production use.

The goal is not to collect disabled indexes like trophies. It is to determine whether the maintenance cost of a particular aggregate structure is justified by the work it accelerates. Microsoft’s documentation supports that tradeoff; the right answer for an individual environment still requires evidence.