Set up workflows for parent and linked requests

[SJEaton]

Hi @Berto2002, I'm interested to see that you opted for a serial approach rather than a parallel process.  I am currently configuring a large parallel process myself and having trouble working out how to get it to achieve what I require. I was wondering if parallel processes within parallel processes was achievable but not sure it is, so this approach may be a better option for me.  Can I ask, do you also have a node after the serial approach that awaits resolution of all the linked requests that may have been raised before closing the requests? If so, are you happy to share the config of this node please?

Sam    

[Berto2002]

Hi @SJEaton, no I do not have such a node, I'm afraid. We resolved that this could introduce a great deal of complexity so we decided to accept that the newly created requests would be free-standing and have their own resolution cycles. we cover that with a note in our new starter process resolution that says, roughly, "Other tickets may have been logged to provide resources for your New Starter; please check your portal view for their progress. This core New Starter Request is now resolved."

[SJEaton]

Hi @Berto2002, our linked requests will also have their own resolution, but we don't want to update customers via those requests as felt they would be bombarded with too many requests and get confused. Ideally, we just want to update the 'parent' request to confirm when they have all been resolved, and only then will we resolve the 'parent' request and inform the customer that the new starter request has been processed.  It's true that this has introduced a great deal of complexity, but I won't be defeated quite yet lol. 

[Steve Giller]

@SJEatonIf you have a number of child requests I don't see a need to have any kind of parallel process.

The child requests will have their own workflow and be completely independent, they can update the Parent Request (which can then update the Customer) and the only thing you need to ensure is that the Parent cannot be closed without all Child Requests being closed first.

[SJEaton]

2 minutes ago, Steve Giller said:

@SJEatonIf you have a number of child requests I don't see a need to have any kind of parallel process.

The child requests will have their own workflow and be completely independent, they can update the Parent Request (which can then update the Customer) and the only thing you need to ensure is that the Parent cannot be closed without all Child Requests being closed first.

Hi @Steve Giller, yes the child requests do have their own workflow and do update the parent request. The parallel process was going to merely raise all of the various linked requests that may be needed for such things as system access, new equipment, remote working for the new starter as they are actioned by different teams.  But that's why I now think the serial approach will be much better.  My only concern is that when certain groups of linked requests are resolved I want the parent ticket to set relevant checklist items on the HUD and I'm not sure where to put these nodes in the workflow. 

Example:

There are 3 potential linked requests that may be raised if equipment is required (1, 2, 3), and there are 3 potential linked requests that maybe raised if system access is required (3, 4, 5).  

The parent request will be waiting for all linked requests to resolve, but when 1, 2 and 3 are all resolved, checklist item "equipment issued" should be checked and when 3, 4 and 5 are all resolved, checklist item "system access granted" should be checked.   

This could happen at different times, and I assume will follow a 'wait for linked request resolution' node but how do I configure these nodes to cater for this?       

Attached is a rough example with 2 'wait for linked request resolution' nodes in them but I'm not sure this would work?? (the variables aren't configured properly yet so I can't test it). Am I on the right track though or way off? 

[SJEaton]

[Victor]

@SJEaton

36 minutes ago, SJEaton said:

Am I on the right track though or way off?

Depends...

"Wait For Linked Request Resolution"... what is that? Can you screenshot the node setup?

 

[SJEaton]

Hi @Victor, well that's just it, what do I need here? lol  This is the node setup as it stands  

[Victor]

@SJEaton you cannot have a "wait for linked request resolution", the functionality is not there. What you have above is a simple wait for resolution on that particular request, not the linked one.

If the main goal is to have the "parent/main" request active and reacting to events on the "child" requests, then in theory, you can achieve this in different ways.

First, it would be problematic to achieve the "HUD update" in the parent request based on events on the linked requests. The only way I can think of is to make use of the "Wait for Request Update" in the parent request in a somewhat semi-permanent state. The linked requests will push an update on the parent request. Based on this event you can drive the workflow on the main request to perform various actions. I say this is problematic due to the semi-permanent suspend state of the main requests which basically "blocks" the main request at that stage, at least until all linked requests have been progressed to a certain stage (e.g. resolved). The workflow in the main request will also have to cater for updates other than the ones coming from linked requests (if there are any).

Another idea would be to make use of custom fields on main requests that will be updated from linked requests. You can have each linked request "associated" to a custom field in main request to reflect the stage of that linked request. You can then make the custom field visible in the main request details section, thus mimicking the HUD. This solution would require pushing the main request data (e.g. reference) into the linked request so the linked request knows where and what to update in the main request.

Another solution, which would be perhaps the least complex would be to make use of human tasks. For each linked request you would have a human task in the main request. The human task will be completed once the corresponding linked request has been progressed to a certain stage (e.g. resolved). The main downside of this approach is the human interaction required to action on the tasks.

EDIT: I have also split this conversation from the other thread as it is now discussing something different than what that thread was discussing.

[SJEaton]

48 minutes ago, Victor said:

The only way I can think of is to make use of the "Wait for Request Update" in the parent request

