What it does
Ingestion is how the event log gets from the source system into process mining. Two routes exist: Power Query, which brings transformation with it, and direct file-based ingestion from Fabric OneLake or Azure Data Lake Storage Gen2, which is faster at volume but expects the data to arrive already in final shape.
Key facts
- The required schema is case ID, activity name, and timestamp — one timestamp for event logs, start and end for activity logs. Optional types add resource, event-level attributes, case-level attributes (interpreted from first or last event), and financial values per event or per case.
- Power Query supports the usual connector set including Text/CSV, SQL Server and OData. The Text/CSV connector needs OneDrive for Business; without it you use Blank table, which takes far fewer records.
- The Dataverse and Dataflow connectors aren't supported in this context. To read Dataverse you use the OData connector against
<environment URL>/api/data/v9.2with organisational account auth — the Activities table appears asactivitypointers. - Fabric OneLake ingestion accepts a single Delta table, single or foldered CSV files, single or foldered Parquet, and delta-parquet folder structures. Lakehouses with schema support enabled aren't supported.
- OneLake ingestion needs the external-apps tenant setting on, a workspace other than My workspace, and the Process Insights Prod service principal shared into the Fabric workspace with the Admin role.
- CSV for OneLake ingestion must be uncompressed, comma-delimited, with default row delimiters, and timestamps in ISO 8601. The header row is capped at 1 MB.
- No transformation is available after file-based ingestion. Data must be mappable to the schema as it arrives.
- Scheduled refresh runs at a maximum frequency of once per day. Incremental refresh is available for ADLS Gen2 and Fabric OneLake sources.
- Refresh can also be triggered externally: a cloud flow calling the Dataverse bound action Analyze on the PM Inferred Tasks table, passing the process GUID as row ID and
"1"as the item/version advanced parameter.
When to use / skip
Use Power Query when the event log needs shaping, when the volume is moderate, and when you want the transformation visible and editable inside the tool. Move to OneLake or ADLS Gen2 when volumes are large enough that Power Query becomes the bottleneck, or when the client already has a data platform team producing curated event logs — at that point ingestion is just pointing at a folder. CSV upload is for proving the concept and nothing else.
Configuration decisions
- Which ingestion route, and whether the client's data engineering capability makes the lake option realistic or aspirational.
- Where the transformation happens: in Power Query inside process mining, or upstream in the pipeline that lands the file.
- Full refresh or incremental, and for incremental, how files are named so the increment order is unambiguous — dated names like
YYYYMMDD.csvare the documented approach. - Whether refresh is scheduled or triggered by the upstream pipeline finishing, using the bound-action flow pattern.
- How much history to load. More history means better variant analysis and faster consumption of the storage entitlement.
Gotchas
- Adding a Power Query step that's already in the applied steps list appends a second one at the end, operating on the already-filtered output. Choose columns twice and the second one sees only what the first left behind.
- Timestamps that aren't ISO 8601 fail ingestion from OneLake with unhelpful errors. Fix them upstream.
- Because there's no post-ingestion transformation on the file-based routes, a schema mistake means going back to the pipeline and reloading rather than editing in place.
- The Fabric service principal sharing step is easy to miss and produces a connection failure that looks like a permissions problem in Power Automate rather than in Fabric.
- Once-daily is the ceiling for scheduled refresh. Clients expecting near-real-time process monitoring need the external trigger pattern, and even then this isn't a streaming tool.
Consultant notes
- Budget the extraction and shaping as the bulk of the effort. The process mining configuration itself is a day; getting a clean event log out of SAP or a bespoke system is weeks.
- Bring the client's data platform team in as a partner, not a dependency. If they own the lake, the OneLake route makes their existing pipelines the ingestion mechanism and the whole thing gets cheaper.
- Warn about the storage entitlement before you agree a history depth. It's easy to design a two-year event log and find out later what it costs.
Recheck the supported connectors and file formats each release wave — OneLake and Fabric support here has been changing steadily