Troubleshooting Data Issues

Troubleshooting Data Issues

Data problems announce themselves in specific ways: cases that fall apart, events in the wrong order, steps that are missing, numbers that look impossible. This page works from the symptom back to the cause, and from the cause to the fix — inside ProcessMind where a setting solves it, and in the extract where nothing else will.

For the full preparation workflow — what good data looks like and how to get there — see Data Cleaning and Preparation. For the checks the platform runs on your data, see Data Quality.

First Checks

Before digging into the source file, look at what ProcessMind already tells you:

• The red list above the panels. On the dataset’s General tab a red list names the blocker: the missing Case ID, Activity, or End time, activities without data, attributes without values, or a mismatch between a re-uploaded file and the process type it was loaded as. Start there.
• The quality badge and panel. The score covers missing values, inconsistent values, and timestamp problems; the panel breaks it down into freshness, attribute coverage, and activity analysis.
• AI data recommendations. A scan over the dataset lists the concerns it finds and suggests mappings and fixes.
• Dataset attributes. Set the display name, data type, and timestamp format — or hide a column — without re-exporting anything.

Symptoms in the Process Graph

Cases are split across several cases

You see: one process instance appears as many short cases with a step or two each, so the graph is a flat row of activities.

Why: the column mapped as Case ID identifies something smaller than the process instance — a line item, an invoice number, a document number from one system.

Fix: map the column that identifies the whole instance: the order, the ticket, the claim. If no single column does that, the unification has to happen upstream — join the identifiers in SQL or your ETL job so every event of one instance carries the same Case ID, then upload again. The naming conventions per system are described in Where to Get Data.

Events are out of order

You see: activities that happen later appear before activities that happen earlier — an invoice dated before its order.

Why: three usual suspects. The timestamp was parsed with the wrong format (a 03/04/2025 value read as March 4 instead of April 3). Events from systems in different time zones were mixed without conversion. Or the wrong column was mapped as the time field.

Fix: check the format in dataset attributes and confirm the type is Timestamp rather than text. Convert every source to one time zone before combining exports, sort each case by its timestamp, and spot-check a few cases end to end.

Steps are missing

You see: the graph skips a step that definitely happens.

Why: the step leaves no trace in the data (a phone approval, a paper signature), the activity was never mapped, or a filter removed it from view.

Fix: keep steps that exist but are not recorded visible by marking the activity as a data flow through step, and map the rest with Mapping and Unmapping Activities — unmapped activities show up translucent, with dotted connections. Then check which filters are active.

Cases never end

You see: many cases simply stop without reaching an end event.

Why: the export cuts off at a date while the cases are still running, the model has no end event, or the closing activity is not in the dataset.

Fix: give the model a real end event, or accept the open cases and keep them out of time analysis — time metrics count closed cases only. A case that has not finished is not a data error.

Counts look inflated

You see: one activity is performed suspiciously often, or the case count is higher than the business reports.

Why: duplicate rows — the same event recorded twice by an integration or by a repeated extraction.

Fix: de-duplicate on case ID, activity, and timestamp before uploading; the preparation workflow covers where duplicated extraction usually comes from.

The map is cluttered

You see: hundreds of activities, most of them technical.

Why: logins, retries, and background jobs live in the same extract as the business steps.

Fix: hide the attributes you do not analyse, filter out events that are not part of the process, and group low-level events into the activity they belong to. Where the line sits between detail and noise is a decision for the process experts.

Data from several systems does not line up

You see: the process has gaps where one system should have contributed.

Why: systems are extracted at different times, label the same step differently, or one extract was missed altogether.

Fix: align the extraction windows and the activity vocabulary before combining, and give each dataset its role through primary and comparison instead of concatenating files that disagree.

Symptoms in the Dataset

The upload is rejected

You see: the upload ends in an error, or the file loads as a single column.

Why: the file breaks one of the structure requirements. The common ones are a missing header row (it belongs in the first line), blank rows between data entries, numbers stored as text, and Excel files whose data sits in the second sheet — only the first sheet is read.

