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.

Hello Bud,

Thank you for your question.

I would like to touch some theory - specifically, the generic meaning of the "starting point" of the business process; for doing that it is suggested to temporary put out of the equation the particular engine that implements BPM in the particular software

I ask myself, whether speaking of the "starting point" of the process we usually mean a) the object (or set of objects) involved and b) the set of conditions or criteria which are so important in some meaning, so that if those are met for the object(s) we treat the situation as fairly important - at least important enough for triggering the sequence of actions (process/procedure/workflow - whatever terminology is prefered)

If to agree with this general meaning, let us note that the "key fact" or, in other words, "logical key event" is identified in a very moment when logical criteria are met for the target object

That is a real trigger.

I have to admit, that sayin the "logical key event" in the meaning of a combination of logical criteria, I also do oppose it to the "physical event" - the primitive of the field value change logged or linkage logged.

So, the "logical event" is the starting point of the process run

Usually, the logical key event - as a conclusion about criteria met - is also a subject of interest for CRM users and a must-be subject for the reports - remember the statistics - about 48% or companies don't get important info from their CRMs - maybe they just cannot be aware on time about key events happened as well as key events expected, but NOT happened- because that is pretty the situation not to miss in CRM (otherwise why it deserves an automated workflow to run, isn't it?)

If to use the criteria of the logical key event happened for collecting events as the records of the Object's Timeline, then you won't need to bother about complex criteria for starting the BPM anymore - all you would need is to fire the workflow on "logical key event" of particular type is recorded on the timeline

Again, because the logical key event identified is the real trigger and starting point for all the workflows, also in the CRMs

The Timeline and Key events collection in Sugar is provided with TImeLine Viewer addon
The criteria for the logical key events collection could be configured with Logic Builder flowcharts.

I hope this could help to choose the approach

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.