Process Configuration Mining helps Orgs improve their processes and UX, address sources of poor data quality, and prepare the Org for Agentification, by auto-generating detailed business process diagrams, that account for complexity and tech debt, in context of the processes you care about.
Prerequisites
To use the Process Configuration Mining feature, ensure the following:
You are a space editor
You are a manager or editor on one of the connected Salesforce metadata dictionaries
Process Configuration Mining is currently available in closed beta.
We are planning GA release in May, subject to feedback from beta customers.
What is Process Configuration Mining?
Process Configuration Mining is a technique of mining Salesforce configuration, dependencies and permissions, to analyze and generate an accurate and detailed picture of how the Org is designed to work today.
It helps teams:
Accelerate discovery of current state processes.
Eliminate guesswork by leveraging actual configuration data.
Kick-start documentation efforts without the “blank page” problem.
Enable process-aware change by showing dependencies and automations.
For full list of use-cases, read our solution guides.
How is Process Configuration Mining different from Process Mining?
Process mining is an established technology and approach that utilizes event monitoring to examine user or record activity within the system to aggregate trends and visualize most common pathways through the system.
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 configuration mining, on the other hand, is like a detailed blueprint of your city streets. It tells you every street lamp, speed bump, traffic light, intersection, roundabout, bridge, tunnel, speed camera, fundamentally it gives you the entire blueprint of how the city streets are designed to function.
It does not rely on event data, instead process configuration mining focuses on analyzing the configuration, i.e. objects, fields, automations, validations, permissions etc. to visualize how the system is designed to work.
What Does It Generate?
The current version of Process Configuration Mining focuses on Single Object Lifecycle Diagrams. That means a diagram for a single object. A diagram like that visualizes:
How a new record can be created, by whom, and from where.
How a record moves between stages or statuses to closure.
What automations or triggers fire at each stage.
What validations or constraints users must satisfy during transitions.
What user roles or permissions can act on the object through the lifecycle.
Every step in the process is automatically linked to the Salesforce metadata it was derived from. In some cases this can be into many dozens, if you account for permissions, pages, objects, and actions.
You are always one slick away from metadata component either in your Elements metadata dictionary or Salesforce Setup.
For example, asking “How do we manage opportunities?” will generate a diagram showing:
Opportunity stages (e.g., Prospecting → Negotiation → Closed Won).
Related flows, triggers, and validations.
User actions and object transitions.
Here is an example output for Opportunity object:
We are already working on multi-object lifecycle diagrams, which would allow us to generate an accurate As-Is picture of e.g. entire lead -> opportunity -> order process.
But that isn't expected to be ready until Autumn 2025.
How to generate business process from Salesforce Org?
In the Diagrams menu, click "New Diagram". From the dropdown, select "Org to process".
In the modal window that will appear:
In the first field, pick one of the metadata dictionaries for which you have edit or manage permission.
In the second field, ask your natural language question. For instance, "How do we manage sales?" Try to focus on the capability you wish to understand or simply give the name of the object you want to analyze.
In the third field, name your diagram.
Elements will identify Objects in your Org that, based on their name and description, most closely match with your query. Select the object you wish to analyze.
Elements will identify the picklist fields most likely to be driving some sort of workflow on the object. Select the controlling field you would like to use as the basis for the lifecycle analysis.
If you have selected either an Opportunity, Lead, or Case object, select one of the active processes. If you don't have any active processes, the generation will start automatically. Once you've selected your active process, click Next.
New diagram will open in a new window. Leave the diagram open and wait for about 1-2 minutes for the diagram to automatically generate.
✅ What's supported?
Below is the list of metadata types with explanations on how they are being identified and drawn in the process.
Metadata Type | How It's Analyzed |
Objects (Custom, Standard, Managed) | The 'core' object used for analysis is selected by user during creation.
Related objects are identified and traversed through lookup and master-detail fields from the core object in order to identify pages with related lists from which user is able to create a new record for the core object.
Related objects are also visualized if there is a record triggered flow, screen flow, action, global action, or apex trigger that are invoked from other objects and lead to creation of a new record on the core object. |
Fields (Picklists) | Suggested by Elements based on name and description indicating being used to drive some lifecycle. Fields are likely to be flagged if they are named
Field is selected by the user during creation. |
Sales/Support/Lead Processes | These metadata types govern the lifecycle logic for Opportunity, Case, and Lead objects. They define valid picklist values and progression rules for each process.
Process is selected by the user during creation. |
Picklist values | Each picklist value for the picklist field will represent a single workflow transition step in the process.
They are taken from the selected picklist field OR sales/support/lead process. |
Page Layouts | Analyzed to determine presence of 'New' actions in related lists. |
Validation Rules | Added to transitions as conditions for progressing through stages. Each rule is summarized and integrated into flow outcomes. |
Record-Triggered Flows firing on status changes | Any record triggered flow that creates a new record for the core object is mapped as one of the initial process start points.
Any record triggered flow that fires on specific status transition is mapped as a separate step in the workflow.
If there are many record triggered flows firing on the same status transition, they are ordered based on their trigger order attribute from Salesforce. |
Autolaunched Flows | Any autolaunched flow that creates a new record for the core object is mapped as one of the initial process start points. |
Scheduled Flows | Any scheduled flow that creates a new record for the core object is mapped as one of the initial process start points. |
Screen Flows embedded in pages | Any screen flow that creates a new record for the core object is mapped as one of the initial process start points.
Screen flows are checked for root pages from which they are invoked by the user and also mapped into the process. |
Quick Actions | Any quick action that creates a new record for the core object is mapped as one of the initial process start points.
Quick actions are checked for root pages from which they are invoked by the user and also mapped into the process. |
Global Actions | Any global action that creates a new record for the core object is mapped as one of the initial process start points.
Global actions are checked for root pages from which they are invoked by the user and also mapped into the process. |
Related Lists | Used to infer secondary processes where related records (child objects) can be created from a parent record. |
Permission Sets & Profiles | For any step in the process that can only happen after user action (invoking quick action, global action, related list, using screen flow, triggering record triggered flow, transitioning record through statuses) we identify profiles and permission sets that allow those steps to be performed and we infer the human roles from their names.
For most steps we check who can create or edit the core object and compare it to who has access to a given page to perform the action to determine the actual subset or profiles and permission sets. |
Apex Classes | Any apex class that creates a new record for the core object is mapped as one of the initial process start points.
Apex classes are checked for root apex triggers from which they are invoked and also mapped into the process. |
Apex Triggers firing on status changes | Any apex trigger that creates a new record for the core object is mapped as one of the initial process start points.
Any apex trigger that fires on specific status transition is mapped as a separate step in the workflow.
If there are many apex triggers firing on the same status transition, they are ordered randomly as Salesforce cannot guarantee their order of execution. |
🚫 What’s Not Supported (Yet)
Mining different Salesforce metadata types, their dependencies, permissions, and many different configurations of all of them is a very difficult process. Below is the list of known gaps in the Process Configuration Mining which we plan to address throughout Spring and Summer of 2025.
Metadata type | What’s Missing |
Record Type Variations | Only Opportunity, Lead, and Case support record type-specific workflows. Other objects default to a single lifecycle based on all values of the controlling picklist field.
We will be adding ability to generate specific process for a selected record type. |
Dynamic Lightning Pages | Dynamic Lightning Pages allow to build a lot of conditional behaviour based on status changes.
Currently excluded; support is planned for future versions. |
Quick Actions in List Views | Button layout visibility not detected due to metadata limitations. |
Custom ‘New’ Action Overrides in related list | Not captured if the “New” button is overridden by custom components; support is planned for future versions. |
Platform Event Triggered Flows | Currently excluded; support is planned for future versions. |
Orchestrator Flows | Currently excluded; support is planned for future versions. |
Omnichannel Flows | Currently excluded; support is planned for future versions. |
Approval Processes | Currently excluded; support is planned for future versions. |
Apex Triggers and Record Triggered Flows firing on non-status changes | We account for record triggered flows and apex if they are tied to status change (e.g. from open -> closed) but not if other attribute is changed (e.g. lead qualification score is >85); support is planned for future versions. |
Legacy Automation: Workflow Rules and Process Builders | Workflow Rules and Process Builders are skipped by design. There are no plans to support this unless we hear from customers that this is critical to them. |
Assignment Rules, Escalation Rules, Auto-Response Rules, Duplicate Rules | Currently excluded; support is planned for future versions. |
Screen flows invoked by actions | We account for screen flows that create new records for the core object being analyzed that are embedded in pages, but we do not account for those being invoked via quick or global actions. |
Screen flows and actions available on the object, but not tied to status transitions | We account for record triggered automations firing during workflow transitions but not for screen flows or actions that are available to the user on the record page and need to be invoked at certain stages. |
Omniscripts | Currently excluded; support is planned for future versions. |
Visualforce pages | Currently excluded; There are no plans to support this unless we hear from customers that this is critical to them. |
Aura | Currently excluded; There are no plans to support this unless we hear from customers that this is critical to them. |
Data Cloud actions | Currently excluded; support is planned for future versions. |
Configuration Record Rules | Salesforce CPQ (SBQQ) and legacy Revenue Cloud relies on automations being driven by record configuration (price rules, product rules, price actions, etc.) These are not accounted for in context of process generation. |
🤖 How much AI is being used?
Process Configuration Mining relies on AI to generate the process diagrams. But Large Language Models are used very surgically, and 90% of the business logic is executed using deterministic algorithms by Elements automations. Here is how it works:
User asks natural-language question or query (uses AI 🤖 to interpret)
Elements finds relevant objects, fields, processes to analyze (does not use AI)
Elements finds automations that can create a new record on the object, finds how and from where they are being invoked, and who has access to use them. (does not use AI)
Elements finds workflow steps, users with access to change the status of the record, and any record-triggered automations and validation rules tied to status transitions (does not use AI)
Once we find metadata, dependencies, and permissions that are in scope, we use AI to summarize automation logic, infer role names, and infer most likely workflow transitions and their rationale to draw the diagram (uses AI 🤖 to interpret)
Elements.cloud by default uses OpenAI's 4o model for its Process Configuration Mining.
Today users have the ability to connect their own OpenAI account and choose their own model for that work.
We are soon going to start work on allowing our customers to connect to other LLM providers.
Frequently Asked Questions
Q: Can I generate a diagram for how the entire lead to order or opportunity to cash processes?
Not yet. Current version only supports single-object lifecycle diagrams (e.g., Leads, Cases, Opportunities). But you can generate a process for each object separately and review them sequentially.
Q: Are the diagrams editable after generation?
Yes. Once generated, you can modify the diagram just like any other Elements diagram. You can add sticky notes, make changes, raise stories and requirements - whatever you wish.
Q: How fresh is the data?
Diagrams reflect your latest metadata sync. If you're not seeing changes, try re-syncing your Org first.