How to progress a BPM if any of a set of actions has been taken

[Aaron Carter]

Hello,

 

Is it possible to have a business process wait for any of multiple activities on a ticket? e.g. wait for email or update or resolution then progress if either have been completed.

 

Sometimes an email or update isn't required before we progress to resolution but we still want to mark the response timer based on the first email or resolution. 

 

thanks

 

Aaron

[Victor]

@Aaron Carter have a look at the "Suspend" section in the workflow configuration documentation:  https://wiki.hornbill.com/index.php?title=Service_Manager_Business_Process_Workflow

[Aaron Carter]

hi @Victor

 

I am familiar with suspend automations and have used them. the problem is when a process needs to wait for an email OR a request but not both. As soon as one of these two fields has been updated, the business process should continue.

 

Have I missed the part in the linked documentation that explains how to do this?

 

thanks

 

Aaron

[Victor]

@Aaron Carter ok, I understand, I misread your initial post. I don't think this is possible at the moment without extensive and rather (unecessarly) complicated configuration. We do have the parallel processing sequence however ending a parallel sequence only occurs when all paths have been completed. Therefore it won't work, for example if we set a path for each type of "Wait For: Resolution, Update, Email". Even if one of the suspend nodes resumes (following resolution, update or email) there will be the other two still in a suspend state that will prevent the of end the parallel sequence...

[HHH]

1 hour ago, Victor said:

ending a parallel sequence only occurs when all paths have been completed.

I would like to raise a development proposal to allow a choice of "Continue when all paths have been comleted" and "Continue when any path has been completed" on the end parallell sequence node

[Aaron Carter]

@Victor Thanks for the response.

 

I tried something that leverages parallel processing to achieve this, from my understanding it should work but maybe there are elements to the parallel processing that I don't understand.

Here is the BPM:

The idea is that we mark the response timer on the first event of either sending an email to a customer or resolving a ticket. Because our resolution pathway includes sending an email to a customer, I thought I could use parallel processing. If an email was sent to a customer, it marks the response timer and waits for the resolution process. If a ticket is resolved, it completes the resolution pathway and kicks of the email > mark response timer path. both paths then complete and the BPM progresses to the next stage. Hope that makes sense

 

however, when I tested this by creating then resolving a ticket, none of the resolution pathway processes were executed. I was the customer and didn't receive any emails and the checkpoint of 'resolution provided' wasn't marked. Checking the BPM for this ticket showed it was on 'wait for email'. Do you know why the resolution pathway wasn't executed as I'd expect in parallel processing?

 

thanks

 

Aaron

[Victor]

@Aaron Carter ok, now that I can see it, I realised this is not actually possible for a very simple reason which slipped my mind initially: you can't suspend two or more parallel paths at the same time with "Wait For..." nodes. I think this was discussed before, someone else tried something similar...  

[Aaron Carter]

@Victor Ah it's as I feared, it chokes on the first 'wait for' it encounters

 

Are there any plans to allow this sort of business process? either a parallel process that handles multiple 'wait for' nodes and will progress if any processes complete (as @HHH suggested), or perhaps a single 'wait for' node that accepts a list of processes, progressing when any have been updated? This would add tremendous value in allowing me to create processes that match my company's procedures

 

thanks

 

Aaron

 

[Gerry]

@Aaron Carter

Thanks for your post.  There is a stream of work where we are looking at a re-work of the current BPM engine, and some work around parallel processing is happening.  I am not sure about this particular use case, although from memory I think there is something in the design of the current implementation that makes this a limitation. I expect BPM 2.0 (which is the very imaginative internal name for this work) will address this.  For now though, its a bit of a limitiation

Gerry

[Aaron Carter]

@Gerry BPM 2.0 - that sounds exciting!

 

is there a current time frame for when this will be released? I'd like to know how long we will need to make the current BPM work to determine what sort of work arounds/process changes we should make

 

thanks

Aaron

[Gerry]

@Aaron Carter

Not currently, I can tell you that it is substantially implemented already but still needs work around the parallel processing. You should not have to do anything, its been designed to work with existing BPM's without you having to make any changes.  What it brings to the table is mostly a big maturity step-change.

* A clean design based on the last 5 years of evolution. 
* Significant performance improvements
* Better enablement for our application developers
* Improvements in the way the BPM engine handles parallel processes and asynchronous behaviour. 
* Vastly improved per-process error logging and reporting. 
* A vastly improved design-rule-checking and error reporting. 
* Extended design to support some enterprise features around object lifecycle management.

