Process Mining Data: What You Need to Get Started

Process mining data comes down to three fields: a case ID to connect events, an activity to say what happened, and a timestamp to place it in time. Most teams find them in an export they already have, and the work is deciding which records answer the question they are asking.

The Short Answer: What Process Mining Data Do You Need?

Start with the minimum viable log: one row for each event, with a case ID, an activity, and a timestamp. Add attributes when they help answer a specific question, and do not wait for a perfect dataset before checking whether the data can show how work actually happens.

Everything below is about making those three fields trustworthy. If the terms are new, start with what process mining is and what a log can show before you extract anything.

The required fields form the core of a process mining data schema; the optional ones are what let you explain variation later. Begin by checking whether your export contains the three required fields and whether each row represents one event. For a worked example of the structure, see how to create an event log; for how the fields get configured, see the data mapping documentation.

What Data Do You Need?

Imagine you run a lemonade stand and want to understand why customers wait. You do not need every detail about every customer. You need the steps in each order.

For each event, record:

• Case ID: the order number connects events that belong to the same order.
• Activity: the name of what happened, such as “Take order,” “Prepare lemonade,” or “Serve customer.”
• Timestamp: when it happened, which is what puts the events in order.

Figure 1 — Look at the steps, not at every detail of every case.

A small example is enough to show the structure:

With these fields you can see the sequence of each order and how long each step takes. Extra fields, such as order type or sales channel, explain why some orders take longer, so add them when they answer a question you have.

The same logic holds outside the lemonade stand. In an order process the case ID may be an order number, activities may be status changes, and timestamps come from an event history rather than a report export. ProcessMind reads an existing export once the fields are mapped, so the flow is visible in the process mining platform without changing anything in the source system.

The Case of the Missing Lemonade Logs

The lemonade stand is busy and the line keeps growing. You want to know whether customers wait to order, wait for preparation, or hit a problem. The evidence is scattered across receipts, order records, and notes.

Figure 2 — The evidence for one order rarely arrives as one tidy table.

That is normal in real projects. The data exists, but not as a ready-made event log: you combine records from different tables or systems, and decide which fields are the case, the activity, and the timestamp.

Start by writing down the question you want to answer, then find the records that can answer it.

• To measure order lead time, find the order identifier and the timestamps for relevant status changes.
• To compare channels, include the channel as an additional attribute.
• To understand complaints, include complaint-related activities or outcomes if they are recorded consistently.

That keeps the first extract focused. You do not need to collect every field in every system, only enough data to reconstruct the process and investigate the question.

If you already have an Excel or CSV export, look at it before you ask your data team to build a new extract. You can see what the fields already support, and what a better extract would add.

The Great Data Dig

Process mining data sources are usually the systems that record work as it happens: an ERP, a CRM, an ITSM platform, a ticketing tool, or another operational application. The records you need may sit in a database, a report, or an export.

Ask the process owner and the system owner where the key events are recorded, then follow a few real cases from start to finish. What you are checking is whether the case identifier, the event names, and the timestamps can be found for every step.

1. Pick one process and one question

   Where do orders wait, or which handoff loses the most time.

2. Find the system and its owner

   The application that records the work, and the team that runs it.

3. Look for event history

   A report or table with status changes, rather than a snapshot of the current state.

4. Check the case ID

   The same identifier has to appear on every event you want to connect.

5. Export a small sample first

   Inspect it before you ask for a larger extract.

Avoid pulling every table because it is available. A focused extract is easier to review, clean, and explain. If the process spans several systems, write down how the records connect, for example which order number links a CRM record to an ERP record.

For an overview of common sources, see the documentation on where to get data. If you need to combine or transform data from several systems, the guide to ETL for process mining covers that part of the work.

The Data Detox

An export can contain duplicate events, missing timestamps, inconsistent status names, test orders, or records that do not belong to the process you want to study. None of that makes the export useless. It does mean you should know what each row represents before you read anything into the results.

Review the data in a few passes:

• Duplicates: check whether repeated rows are real repeated events or accidental copies.
• Timestamps: look for missing values, mixed formats, unexpected time zones, and events that appear out of order.
• Activities and statuses: standardize labels that mean the same thing, and keep statuses separate when they represent different steps.
• Test or cancelled records: decide whether they belong in the analysis, and write down what you exclude and why.
• Case IDs: check for blank or changing identifiers that could split one case into several or combine unrelated cases.

Do not clean away unusual cases just because they look different. First determine whether they are valid exceptions or data errors, and keep a record of every change so the prepared dataset can be explained against the source.

