Microsoft’s roadmap record for feature 577827 lists the web capability as Launched, with preview availability in June 2026 and general availability in August 2026, scoped to the Worldwide (Standard Multi-Tenant) cloud. It is an administrator- or maker-enabled capability, rather than an automatic conversion of existing imports. Microsoft cautions that roadmap dates are estimates and subject to change.
Why keeping tables separate matters
Microsoft’s release plan identifies a familiar data-engineering problem: existing pipelines and data products often use efficient, related-table structures, while a single-table event log repeats attributes across event rows. Normalized import supports case-level information, historical events, and separately stored attributes without requiring that preliminary flattening exercise. Microsoft says this improves both transformation and import-to-model stages.
The practical implication is less architectural compromise. A team should not need to rebuild a well-organized data product simply to feed one analysis tool. However, Microsoft’s cited documentation provides no quantified ingestion benchmark or storage-saving percentage; those benefits should be treated as workload-dependent, not guaranteed performance figures.
What the import supports—and what it does not
Microsoft Learn documents a specific structure:
- Exactly one event table.
- At most one case table.
- Any number of lookup tables, but no nested lookup joins.
The documented sources are OneLake/Fabric Lakehouse and Azure Data Lake Storage Gen2, with CSV, Parquet, and Delta-Parquet formats. Both normalized and standard imports produce the same Process Mining model.
There is also an authoring trade-off: normalized import currently requires an uploaded JSON configuration; there is no in-product editor. Teams with an already-flat export can retain the standard import experience.
Two technical checks deserve particular attention. Start and end timestamps must be direct event-table columns, not joined attributes. For Delta tables, select dataSourceFileType: 2 and point to the table root—not _delta_log/ or an individual data file. Microsoft warns that treating Delta as plain Parquet can produce misleading missing-column errors.
Better ingestion still needs genuine event history
Normalized tables do not automatically make a database suitable for process mining. Microsoft’s data-preparation guidance distinguishes current-state application records from historical event logs: analysis needs a record of what happened, not merely what an order or request looks like now. Core fields include a case identifier, activity name, and timestamps.
That distinction provides a useful readiness test: before redesigning an import, establish whether the source captures the required history. Preserving table relationships cannot reconstruct events that were never recorded.
Nor should this update be confused with object-centric process mining. Microsoft describes that approach as allowing one event to relate to multiple business objects. Normalized import still documents a single case context; changing the storage layout does not, by itself, change the analytical perspective.
The bottom line: this is a targeted improvement for organizations already maintaining related process-data tables. It removes an unnecessary flattening requirement, but leaves teams responsible for configuration and sound event data. For those users, the useful upgrade is not a flashier process map—it is less preparation work before the map can exist.