# Integrating Apromore with Salesforce Apromore is process intelligence. It is not a migration tool and not a connector that moves records. The failure is treating a discovered path as a change already made. **Published:** 2026-07-01 **Canonical:** https://synconai.com/integrating-apromore-with-salesforce **Author:** SynconAI Architecture Team ## In short Integrating Apromore with Salesforce means naming process intelligence as the system, the path it discovered, and the failure of treating that path as a change already made in the org. The acquisition completed on 3 November 2025. Apromore is not a migration tool and not a connector that moves records. A diagram that skips the path and the failure is a poster. ## Sources - **Salesforce Signs Definitive Agreement to Acquire Apromore** (retrieved 2025-11-03) https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-apromore/ > Salesforce completed its acquisition of Apromore on November 3, 2025. ## What to take away - The system is process intelligence. The object is the discovered path. The failure is treating that path as a change already made. - Apromore does not migrate data and does not move records. It is not a connector. - Salesforce completed the acquisition on 3 November 2025. This page names no screen, no price, and no API. - Change the org in a separate piece of work, after someone accepts the path as a proposal. ## The guide A process owner pins a map on the wall. The map was discovered from logs. Someone in the room says the org now works this way. Nobody has opened a Flow, a validation rule, or a page layout. The map has been treated as a change already made. That is the failure. An integration here names the system, the object, and that failure. The system is process intelligence. The object is the discovered path. The path is evidence. It is not a deployment. Apromore is process intelligence. Salesforce completed the acquisition on 3 November 2025. Process intelligence reads how work ran. It can show a path people actually took, including the path nobody documented. It is not a migration tool. It is not a connector that moves records. A record does not change because a path was drawn. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Apromore on November 3, 2025." ## The system reads work. It does not move it The system takes events you already have and shows sequences. Who did what, on which record, in which order, and where the work waited. That reading is the product of the integration. The output is a path a person can argue with. The output is not an updated org. Say what you will feed it, in your nouns. Case history. Opportunity stage changes. A log you already keep. This page will not invent an API to extract those events, and it will not invent a connector that streams them. If your team exports a file they understand, say "a file of these events". If a platform feature they already use can supply the events, they can name that feature from their own org. A name this page coins would be fiction. Do not draw Apromore as the box that writes back. Writing back is a different system. If you later decide a path should become a Flow, that decision is a build. The build has its own test. The discovery diagram must not include the build as a dotted arrow labelled automatic. Automatic is how a discovered path becomes an unreviewed change. [Apromore and the process quote](/apromore-process-intelligence-salesforce) is where you scope the log and the question you are asking. This page is the boundary: seeing a path is not making a change. [What happened to Apromore](/what-happened-to-apromore) dates the close and states the ownership. It does not list your events. ## The object is the discovered path The call lands when a person can point at a path and say what evidence produced it. The object is that path: the steps, the records it was seen on, the period, and the count of cases you are willing to show. A path with no period and no count is a story. Stories are cheap. Evidence has edges. Write the question first. "Where do Cases wait before they reach the queue" is a question. "Improve the process" is not. The path answers the question or it does not. If it answers a different question, say so. A beautiful map of the wrong work will be treated as a change to the right work. That is the failure starting early. Name the record type the events came from. A path discovered on one Case record type does not describe another. A path discovered in one country does not describe the rest. Put the boundary on the object. People will generalise. The diagram should make the generalisation obvious and unpaid. The path is not a metadata diff. It does not list the Flows to edit. If someone wants that list, they write it as a proposal, after they accept the path. The proposal is a new object, owned by an admin, tracked like any other change. Keep it off the discovery picture so nobody confuses a finding with a release. ## The failure is a path treated as a change already made A team discovers that reps skip a stage. The next sentence in the workshop is "so the org no longer requires that stage". The requirement is still in the configuration. The reps are skipping it. Both facts can be true. Only one of them is a change to the org, and it has not been made. Treating the discovered path as that change is the failure. The harm is practical. Training material is rewritten to match the skip. A report is "fixed" to hide the stage. A new hire is told the official path is wrong. Meanwhile the validation rule still fires for anyone who follows the documented process. You now have two processes, and you have blessed the informal one without a decision. The other harm is a migration that nobody approved. Someone sees the path and builds a data load to "align" old records with it. Apromore is not a migration tool. A load that rewrites history because a picture suggested it is a data incident. Stop at the picture. If history should change, that is a separate brief with a backup and a witness. A connector that moves records would be a third mistake. This integration does not move records. Do not draw one. If records need to move, name that project, name the object, and name the failure mode of a bad write. Do it on a different page. Mixing it here lets a discovery tool inherit a write permission it should not have. ## What the diagram has to show System: process intelligence reading a named log. Object: the discovered path, with period, record type, and count. Failure: treating that path as a change already made in the org. You may show the question the path answers. You may not show a write-back, a connector, a price, or a screen. The source does not give them. | Name on the diagram | What you write | A poster instead | | --- | --- | --- | | System | Process intelligence over a log you named | A box that updates the org | | Object | The path, the period, the record type, the count | A map with no edges | | Failure | The path treated as a change already made | A tick beside the current org | | Boundary | Not a migration. Not a connector that moves records | An arrow into a data load | | Out of diagram | API name, screen, price, cap | A logo where the evidence should be | Read the caption under the map. It should say "discovered, not deployed". If the caption says "the process", you have already made the mistake. The process in the org is whatever the configuration does today. The path is what the log showed. ## What you refuse to invent An API name for extracting events would send a developer to documentation that may not exist under that name. Say which events you will use. Let the people who run the org choose the export they trust. A coined name is not a design. A connector name would imply records move. They do not, not on this diagram. Repeat the refusal in the meeting. Process intelligence is not a connector that moves records. A current screen of a mining product is a poster with pixels. Your viewers need the path and the caveat. If a vendor demo shows a screen, it is a demo. It is not your integration, and this page will not redraw it. No price and no cap. How much history you load is a choice about sensitivity and about volume you measure. The announcement does not set it. Do not invent a retention period to look precise. ## How you test that the call landed The landing test is not a changed org. The landing test is a path a sceptic can trace to rows. Pick one question. Produce one path. Have someone who did the work in that period look at it. They should recognise the steps, or they should tell you which event is missing. If they recognise it, you have a finding. Write the finding down as a finding. Do not open Setup. Then ask a second person, an admin, to confirm the org was not changed by the exercise. No new Flow. No edited validation. No data load. If any of those appeared, the failure has already happened. Back the change out. The discovery work does not authorise it. Store the path with its period and its record type in the place you keep decisions. When someone proposes a change later, they can cite the path. The citation is the integration paying off. The change, if you make it, gets its own test in a sandbox, like any other configuration. A sandbox test of a Flow is not a test of Apromore. Do not mix the sign-off. ::: warn Treating a discovered path as a change already made in the org is the failure. Apromore is process intelligence. It is not a migration tool and not a connector that moves records. Do not invent an API name, a screen, a price, or a cap. ::: When one question has a path people trust, ask the next question. Do not widen the log until the first path has a written boundary. A wider log produces a wider map, and a wider map is easier to mistake for the whole company. A partner who offers to "implement the process we found" in the same statement of work has joined discovery to deployment. Split the work. Pay for the path. Decide later whether the org should change. That gap is the control. Without it, the diagram is a poster that edits production. ## What the meeting is allowed to decide End the readout with a written choice, and keep the choices small. Accept the path as a fair picture of the period. Ask for a missing event and run the picture again. Or reject the path because the log was the wrong record type. Those three choices are in bounds. "Update the org to match" is out of bounds for this meeting. If someone wants that, they open a change request that cites the path. The request is not approved by the existence of the picture. Write the names. Who brought the log. Who recognised the work. Who confirmed Setup was untouched. Who is allowed to propose a later change. A path with no names will be forwarded as fact. Forwarded fact is how a discovered skip becomes the training standard by Friday. Keep the file of events in the same retention you already use for that record. Do not build a second warehouse for the exercise and then call the warehouse the integration. A second copy of Case history is a data store with its own permission problem. Process intelligence does not need a new home for the records. It needs a question and a period. When the question is answered, the path is the object you keep. The raw extract can expire on the schedule you already trust. If a later change is approved, test it the way you test any configuration. Sandbox. The users who do the work. The report that should move. None of that test result is an Apromore result. Label the two sign-offs so an auditor can see which one deployed. The discovery sign-off deploys nothing. ## Questions ### What system does an Apromore Salesforce integration have to name? Process intelligence reading a log you name: which events, which record type, which period. The acquisition completed on 3 November 2025. The system shows how work ran. It does not deploy configuration. ### What object does the integration land on? The discovered path, with its period, its record type, and a count you can show. The landing is a person tracing the path to rows. It is not a changed Flow, a changed validation rule, or a rewritten record. ### What fails if we treat the path as a change already made? Training, reports, and new hires follow a path the org still does not implement, or someone loads data to match the picture. Apromore is not a migration tool and not a connector that moves records. A change is a separate decision. ### Does this page name an Apromore connector? No. Naming a connector would imply records move. They do not. The cited page also does not give an API name, a current screen, a price, or a daily cap. Draw the log, the path, and the refusal to treat the path as deployed. ### Where should we read scope and ownership for Apromore? Scope the log and the question on the implementation page. Read the completion date and ownership on the what-happened page. This page keeps discovery and deployment apart. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).