Question about setting up Salesforce flows for our support team

For a year I built every flow with a single trigger, thinking it kept things clean. Yesterday our new ops lead in Chicago pointed out how it was causing a 15-second delay on high-volume ticket days. What's your rule of thumb for splitting triggers versus adding actions to an existing flow?

3 comments

3 Comments

terry83525d ago

Look, riverh49 is wrong about the delay. A single trigger with a bunch of filters still has to evaluate every single record that comes in, that's the real bottleneck. You need to split the work. I build separate flows for completely different jobs, like sending an alert versus updating a status field. It's not about filters, it's about not making one flow do ten things. That's how you get those crazy delays on busy days.

riverh4925d ago

Honestly I go the other way. A single trigger per object is my baseline for keeping logic together. Those delays usually mean you need better filters before the flow even runs, not more triggers. I'll add a fast field update or checkbox check right at the start to screen out records that don't need the full process. Splitting into multiple triggers just makes it harder to debug later when you have to track down which flow did what.

aaronsullivan25d ago

Wait, what happens when that single flow fails? Doesn't that break the whole process? I split triggers by what the business outcome is. Like one for auto-assigning tickets, another for priority updates. That way if one part has a problem, the rest still runs. Debugging is easier because you know each flow does one job. A single trigger with a bunch of filters and checks gets messy fast.