enhancement Assign to Owner (Variable) does not fail gracefully

[Martyn Houghton]

Thought the Request > Assignment >Assign to Owner (variable) node has a outcome indicator to pass whether it was sucessful or not, it doe not fail gracefully when it is not able to assign the requests based on the variable being passed.

Instead it creates a BPM Error.

Can the node be updated to continue the BPM but report the outcome as a failure. That way we can control how to handle it not being assigned in the BPM logic itself.

Cheers

Martyn

[Bob Dickinson]

Hi @Martyn Houghton

The issue with a graceful fail here is either you could easily end up potentially with a task without an assignee/team OR the task not being generated, which would mean the BPM loses some of it's integrity - and could cause confusion for all parties. 

The solution here is to perform the "User Validation" BEFORE you create, and assign the task to them - and this is something that can achieved right now.
You would simply pass your User Variable into a "Get User Details" node - which looks up and sees if this user exists on your system. This DOES fail gracefully if it doesn't find a match - and if it doesn't find a match, the resulting User ID from the output of the node will be null (and then you can perform whichever decision logic is required). 

Below is an example using Checkpoints based on whether the User exists:

 

And the Get User Information node can be found here:

 

Kind Regards

Bob

[Martyn Houghton]

@Bob Dickinson

This only checks half of the problem. I need to check that the user is also a member of the team as well that the request is being assigned to.

In terms of the request assignment, I always do a get request details and check the 'Request Assigned Yes/No' which then branches to wait for Request Owner before a human task is created.

Cheers

Martyn

[Bob Dickinson]

Hi @Martyn Houghton

There is another option that might accomodate this which could even be used in conjunction with the above. 
We have a "Get User Groups" node - which can output up to 10 groups (relating to a specific defined type e.g. Team, Department, Company, etc).

You could call this node, and feed in:
User ID: The user ID you are evaluating
Group Type: Team

And off the back of it, you would have a decision node, with the criteria something like:
 

IF Organisational Group One = 'Data Consultancy'
OR
Organisational Group Two = 'Data Consultancy'
OR
Organisational Group Three= 'Data Consultancy'
OR
Organisational Group Four = 'Data Consultancy'
ETC...
ETC...

This way, again you are checking that the User ID is a member of the group before trying to assign the task to them. If they aren't, then you go down the No Match route, which is however you want to deal with that. 

Again, I appreciate this isn't as elegant as what you desired in your original post but it should be possible logically to achieve today

Kind Regards

Bob

[Martyn Houghton]

@Bob Dickinson

Thanks for the assistance. That will allow us to mitigate most of the issues, but we do have a large number of teams relating to our different product areas which people are members of.

I am presuming the 'outcome' from the node is not actually used?

Cheers

Martyn

[Bob Dickinson]

@Martyn Houghton

No problem. 
The outcome for ALL nodes is used and should always have a value once it's been processed (to see what is recorded, you can use an "Update Details" or "Update Timeline" node place directed after the node you are testing, and inject the outcome into the description/timeline of a ticket to see). 

The issue is (as you reported) that some nodes - such as task assignment - also error is they fail, and are not elegantly ignored/bypassed. This is node specific, so in those scenarios a decision on the outcome isn't going to be of use as the BPM has already errored anyway so you can't continue. 

Kind Regards

Bob