Fix: put the header in row 1, remove blank rows, make sure numbers are numbers, and move the event data to the first sheet. Delimiters and quotes in CSV, TSV, and TXT are detected automatically, so a single-column result usually means the file cannot be interpreted — re-export it as CSV or Parquet.

Columns or types are wrong

You see: a column is missing, or a timestamp is treated as text.

Why: the file changed since the last upload, or the type was detected incorrectly.

Fix: set the data type and format manually, or hide the column. After replacing a file, check the red list for a mismatch between the new file and the dataset it was loaded into.

Timestamps are not recognised

You see: the timestamp column is empty, or the durations come out far too long.

Why: an unusual format, a locale-specific day and month order, mixed precision (seconds and milliseconds in one column), or time zone conversions applied twice.

Fix: set the format explicitly in dataset attributes, split mixed-precision exports at the source, and standardize on a single time zone before uploading.

Values are blank

You see: attribute coverage in the quality panel shows gaps, or a chart has a null category.

Why: the source system does not capture the value for every case, or the export dropped empty fields.

Fix: fill the gaps at the source where that is possible, and use null handling functions in a calculated attribute where a blank can be replaced by a sensible default.

Activity names disagree

You see: “Approve Order” and “Order Approval” listed as two activities that mean the same thing, or the same step named differently per country.

Why: every source system has its own label for the same work.

Fix: agree on one name per step, then either normalize the values in the extract or add a calculated attribute that maps the variants onto one name and map the activity from there.

Symptoms in the Numbers

Averages look too low

You see: an average case duration the business does not recognise as realistic.

Why: time metrics count closed cases only, so unfinished cases are excluded — and the cases that finished are often the fast ones, especially in a recent period.

Fix: compare like with like. Restrict the period to cases that had time to finish, read the definitions in Time Metrics before drawing conclusions from a single average, and look at the distribution rather than the mean.

Averages are dominated by outliers

You see: averages far above the typical case.

Why: a handful of extreme cases pull the average up; sometimes they are real exceptions, sometimes they are data errors.

Fix: read the slow-case tail (P90 against the median) instead of the average, check whether the extreme cases are genuine, and exclude only what is actually wrong — a rare but real exception is insight. Time Metrics explains each measure.

A comparison shows nothing

You see: a comparison dataset reports Not present (0 cases, 0% coverage).

Why: the active filters or the selected period contain no cases for that dataset, or its activities are not mapped to the model.

Fix: widen the period, check the mapping of the comparison dataset, and confirm which dataset is primary.

When It Is the Size of the Data

Some problems are not data errors but scale:

• Slow uploads: prefer Parquet or ORC, and XLSB over XLSX for Excel files; see Supported Data Formats.
• Growing files: append new periods with an incremental (delta) upload instead of replacing the whole file.
• Slow analysis: drop the columns nobody analyses, filter out the happy path when you are hunting exceptions, and look at one period or one region at a time — the performance guide shows what the sizes cost.
• Datasets that can go: archive what you no longer analyse, so the workspace holds the data you actually act on.

Fixing It at the Source

Every fix that happens inside ProcessMind saves a round trip, but some problems only disappear upstream: a missing source system, mixed time zones, identifiers that no export unifies. Those belong in the extract and, if they recur, in the system that produces it — see Where to Get Data for the per-system routes and ETL for Process Mining for the habits that keep an extract trustworthy.

Still Stuck?

If the checks above do not explain what you see, contact the support team with the dataset name, the case you are looking at, what you expected, and what you see instead. A screenshot of the graph and one of the quality panel usually settle it faster than a description.

Related topics

• Data Quality - what the badge checks and how to read the panel
• Configuring Your Dataset - the red validation list and the required fields
• Supported Data Formats - header rows, sheets, and file types
• Data Cleaning and Preparation - the full preparation workflow
• Incremental Data Loading - growing datasets without re-uploads
• FAQ - the questions that come up most often