The feature preserves relationships between multiple business object types, such as orders, deliveries and invoices, alongside process metrics. Microsoft positions it as a way to combine process intelligence with financial, operational and customer analytics rather than keeping those insights inside a separate process-mining experience.
Availability: separate the roadmap from tenant readiness
Microsoft’s release plan lists May 31, 2026 for public preview and August 2026 for general availability. However, that page was archived in October 2026 and explicitly warns that it may no longer reflect current plans. Those milestones should not be treated as proof that every environment has the capability, or that October represents a new launch.
The stronger practical evidence is Microsoft’s product documentation, which describes Fabric export as an option during object-centric process creation. Some related links still retain a “preview” label, so administrators should distinguish documented functionality from a blanket assurance about availability.
Configure the export during process creation
Microsoft’s ingestion guide starts with an object-centric event log stored as a CSV file in Azure Data Lake Gen2 or OneLake. The documented workflow is:
- Open Process mining > Start here.
- Select Object-centric process mining and enter a process name.
- Choose Azure Data Lake or OneLake as the source, then select Continue.
- At Choose where to export, select Continue rather than Skip export.
- Choose an available Fabric workspace, a Lakehouse within it, and a name for the report.
- Complete the source-specific connection setup and map the data.
- Select Save and Analyze. After ingestion, the Process overview tab opens.
Mapping requires one Activity, one Start event, and at least two Object type attributes. End event and Resource are optional, as are additional event-level and object-level attributes.
That minimum of two object types is an important preparation check: this is not simply a new destination for any arbitrary event spreadsheet.
What analysts receive—and what needs care
The published model includes object/event records, process-mining-derived visualization data, and process executions based on a leading object type. Predefined relationships provide the starting structure. For additional sources, relationships or custom DAX, Microsoft directs analysts to build a Power BI composite model on top.
Two operational caveats deserve attention before a production rollout:
- Column-name collisions: Lakehouse export replaces unsupported characters with underscores.
Customer NameandCustomer_Nametherefore collide and can interrupt export, although semantic-model columns retain original names. - Refresh consistency: Large OneLake updates can temporarily produce inconsistent reports. Microsoft documents taking ownership through Take over, then disabling Keep your Direct Lake data up to date in semantic-model settings as a mitigation.
Microsoft also warns that inefficient DAX or an incorrectly configured composite model can trigger DirectQuery fallback, reducing performance without breaking the report.
The practical takeaway
The opportunity is more useful than another export button: Microsoft’s stated design lets teams bring connected process relationships and metrics into their existing analytics work. But “available in Power BI” does not mean “finished business analysis.”
For a pilot, the sensible acceptance criteria are straightforward: confirm that publishing succeeds, validate the report against the process analysis, and test refresh behavior before extending the model. Treat the first dashboard as a validation exercise—not merely a design exercise. That is where this integration earns its place in an enterprise reporting workflow.