Process Mining vs Process Configuration Mining: What’s the difference?
Process mining has been a valuable approach to surfacing opportunities to streamline. It’s been based on tracking user’s screen activity. But, by taking a different approach – how the systems have been configured – there are even more valuable insights.
What is Process Mining
Process Mining is a valuable approach to understanding user behavior. It’s like a heatmap of the traffic through your city. It tells you what is moving and what is not moving, but not why.
Process mining is useful for understanding adoption, identifying inefficiencies, and streamlining operations. In Salesforce terms, this is achieved by looking at the field history or the event logs to understand what paths the users are taking.
The challenge with this approach is that it is an incomplete picture. It doesn’t explain your entire org configuration because it is based on a user’s behavior across a time frame. It also requires planning and setup to decide which fields (and you can only choose a limited amount!) are going to be tracked. The mining then requires enough time to collect the data based on the volumes of user activity in the area of interest. There are also technical limitations with the field history approach. These are listed at the end of the article.
Typical process mining output
Process Configuration Mining – on demand
This is like a detailed blueprint of your city streets. It tells you about every street lamp, speed bump, traffic light, intersection, roundabout, bridge, tunnel, and speed camera. And you can overlap the traffic patterns. It is a map of every possible route. You can then overlay the usage data to show which paths are taken – vs which paths should be taken.
In Salesforce terms, this is a UPN business process diagram that shows the configuration of the Salesforce Org and all the paths that a user can take. It is based on analyzing chains of automations, like apex classes, triggers, flows, quick and global actions, validation rules, workflows, user permissions, fields – in essence, your entire setup. It is live Org documentation. All metadata used to infer the business process is automatically linked to every process step, providing insight into how it is being used and providing quick access in Salesforce Setup if you need to make changes to your business processes.
This requires access to the Org configuration metadata and some very sophisticated analysis. While AI is used to infer and summarize business logic, it is only possible because Elements.cloud has the most advanced insights on metadata dependencies.
Process configuration mining can be run on the Org for any object at any point in time. What would take weeks of work is done in a few minutes. So it can be on-demand and used to understand the existing, As-Is business processes and configuration for any planned change, no matter how small or big. And we know that it is accurate because it is running against your current Org metadata.
The benefits of this approach is
- More rapid health check – a complete view of the org configuration
- Better architecture decisions – understand the implications of a change.
- Highlights security risks – shows what users can do
- Reduce technical debt – uncovers functionality that can be reused
- Identify areas of technical debt and cost – configuration and usable
This is a great concept, but I didn’t think it would be possible. I’ve been proven wrong by the team. This is an amazing capability.
Adrian King, CTO, Elements.cloud
Elements.cloud is the only vendor able to provide this because it has the combination of rich metadata, dependency insights, and user access permission data in the metadata dictionary, which includes Agentforce, Data Cloud, and every Salesforce Cloud. And, it also has the process mapping capability, which links back to metadata.
Consulting revenue at risk
With so many undocumented orgs, consulting get paid thousands to manually understand and document org configurations. This is often for regulatory reasons, but it is an aspect of most projects.
We’ve just spent $500k with a consulting firm documenting our Org. Elements.cloud could have done it in 10 minutes.
Financial Services
Whilst this may seem to be taking money away from the consulting firms, the forward thinking firms understand that their client’s budgets could be more usefully spent on moving their business forward: Agentforce, new clouds or Data Cloud. But this does put an emphasis on more experienced consulting resources.
Talk to us
Deep dive: technical limitations of Process Mining using Field History Tracking
Requires Field Selection
It must be enabled before tracking begins, so there is no retroactive data collection. Only 20 fields per object can be tracked unless expanded, with a hard cap of 60 fields max. If the process spans multiple fields but only a subset is being recorded, critical steps may be missing. Field tracking is often allocated for other business needs.
Implication: Fields selected for history tracking may not align with process mining goals.
Short Retention Period
Data is only retained for 18-24 months, limiting historical analysis. Therefore cannot analyze long-term trends or past optimization efforts.
Implication: It is difficult to validate multi-year process improvements or compliance history.
Lacks context on why a field was changed
There is no way to determine whether a change was made manually, through automation, or via external systems.
Implication: This forces analysts to make assumptions or manually interview users, which defeats the purpose of automated process discovery.
Incomplete Data
It does not track deleted records or rollback events. So once a record is gone, process visibility is lost. The same object may be used in multiple processes, meaning tracked fields might represent a different process than the one being analyzed.
Implication: The resulting data may not reflect a coherent process but rather a mix of multiple workflows, leading to misleading insights.
Multi-object process mining
It works well for linear workflows like Opportunity or Case stage changes. Clear, sequential changes are easy to visualize when fields directly represent process progression. Because field history tracking is object-specific, cross-object processes are fragmented. There is no inherent way to link related changes across objects (e.g., an Account update influencing an Opportunity).
Implication: True process mining requires stitching together disparate data, which this approach cannot do without heavy manual work.
Process Completion
Since it relies on past snapshots, only completed processes are well-represented. Mid-flight processes are difficult to analyze, meaning bottlenecks or real-time inefficiencies may be hidden.
Implication: The analysis is inherently backward-looking and may not reflect current operational challenges.
More visualization than real process mining
As it is field history tracking reports changes it does not infer workflows. This approach is more like traditional reporting rather than true process discovery.
Implication: Organizations might believe they are conducting deep process mining, but in reality, they are just visualizing tracked field changes with missing context.
