enhancement Ability for a decision node to check a simple list?

[Guest Paul Alexander]

We have a request which will be used to log a 'new starter' ticket and that new starter will have specific hardware, software and access options based on their job role.

So, the person logging the request will select the job role (we have 65 so far!), and, based on that job role, we need the process to be able to select whether that job role requires a laptop, a tablet, an email address, access to the finance system etc.

I'm trying to get find the easiest way of doing this - and, at the moment I have the IC form look at a simple list containing all of the job roles. Then the BPM has a ton of decision trees which are filtered based on whether the selected job role is in the 'expression' of that decision. If so, then it can trigger a task. 

This is very messy, and it means that, if a new job role is added, then I have to go through each decision tree and update it if required.

What I think would be easier would be if there was an option in the decision node to say whether the selected job role is in a Simple List, rather than the list included in each node. That way I could have Simple Lists for each 'expression' (so if Job Role 1 is included in the Simple List which requires a laptop, then order a laptop). I think that managing Simple Lists rather than decision nodes in a BPM would be much easier. Especially when a change is made!

 

Any thoughts please?

 

[Adrian Simpkins]

+1 from me as I have had a similar thought rolling around for a while about doing this exact same thing for decision tree config

 

[Berto2002]

+1 because I can see how having access to external reference data could be very useful in workflow design.

Paul, have you considered using custom fields for this? I was thinking along these lines:

• Assuming you have a fewer number of "entities" (email, laptop, tablet, etc) than custom fields with unlimited strong length (15: p - t and 31 - 40)
• The custom fields would act like simple lists insofar as they have strings which can be detected by expressions
• Pick a Custom field for each "entity"
• At the start of your workflow, have a node that sets the value of each custom field above to have a bunch of roles listed that are entitled to that "entity".
• E.g. Custom P contains 60/65 of your roles literally like this
  • Account_Director , Authorised_Engineer , Customer_Director
• And then Custom Q lists the roles that should have tablets; etc
• Then, each expression will have a long but fixed expression along these lines:
  • For the laptop choice: If Custom P contains "Account_Director" OR "Authorised_Engineer" OR .... [all roles]; then go for the task else No Match
  • Then the next Decision has exactly the same list of roles but just points to the next Custom Field, e.g. If Custom Q contains "Account_Director" OR "Authorised_Engineer" OR .... [all roles]; then go for the task else No Match
  • And so on
• Then, the only thing you need to edit when things change is which Custom Field each role is listed in
• You can maintain these 'lists' externally and just paste your altered text into the "Update Custom Fields" node Manual entry-point

Another idea is making use of the RAW data from the user role selection to give a 'coded' answer if you have >15 but <36 "entities":

• Allocate a character to each "entity" thus:
  • Laptop = L
  • Tablet = T
  • Finance System = F
  • etc
  • [you can have 36: 0-9 and A-Z. Maybe more if it works with special characters...
• Then decide, for each role, which "entity" they are entitled to
  • Account Directors get Laptop, Tablet and Finance System
• Set the RAW value for the Role in the SimpleList used in the IC to have the 'codes' relevant to their entitlement such as:
  • Display: "Account Director"; Raw: "LTF"
• Then, your Expressions that trigger each of the tasks simply use the "contains" feature to detect if the 'code' is present
  • Decision 1: If IC_Answers>Role contains "L" then trigger the task to give a laptop else No Match and on to the next
  • Decision 2: If IC_Answers>Role contains "T" then trigger a tablet
  • etc
• This time, your only maintenance is in the 'codes' for each of the roles. And remember, you can still use the Display names in your workflows and comms

I'd be interested in your thoughts on these theoretical ideas (i.e. I have not used them, I'm just trying to problem-solve).

Berto 

[Guest Paul Alexander]

Cheers @Berto2002 - I haven't tried this option, but might have a go later today to see whether it helps or not. Obviously my main problem comes (with either method) when 'something' gets updated! 

What would be handy would be if, when I look at a list of Values in a decision node, I could sort them alphabetically (which would make comparing them to the excel list that I'm currently using) easier!