Hi @Victor, yes I have already configured the child requests to update the parent request timeline when they are resolved and then the parent request can update the HUD so I understand the configuration needed here.  What I can't get my head around is how I cater for waiting for different groups of linked requests to all be resolved (and the parent request updated) before the HUD checkpoint is ticked. 

I'm not sure I want to (or could) use custom fields as we use so many already in the IC.    

Your other suggested solution about using human tasks is also not preferred due to the human interaction needed.

I've attached a high-level overview of what might happen when a new joiner request is logged.  There may also be other parent request tasks / linked requests raised but this is the basics which I hope gives you an understanding of what I'm trying to achieve.  I guess the bit I'm struggling with is waiting for the multiple parent request timeline updates to be received before updating the "system access granted" HUD checkpoint so if you can advise on the best way to configure this that would be great, thanks Victor

 

[Victor]

13 minutes ago, SJEaton said:

What I can't get my head around is how I cater for waiting for different groups of linked requests to all be resolved (and the parent request updated) before the HUD checkpoint is ticked. 

@SJEaton you can try my first suggested approach where you put the main request in a semi-permanent suspend state, only resuming briefly at certain intervals and performing various actions (e.g. HUD update) based on what even triggered the resume. I think at this point it would be more beneficial if you can discuss this in more detail with a product specialist to cover the complex aspects involved here and perhaps identify a different approach that could work better.

[SJEaton]

OK, thanks Victor.  

[Hornbill Staff DR]

@SJEaton nice, always great to see advanced capability being explored!

I'll first cover off how we can wait for a linked request to be resolved. While there isn't a specific business process operation which waits for linked request resolution, we can actually use the operation "Wait for Request Resolution". Indeed, this is typically used to wait for the resolution of the request against which the BPM is running but, if we switch the "Request ID" input param to "variable" and inject a variable which contains a request ID belonging to one of the linked requests, then this node will actually wait for the resolution of the request ID specified. You can get a request ID by using an output variable available in the "Log Request" node which is logging these child requests from your BPM.

Now, focusing on your requirement a bit more specifically, you have several child requests which may be resolved in any order. So as you have surmised, you're going to need a parallel processing block that has several "Wait for Resolution" nodes corresponding to each child request. Unfortunately, I don't believe the business process engine is capable of handling multiple suspend nodes in a parallel block. When the engine resumes a suspended process, I believe it sends a generic "resume" instruction which doesn't include any node identifier. So basically if the process is waiting at multiple suspend nodes, when the resume instruction is given by the system, it doesn't know which node it needs to unsuspend.

This is what I encountered the last time I tried this approach, and I believe that's still the case. Perhaps you could try and confirm that is so?

Dan

[SJEaton]

Thanks @DanielRi, that is what I feared.  I think you are right as on an earlier, slimmed down version of the BPM a few weeks back I did gain advice and get something working but the suspend node had to be outside of the parallel process. At the time I had only configured the System Access elements of the process though so now I'm introducing Equipment and Remote Working etc, I'm not sure it would work, as I don't know how I would get the different HUD checkpoints ticked at the relevant times (i.e. when all of the relevant linked requests/activities have been resolved??

  

I had therefore started to explore the serial approach yesterday, but it seems I've come full circle lol.   Do you think there's potential to achieve my requirement using a serial approach instead of a parallel process?   

[Hornbill Staff DR]

Hi @SJEaton,

 the serial approach should technically work, but I suspect it wont have precisely the desired affect when it comes to the checkpoints.

In essence, you're wanting to use the checkpoints as an indicator showing when each of the linked requests are complete. When things are configured in series, it means there is a definite order and one thing has to happen after another. If you set your checkpoints up in series, lets say your last one is "Equipment Issued" even if the corresponding linked request is resolved first, that checkpoint wont be marked until the workflow has passed through the other checkpoints in sequence.

So ultimately, yes, all your checkpoints will eventually get marked, but there will likely be a situation where a linked request is resolved but the corresponding checkpoint is not checked because the workflow is still waiting for one (or more) of the other linked requests to be resolved first.

I'd dispense with the specific checkpoints and perhaps have a single one which indicates that "User Provisioning Actions Complete" or something generic like that. This will only be marked when all the linked requests are resolved. If an agent wants to see what's still outstanding, they should be directed to the linked requests section where they can inspect the status of the linked requests. 

I hope that helps.

Dan

[Guest Paul Alexander]

Hi all

I'm just gatecrashing this party because - well, why not?!

We have a similar situation to @SJEaton (I think!) where we have a new starter process which MAY kick off any number up to 15 separate linked requests (dependant on whether the starter is directly employed or a sub-contractor, and what their job role is etc)

These DO need to be linked requests as each of those requests has it's own process which will fire off emails and automatically set up accounts etc, so they can't be Human Tasks.

It would be really beneficial to us if we could know when ALL of the linked requests are resolved, as that would then be the point when we could tell the customer that their request for a new starter is complete, and that they do have access to everything that they need access to (and any hardware has been procured/built/sent out etc)

