SJEaton

I knew it would be something simple that you'd be able to spot!! Thanks @Victor, all sorted now

Hi @Victor 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. All looks ok in the config as far as we can see - see screenshots below. Any other ideas would be greatly appreciated. Thanks

@Victor I can't even see the screen shots anymore so I'll raise a new request and re-attach them

Hi Paul, I'm in the exact situation as you with a huge amount of linked request options so yes this may be helpful for me too! I won't be having a go at this until next week but do let me know how you get on. Thanks

Hi @DanielRi @Victor, can either of you assist with this? I think it got lost in amongst the other stuff, thanks

@Paul Alexander it might work if you have all linked requests in the parallel but if you have (at least) a path in the parallel processing that will not raise a linked request, and your workflow goes through this (or these) paths then there is no linked request thus you will have an invalid criteria for the expression. I've hit so many brick walls trying to get the suspend node to work. I really didnt think it would be this difficult! lol

OK. Try it and see

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.

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.

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

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.

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?

OK, thanks Victor.

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

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

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?

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.

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

Update, the following split still didn't work: 1. First condition is where you have "Remote Working is set" on it's own. 2. Second condition is where you have "Equipment Required 1 or Equipment Required 2" grouped together on their own. I therefore had to split the 2 override flags like this to make it work: 1. First condition - "Remote Working is set" and "Equipment Required 1". 2. Second condition - "Remote Working is set" and "Equipment Required 2" Hopefully this is all good now Sam

Thanks @James Ainsworth and @Victor. I've never created multiple override flags before so will have a go! Sam

Hi I have a Custom Form in an IC that has multiple Form Fields within it that have override flags configured so they are visible only if other questions are answered. Some of these questions are on the previous Custom Form and are therefore selected accordingly in the override flag conditions. I can't however get one of the conditions to work (see highlighted on the attached). The first condition is based on a question in the same form so works fine. The second condition is based on a question in the previous form and still works fine, but although the third condition is based on a question in the previous form (i.e. the same form as the second condition) the override flag for this condition is failing. I have checked and I am pulling in the correct answer. I wondered if it was due to the second condition not being answered and therefore being an empty string but surely the whole point of the 'OR' is to cater for that? I'm sure I've also got other similarly configured override flag conditions that work ok. Any ideas? Thanks, Sam

Hi @Victor Support request raised on 07/07/22 - IN00173142. This is pretty urgent as holding up development of a priority piece of work so hopefully this can be investigated soon.

@Victor ok we will raise a support request as we are definitely affected by this

Hi @Victor, Where has this got to? I'm having major problems with configuring a new IC with override flags in it. I have multiple override flags configured with particular questions selected in the conditions which work fine one day then when I log back in the following day, some of these questions selected in the override flag conditions have changed to a different question therefore meaning the override flags aren't working and the form doesn't display the questions it should. It's actually making me feel like I'm going mad and more to the point is very time consuming having to keep going in and amending the override flags again.