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.

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