Most process models end up as documentation. Someone draws the process, the people building the system read it, and from that point on the diagram and the implementation go their separate ways.
Last week a Salesforce consultant showed us a setup where that gap is a lot smaller than usual. He models the process in Crismo, exports the BPMN file, and imports it into Salesforce, where it runs as a process plan on top of a case. No re-interpretation along the way.
How a BPMN model from Crismo runs in Salesforce
A Salesforce consultant built what he calls a lightweight process management accelerator inside Salesforce. Lightweight because it always runs in the context of a Salesforce object, typically a case. Generic because the minute you create any object, you can run a process against it.
The interesting part is where the processes come from. He exports a BPMN model from Crismo, uploads the file into Salesforce, confirms once, and a new version of the process plan is live in the system. Not a picture of the process. The actual executable structure.
Every task in the BPMN model becomes a step. Every gateway becomes a decision point with result codes, which are the labels on the sequence flows. A comment on a task becomes the help text the agent sees when they reach that step. Where he attached an AI prompt to a decision, the process evaluates the case data on its own and picks the route: escalate, reject, move on. Where a step needs a guided interaction, he ties in a Salesforce screen flow. Where a step should be automated, an automation definition links it to a Salesforce flow, and the result code decides what happens next.
The whole thing renders as a clickable map inside the case. Glyphs show which steps are automated, which are in progress, which are done. You can click into a step and see why the AI decided what it decided.
None of that was built for a demo. He is using it at a client with a large process estate, many processes deep in sub-processes.
Why process management in Salesforce usually breaks down
The obvious reaction is "nice integration." The real point is what it does to the economics of process work.
In the classical process management cycle you design, you execute, you measure, you improve. The reason most companies never complete that loop is that each stage lives in a different tool owned by different people, and the handovers are where everything dies. The process model sits in a documentation tool. The execution logic sits in the CRM configuration. The stats sit in a report someone runs quarterly. Nothing connects, so the model goes stale within weeks and everybody stops trusting it.
With this setup, the model is the execution logic. Change the BPMN process in Crismo, re-import, and Salesforce is running the new version. There is no drift because there is nothing to drift between.
His own words on a process estate that size: there is no way you get that right on the first go. Which is exactly why he built step-level statistics into the accelerator. Time per step, time per plan instance, averaged across every run. Look at the numbers, find the step where people spend too long calling the client back, go fix the model, re-import. That is the improve stage of the cycle, and it becomes a routine afternoon task rather than a project.
Bringing Salesforce execution data back into the BPMN model
What he showed us is the model flowing from Crismo into Salesforce. What we are building now is the execution data flowing back.
We already have a working pilot with an ERP system where execution counts, task durations and deviations show up directly on the BPMN diagram in Crismo. Heatmaps for where approvals pile up. Markers for where reality skipped a step the model says is mandatory. The same view for Salesforce is a matter of mapping, not architecture, and it is next on the list.
Two ways to get the data across. Either an agent reads the stats out of Salesforce and writes them onto the process attributes via Crismo's MCP server, which works today. Or listener events in Crismo map directly to Salesforce tasks and build an event log the classical process mining way, which is what we are finishing now.
Either way, you end up with one place where the approved process, the running process and the measured process are the same object.
Who Crismo plus Salesforce is for
If you own Salesforce processes and you have more than a handful of them, you already know the pain. The flows are in the system, the documentation is somewhere else, and the person who understood the original design has moved on. Managing 120 flows as configuration is hard. Managing 120 BPMN models with versioning, comments, attributes and a visual landscape is what Crismo does all day.
If you are a Salesforce implementation partner, this changes the conversation with your client. Instead of "we will configure your processes," it becomes "your team will own and iterate their processes, and we will automate the parts that deserve it."
We are looking for a small number of design partners to build the full loop with. Salesforce shops, or their clients, who want processes designed in Crismo, executed in Salesforce, and measured back in Crismo, at a design partner price. If that is you, get in touch.
Try it yourself
Design the process once, run it where the work happens
Real BPMN, fast to model, organised into value streams. No signup needed to start.