ChatGPT
Claude
Google AI
Copilot
An operations lead draws a chain of steps and a box labelled Salesforce at the end. Every step has a tick. None of them names the system it calls, or the record that should change. The chain looks finished. It is a poster. An integration names the system, the object, and the failure when the call does not land. A process step is not an integration until the system it calls is named. The object is the record that must change. The failure is a step that completes in the tool and never lands on that record.
Salesforce completed the acquisition of Regrello on 1 October 2025. Regrello does not replace every Flow. A step your org already runs in Flow, with a known rule and a known record, can stay there. Moving it for the sake of one chain makes two homes for one rule. Two homes drift. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Regrello on October 1, 2025."
The system is the one the step calls
A step that only talks to itself is a checklist. A step that updates a record in Salesforce, or reads a system you run, is an integration, and only then. Write the system in the step name. "Check stock in the inventory system we run" is a system. "Check stock" is a verb. Verbs do not land.
The system might be Salesforce itself. Say so. "Update the order record" names Salesforce as the system and the order as the object. The system might be one you operate outside it. Say the name your company uses. This page will not invent an API, a connector, or a package to sit in the middle. If you do not know the system, the step is not ready to draw. Leave it as work a person does, and name the person.
Regrello is the tool that may run the step. The tool is not the system being called. A diagram that shows only the tool has hidden the landing. You can finish every step inside the tool and change nothing a colleague sees on the record. That is the failure, and it is easy to miss because the tool's own log says complete.
Do not treat the whole company process as one integration. Break it at the calls. Each call is a line: this step, this system, this record, this failure. Steps that do not call anything are instructions to a person. Instructions are allowed. They are not integrations, and they should not be drawn with the same arrow.
The object is the record you named
The call lands when the record shows the outcome. Status, a date, a comment a person can read, a related record you meant to create. Pick the fields before you build. If you cannot point at them, you cannot test. "The process finished" is not a field.
Use a record you already report on. An order, a work item, a Case, a custom object you already trust. Inventing a parallel log inside the process tool gives you a second history. The people who live on the Salesforce record will not see it. They will keep working the old status. You will think the step landed because the tool moved on.
Write the identity of the write. Which user or integration context updates the record. What it is allowed to change. A context that can edit every field will eventually edit a field you meant to protect. List the fields. The list is the contract. A contract that says "update Salesforce" is the poster again.
A person still owns exceptions. When the step cannot call the system, the record should show a state a person recognises, and a queue or an owner. A silent retry that never changes the record looks like progress inside the tool and like stillness everywhere else. Stillness is the miss.
The failure is a completed step that never lands
Watch one item go through the step. The tool says the step completed. Open the record. The field you named is unchanged. The customer, the colleague, or the next system still sees the old state. That is the failure. The step completed in the tool and never landed on the record.
The twin is a landing on the wrong record. The step wrote, and it wrote to a sibling, a duplicate, or a previous version. Your test has to include the id. Completing against "an" order is not completing against this order. Put the id in the diagram.
A third shape is a Flow and the tool both writing the same field. You left the old Flow on because the new step was only a pilot. Both succeeded. The field shows whichever wrote last. You will not know which rule ran. Regrello does not replace every Flow, and it also does not automatically retire the Flow you forgot. Retirement is a decision. Write it next to the step. If the Flow stays, say what it still owns, and make sure it is not this field.
Do not accept the tool's green state as evidence. Evidence is the record, read by someone who did not run the step. Ask them what changed. If they cannot see it, it did not land.
What the diagram has to show
System: the named system the step calls. Object: the record and the fields. Failure: the step completes in the tool and the record does not change. You may add the owner for the exception. You may not add a connector name, a price, a daily cap, or a current screen. The source does not give them. You may not draw a single arrow that means "replace Flow".
| Name on the diagram | What you write | A poster instead |
|---|---|---|
| System | The system this step calls, by the name you use | A chain of verbs |
| Object | The record and the fields that must change | The tool's own log |
| Failure | Step complete in the tool, record unchanged | A tick on the last box |
| Boundary | Which steps stay in Flow, and which field they own | One box that says replace Flow |
| Out of diagram | Connector name, screen, price, cap | A logo in place of the record |
Read a step aloud. If you cannot say the system and the record, it is not on this diagram. Regrello and the process quote is where you decide what is in scope. What happened to Regrello is where you read the date and the ownership. Neither page is a reason to move every Flow.
What you refuse to invent
An API name would make the step look buildable. The source does not name one. Your architects can choose a call they already operate, and they can name it in the brief with the real system. This page will not supply a placeholder that sounds official.
A connector name has the same defect. The integration is the named call and the visible field. A brand in the middle, with no field, is a poster with a budget.
A current screen of a process builder would be out of date the moment a release moves a button. Describe the record. If a partner needs a screen, open yours. Do not accept a tour of a screen they cannot show in your org.
Leave prices and caps off. How many items a week the process sees is your measurement. It is not a limit published on the announcement. A step that already has a right answer in Flow should stay, even if a licence conversation is happening elsewhere. Do not migrate it to make a diagram symmetrical.
How you test that the call landed
Choose one step that calls one system and writes one record. Run one item. Read the record as a user who does the job. Confirm the fields. Run the item again and confirm you did not create a second write you did not intend. Then break the call. Stop the system, or use a value that should fail. The tool may show an error. The record must show the exception state you named, with an owner. If the tool says complete and the record is unchanged, you have the failure. Stop there.
Compare with the Flow that used to own the field. If both can still write, turn one of them off for this field before the pilot continues. Two writers are not a safety net. They are the last-write-wins defect.
For the first real week, read the exceptions, not the count of completed steps. Completed steps are what the tool is eager to show you. Unchanged records are what your operation feels.
Add the next step only when the first record changes in front of a witness. A long chain of green ticks is how the failure hides. One witnessed landing is how it stops.
People will ask for the whole process on one picture. Give them the picture after each calling step has a system and a record. Until then, give them the one step. A short diagram a supervisor can test is the integration. A mural is a poster.
One step, written as a contract
Take a step a plant or a back office already runs. A colleague checks that a shipment left, then tells the customer. Today that may be a Flow, a report, or a person with a list. If you move it, the contract is four lines. The system called is the shipment system you already operate, named as your company names it. The record is the order or the Case you already open. The fields are the date and the status you listed. The failure is a tick in the tool while those fields stay blank.
Put the four lines in the step title if you have to. A title that does not fit the system name is a title that will be abbreviated back into a verb. Verbs are how the landing disappears. Keep the system name where a supervisor can read it without opening a property panel.
Time the witness. One item, one record, one person who did not press the button. If that person can say what changed, the step is an integration. If they can only say the tool moved, it is not. Do not schedule the next step in the same week. The next step will have its own system. Stacking systems before the first witness is how a chain of ticks replaces a record.
A step that stays in Flow needs the same four lines, so nobody "integrates" it by accident. Write "stays in Flow" on the diagram next to the field it owns. Regrello does not replace every Flow. The sentence is an instruction to the team, not a criticism of the tool. Tools that overlap on one field will produce a record nobody can explain on a Thursday.