Process mining data quality is rarely a yes or no. It is whether the fields your question depends on behave consistently, which is why a sample is worth more than a promise. ProcessMind shows it on the dataset itself: a quality badge with a percentage, and a panel that explains what is driving the score, including missing values, inconsistent values, and timestamp problems. You can see how much to trust a result before you act on it, and watch the score move as you fix things. The details are in the data quality documentation.

Reviewing is iterative: start with a sample, map the fields, look at the resulting process, and investigate whatever looks wrong. The data cleaning and preparation guide covers the common steps and checks.

The Data Makeover

Once you have found and reviewed the records, map the source columns to the fields the process analysis needs. The source system may use different names, but the meaning must be clear.

An activity should describe an event in the process, not a vague comment. “Customer happy” may be an opinion or note; “Order delivered” is a clearer event if the system records that status. Choose the timestamp that reflects when the event occurred, not simply when a report was exported.

You do not have to assign every column by hand either. ProcessMind suggests matches as you map a dataset, and AI Data Recommendations point at likely mappings with a confidence score, then suggest attributes, activities, or sources that would make the analysis sharper. You review and confirm instead of hunting through field lists, which is the difference between a mapping afternoon and a mapping week. See AI data recommendations.

A good mapping makes the process understandable to the people who know the work. Review activity names with the process owner, and confirm that the case ID and timestamps behave as expected. The data mapping documentation explains how to configure a dataset, while the guide to mapping activities covers activity definitions.

How Much Data Do You Need?

There is no single case count or history length that fits every process. The right amount depends on how often the process runs, how much variation you expect, and what you want to compare.

For a first check, use enough cases to include normal work and the exceptions you care about. Include enough history to see the relevant process cycles and any meaningful changes over time. If you only have a short period or a small sample, you can still test the schema and mapping, but be cautious about treating the results as representative.

More data can reveal less common paths, but it also takes longer to prepare and analyze. Start with a focused period and expand it if the initial results raise questions. If you are working with a large event log, review the guidance on process mining performance and scalability before deciding how much history to load.

Format and Upload Options

For a first project, use an export your team can produce and review. ProcessMind supports common spreadsheet and delimited-file workflows, including CSV and Excel files; larger logs can use Parquet or ORC. Uploading one takes minutes: you add the file, review the columns that were detected, and see the process before you decide anything about connectors. The steps are in how to upload your dataset.

You can also load data incrementally when you need to add newer records without rebuilding the entire dataset. The right approach depends on how your source data is produced and how often it changes. See the supported data formats and incremental data loading documentation for details.

An API may suit a repeatable data-loading setup. Check the data API documentation to understand the available options. If you are deciding how to extract, transform, and load data, start with the ETL guide.

Data You Should Not Upload

Only include data needed for the process question. Personal information can appear in fields you do not expect, especially free-text notes, comments, or descriptions. Review the extract before uploading and remove or mask fields that are not necessary for the analysis.

Work with your privacy, security, and data governance teams to confirm what your organization permits. Consider whether you need names or other direct identifiers at all. In many analyses, a team, role, or pseudonymous identifier is enough, if it is appropriate for your purpose and policies.

Do not treat a process analysis as a reason to collect more personal data. Keep the dataset limited to the fields needed to understand the process, and follow your organization’s rules for access, retention, and handling. ProcessMind separates tenants and controls access by role, and an audit log records who could see what, which is what lets you answer that question later. See users, roles and permissions, the audit log, and our privacy policy.

Getting Your Data Team on Board

A clear request helps your data team estimate the work and avoid unnecessary extraction. Send a one-page brief with the following information:

• Process: Name the process and its start and end points.
• Question: State what you want to learn, such as where orders wait.
• Scope: Specify the systems, date range, and types of cases to include.
• Required fields: Request a case ID, activity, and timestamp for each event.
• Useful fields: List only the attributes needed to answer the question.
• Examples: Include a few representative cases, with sensitive values removed where needed.
• Checks: Ask the team to flag missing IDs, missing timestamps, duplicate events, and unclear status values.
• Privacy: Confirm which fields can be shared and whether any need to be removed or masked.

You can also share the event log guide so the team has a concrete example of the structure you need, and point them at the matching process improvement guide when the extract has to come from a specific system. Once you have an export, follow the getting started guide to load it and view the process.

Next Step: Upload and Map Your Data

You do not need a perfect extract to find out whether your data can support a first analysis. Start with an existing export, check the three required fields, and see what needs attention before you invest in a larger data project.

There is also a payoff beyond the first process map. Once a dataset is loaded, ProcessMind scores the process out of the box through Process Health: one repeatable score per process, built on the five dimensions of the CURES framework, Conformance, Uniformity, Rework, Efficiency, and Smoothness. The score says where to start, and the same dashboards point at what to fix, so the first dataset produces a worklist rather than a picture. Process Health and its scores come with a Process Intelligence seat.