SugarBPM and performance, best way to reduce the amounts of saves on a module?

Hi Enrico Simonetti ,

With regards to #2, I don't think it would be a good idea to consolidate actions within a process to a single save event. Each action on a process should be treated as its own event in my opinion. I understand the desire to make things more performant, but there are scenarios where those actions need to save independently.

When accounting for elements like wait timers, event-based gateways, etc., I don't know how you could group specific actions within a design to complete together without causing potentially unintended side effects whether it be in the same or another definition.

Chris

Hi Enrico Simonetti ,

With regards to #2, I don't think it would be a good idea to consolidate actions within a process to a single save event. Each action on a process should be treated as its own event in my opinion. I understand the desire to make things more performant, but there are scenarios where those actions need to save independently.

When accounting for elements like wait timers, event-based gateways, etc., I don't know how you could group specific actions within a design to complete together without causing potentially unintended side effects whether it be in the same or another definition.

Chris

Hey Chris Raffle ,

Hope you are well!

Thanks for your insights.

In my opinion, the system should be "smart enough" to understand if actions are subsequent, on the same path, and change some fields, and some other fields and some more.

Why would those be treated as 3 separate save actions by the system and not one? Or at least the system could notify the user who is editing the process to optimise and combine the actions into one. I personally did not expect multiple saves, one for each subsequent action.

Do you see this system improvement could potentially create problems?

To give you a little bit more context, in this specific case, the customer had multiple BPMs, multiple actions per BPM, sugar logic formulas, related (circular) formulas and multiple logic hooks.

A record save would take 45+ seconds. This would happen on the first save and on every subsequent save (even just a change of a description field). Which was unbearable for the users, hence they reached out. There are valid reasons why they needed each component (related records that needed savings, shortcomings etc). And every save would re-trigger most of the logic outside of the BPM again.

This time, I had to write substantial backend code to achieve the same outcome, refactor the formulas, the hooks and the BPMs for optimised performance. The system now runs only the logic absolutely needed, when needed. Now only if all the business conditions need to trigger, a save takes about 30 seconds (which normally happens once per record only), then every other change takes < 2 seconds, which is a massive improvement. You could argue that potentially is less flexible to change for the future (which is also a positive for critical business processes that need deep testing such as this one), but it produces a big user experience and ongoing productivity improvement.