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

Hi Enrico, I can't help you with #2, but we do have an idea submitted to document some general SugarBPM best practices in the documentation. It is idea # 92535, and if you submit a case with your request for this type of content and share that idea number, it would help us gauge interest.

If you can give examples in the case of the types of things you'd find valuable, especially if you have any wisdom of your own to share, that would help guide the content.

Hopefully someone will have some idea for your other question!

-Brenda

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

Thank you Brenda Rossetto 

I believe the Technical Advisory team used to have some best practices documents back in the day as well. Most might still be relevant.

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.

For sure, we don't want to lose that wisdom!

-Brenda