As for timing, it really should have been last year, but other priorites etc.  Its already well baked so subject to the outstanding changes and some fairly rigorous testing it most definitely should see the light of day in the next 6-8 weeks I would have thought. 

Gerry

[Guest Paul Alexander]

On 1/21/2021 at 11:33 AM, Gerry said:

@Aaron Carter

Thanks for your post.  There is a stream of work where we are looking at a re-work of the current BPM engine, and some work around parallel processing is happening.  I am not sure about this particular use case, although from memory I think there is something in the design of the current implementation that makes this a limitation. I expect BPM 2.0 (which is the very imaginative internal name for this work) will address this.  For now though, its a bit of a limitiation

Gerry

HI @Gerry

With regards to the parallel processing in BPM 2.0 do you know if this will allow us to 'break out' of a parallel process at any point please?

My problem is that I have parallel approvals happening, and I need to break out of this part of the process if any one of the approvals is marked as Tentative or Rejected, and then go off and do something without needing to wait for the other approvals in the parallel processing to finish. 

Hopefully that makes sense?! 

 

thanks

[Gerry]

@Paul Alexander

The very nature of parallel processing means that one thread cannot break the other threads of processing, so no, it would not be possible to break out of a parallel processing scope until all parallel threads are completed.

If this relates to athorisations, why not just the authorisation node that deals with multiple approvals and weighting etc...? this is what its built for

 

Gerry

[Guest Paul Alexander]

@Gerry

Yes, this is about authorisations but, as I can't assign the authorisation node to a group (or role) it's a bit tricky.

What I need is to be able to assign the one authorisation to a couple of different roles, and for that role to have the weighting assigned to it.

So, for instance, if I have 2 people in Role A and 2 people in Role B, and then have an authorisation node with a weighting of 50% per role, assign the node to both roles and have one person from each role update the approval. 

I know I can do this with individual PEOPLE, but not roles....and I think that's what I need (hence the parallel authorisations each assigned to a role)

 

[Gerry]

@Paul Alexander

Quote

What I need is to be able to assign the one authorisation to a couple of different roles

The authorisation scheme was conceived on the basis that authorisations are individual as opposed to collective responsibilities. From a business process point of view it sounds like a really bad idea to have a group of people responsible for an authorisation.  From a practical point of view, one has to manage the conflicts, like what happens if one approves and another rejects, is it a good idea that depending on who "gets there first" a business process could get either an approval or a rejection under the exact same conditions. 

The problem with weighting per role is that make things not only really complicated to implement, but also really complicated for people to understand.  I will take a look at that, as I am not really sure just how much of a change that would be, but given the auth system was built with a view of individual rather than group responsibility, I have a feeling thats going to be very complicated to implement. 

Gerry
 

[Guest Paul Alexander]

Thanks @Gerry

This has really only come about because of the amount of people who are off work at any particular time at the moment - what with people being on holiday, isolating and not available etc it seems that you can't rely on any one person to be available - hence wanting to get things assigned to a group or a role instead. 

It may well be that I'm making a mountain out of a molehill but I do like to try to make things as flexible as I can...but we'll always find a way around it if we need to 

[Gerry]

@Paul Alexander

Not at all, in my experience you are good at making things work well. I guess what I am curious about is can we make our approvals functionality more flexible to make it easier for you, but also to keep true to the overall design intent.  Instinctively, giving the responsibility of something important like an "approval"  to a collective where no one is responsible *feels* like a bad idea. 

Just a question, why not use a task, with appropriate outcomes to achieve what you want, unlike an approval, a task can in fact be assigned to a group or a role?

 

Gerry

[Guest Paul Alexander]

@Gerry

Good question....

I was trying to use a task when I first started doing this, but for some reason (that I can't now remember) I veered off into using the Authorisations, and seem to have gone down a rabbit hole and got a little confused! 

You're right though...I CAN do this (up to a point) with normal Tasks, and that's what I've now changed to so thanks for the nudge 

[Gerry]

@Paul Alexander

You said "up to a point", where do you run into limitations?

Gerry

[Guest Paul Alexander]

@Gerry

Up to the point of having multiple tasks in a parallel process, and being able to break out of that parallel process if any ONE of those tasks clicks either 'tentative' or 'rejected' without breaking the process.

 

[Steve Giller]

@Paul Alexander The nearest you have to that is to set an Expiry on the Tasks.

To be honest, though, Authorisations by multiple agencies would normally be staged, not parallel - for example if the 1/3 rejection is on the grounds that it's not possible/affordable, then having it approved is going to cause issues.