So, could there be a suspend node which would wait until ALL of the linked requests are showing as resolved? I know we can't have more than one suspend node in a parallel process (I've tried it!) but one which sits outside the parallel process waiting for all of the linked requests to have their statuses updated to Resolved would be helpful.

OR, failing that, a suspend node which waits for a field to equal a specific string?

 

My thoughts here are that the Parent Request will have a number of decision trees.

• If the decision equals one thing, then it triggers a linked request.
• If the decision does NOT equal that 'thing' then it updates a custom field in the Parent Request with a 1
• In the linked request, once that is resolved, a node in that BPM will update the linked request (Parent Request) custom field with a 1
• In the parent request, the suspend node waits until the custom field = 11111 (however many decisions are calculated in the parallel process)
• Once that custom field DOES equal 11111 then it continues. 

I don't know if that's even possible, but I thought I'd ask anyway? 

[SJEaton]

Hi @Paul Alexander, in simple terms, yes I think so.  I have included the suspend node after the parallel process end so it then awaits all linked requests to resolve. I haven't fully tested all of the scenarios yet but think this works in principle. 

[Guest Paul Alexander]

Hi @SJEaton

Which node are you using to wait for all of the linked requests to resolve please? I can't see any nodes which will wait for ALL of the linked requests to be updated - only a specific one? There's always the chance that I'm just not seeing something of course!!

[SJEaton]

Hi @DanielRi, following up to our discussion on Monday, I'm still having trouble getting my linked requests to raise correctly.  I've checked the workflows attached to the catalog items and the spelling, but they still are raising another New Joiner request rather than the catalog items that I want them to raise e.g New Joiner Equipment Order or New Joiner Existing Equipment. Both myself and Adrian are baffled as all looks ok in the config - see screenshots below. Any other ideas would be greatly appreciated.  Thanks

   

[SJEaton]

1 minute ago, Paul Alexander said:

Which node are you using to wait for all of the linked requests to resolve please? I can't see any nodes which will wait for ALL of the linked requests to be updated - only a specific one? There's always the chance that I'm just not seeing something of course!!

It's just this one node which seems to wait for all of them.  As I said, it's not fully tested yet but try it and see.

  

[Guest Paul Alexander]

Ah I see....thank you. 

That's going to wait until that one linked request is resolved...(the id as entered in the 'Request id' field).

I need it to know when ALL of the linked requests have been resolved...not just one specific one.

[Victor]

12 minutes ago, Paul Alexander said:

That's going to wait until that one linked request is resolved...(the id as entered in the 'Request id' field)

Has this been tested by any of you? Afaik, this will not work as you think it does and this is because how the suspend/resume works in the background. I'll try and give you a broad overview: one each (or most) actions performed on a request (e.g. update, resolve, escalate, email, etc.), the last bit the action does is invoking a "processResume" API. This API will retrieve the relevant workflow based on data from where the API was invoked (important). It will then check the workflow and see if a) is it in a suspend state and b) if yes, is the suspend sate waiting for the action (that was performed) to be performed. If yes to both it will resume that workflow, if no then it will keep it suspended.

Let's have some examples, to make it a bit more clear. Request 1 has a workflow A that is configured to raise a (linked) request 2 that has a workflow B. Then in workflow A you set a "Suspend Wait For Resolution" and set the request ID input param to use the variable that has the value for request 2. When request 1 is raised, it spawns workflow A which will the progress, raising request 2 that spawns workflow B. Workflow 1 then suspends waiting for a resolution having request ID param for request 2. At this point you navigate to request 2 and resolve it. Here is where things might not proceed as you would think and I will refer to the underlined statement above. So, when request 2 is resolved, part of this action is invoking "processResume". This API will get the data based on the request from where the resolve action was performed which is request 2. This request has workflow B. The "processResume" will then open workflow B and checks the a) and b) above... You can see now that when the resolve action was performed on request 2 there was no action on workflow A which is the one we would have expected or wanted to resume... makes sense? So in order to resume workflow A you would need an action on request 1 - which will have a "processResume". So even if you have "Suspend Wait For Resolution" (in workflow A/request 1) with request ID input param as request 2, you still need an action on request 1 to trigger "processResume" for workflow A...

Now, the above is from what I remember of how this suspend/resume was designed, might have changed although I did not see any code changes to suggest that... so worth a test but if it does not work as you would think it would even with the request ID param set for the linked request, the above is why...

However...however... having an automated node that will action on a different request (by using a different value for the request ID param) does for for other types of automation...for example you can use a "Update Request" having another value for request ID param which will update this other request... but this logic does not apply to suspend/resume nodes due to how resuming triggers and executes as described above...

[SJEaton]

5 minutes ago, Victor said:

Has this been tested by any of you?

I tested this one in a previous BPM (based on advice I received from you in a previous topic on here) and it did work.

[Guest Paul Alexander]

 

I'm pretty sure that if you resolve the request whose ID is in the 'Request ID' field here that your process will continue, regardless of whether the OTHER linked requests have been resolved?

 

[SJEaton]

OK. Try it and see