BPM Best Practice for Start Points - One complex, or multiple simple? What is your opinion?

Bud,

Great question. It will be interesting to hear everyone's views on this. I have had similar experiences.

With Sugar 10.3 you can have 1 start event for new or updated records (nearly every BPM I created previously I needed one for new records and one for updated records).

I tried using a fairly extensive Sugar Stock BPM for Follow Up Dates on Cases, but needed to modify it in certain areas and that was quite a challenge. The conclusion I reached with that was if you designed a complex BPM, you probably can troubleshoot it but for anyone else whilst not impossible it can be difficult and time consuming for them.

Generally, I try to have simple separate workflows in one BPM so that anyone can look at the flow and work out what its doing without having to deep dive. However, sometimes due to the nature of the workflow it is simply not feasible and in that case, I have to create less (or one) flows in the BPM. Finally, if necessary I will use Business Rules.

So in order of preference I will:

1. Try to create multiple separate flows in one BPM without Business Rules

2. Try to create multiple separate flows (but not as many in point 1) with Business Rules

3. Create one flow without Business Rules

4. Create one flow with Business Rules. 

The reason I try to avoid Business Rules unless essential is that they add a layer of complexity to determining why a BPM is failing. A Business Rule right at the beginning of a BPM is not so much of an issue particularly if it logically branches. But having Business Rules embedded along the way through a BPM starts to make things hard to diagnose. 

If you want some screen shots of examples to illustrate some of these points, let me know.

Hope this helps.

Hi Greg,

Thanks for your insight.  Yes, I'm also glad we have the option for a single start for new and changes in Release 10.3 - I went through my processes and removed the second start point on many of them.

I also share your preferences list. Part of my consideration is thinking that someday someone else may need to act on a process I've written.  Since the coding for some of my start points are fairly complex, it reminds me of the "spaghetti code" I wrote in assembly language in the 1970s.

My inclination is to split the start points into "simple" triggers that follow the same flow.  I started this discussion looking for opinions about having one complex start, or multiple simple starts.  I like the thought of being able to determine what condition triggered the flow.  I'm not sure if there's a performance implication of a singe or multiple start conditions.

Thanks again for responding.

You have raised an awesome discussion in here Bud Hartley

We like to have as few SugarBPM Processes as possible, so a single Workflow may have several start points, even if they don't converge at all. It is much easier to maintain.

Additionally we ALWAYS prefer Business Rules so the Process design gets cleaner.

A good and up to date documentation of Processes is always welcome so anyone, with access to, can understand and maintain without big deal.

In terms of efficiency I do believe that a single workflow with several star points and several workflows with fewer start points may not change that much. Additionally Business Rules trends to work just like a "switch case" statement, that means it should be fast enough.

BTW, earlier I programmed in Fortran 77, so I'm glad to know someone from old school. 

Regards

Thanks André!  I'm thinking I'll probably split the some of the complex start logic into multiple starts that take the same flow in the process - It will certainly make it easier for someone else to sort out what i've done. I'm liking the idea of being able to determine what criterion triggered the process.

I like the comments "bubbles" in BPM and some of my processes are too large for the screen because I have comments at almost every branch, next to the Business Rules, and near every send and receive message.  Sugar BPM and Studio are both great tools.

Hello Bud Hartley,

Just to add some more discussion to the performance aspect, a process definition with a single start event that has a large condition set is likely going to be more performant than a process definition with several start events that have simpler/smaller condition sets, though the difference really depends on the process definition. There are a couple of main reasons:

1. Since each start event can only be triggered once per record save, then a process definition with one large start event will only trigger one process at most. If you instead have multiple simpler start events on that process definition, each one of those that passes its conditions will trigger a process from the record save, which could cause the BPM engine to take a bit longer to finish if it has to work multiple processes.

2. Following #1, if multiple start events cause multiple processes to be triggered from a process definition, the BPM flow table will likely grow faster. Over time, this could contribute to a performance slowdown of BPM if the table becomes too large.

That said, there are benefits to splitting a large start event up into several smaller ones as you noted: simplicity of editing the process definition and being able to see which of the start events triggered the process at #pmse_Inbox/layout/casesList. I don't know if there is any official best practice for which way to choose, just thought I'd chime in with some performance thoughts.

Thanks Eric!

I've split a few of my complex starts into multiple start events that are in the same process.  I haven't seen a performance degradation, and having the ability to see which condition triggered the process is helpful.

I have a couple of cases where a record save triggers two disparate processes, and the addition of the Run Order a couple of releases back and the use of timers to delay operations helped to prevent collisions.  In my case, having two processes for a single save was done to simplify the logic of a complex process that involved separate organizations in the company.

I appreciate the insight folks have offered.   

Thanks Eric!

I've split a few of my complex starts into multiple start events that are in the same process.  I haven't seen a performance degradation, and having the ability to see which condition triggered the process is helpful.

I have a couple of cases where a record save triggers two disparate processes, and the addition of the Run Order a couple of releases back and the use of timers to delay operations helped to prevent collisions.  In my case, having two processes for a single save was done to simplify the logic of a complex process that involved separate organizations in the company.

I appreciate the insight folks have offered.