Limit on amount of outcomes from a task?

[Guest Paul Alexander]

hello

Is there a limit on the amount of outcomes options coming from a human task?

We have a BPM which will ask the analyst to choose a person from a list of 14 options (this will be a human task where you select the size of a project and, in this case, I choose 'Small') but, whenever the BPM gets to this point (the Pick PM task in the pic) it fails. If I select a different outcome (for instance, from the attached pic, if I choose  a Project Size of 'medium', which will then branch off to a Human Task with only 2 outcomes) it works fine.

Any ideas please?

 

[Victor]

10 minutes ago, Paul Alexander said:

Is there a limit on the amount of outcomes options coming from a human task?

I can say for sure but I don't think there is a limit... PM the BP definition, I'll have a look...

[Victor]

@Paul Alexander maybe I was wrong... I have run various tests with different outcomes... All works fine as long as I have a max of 8 outcomes. As soon as I add the 9th, the error occurs... so possibly there is an internal restriction. I'll ask the dev team.

[Gerry]

@Paul Alexander

Having looked at this I wanted to give you an update.  So firstly, there is in fact a limit of 8 outcomes on tasks. Unfortunately the limit was not respected in the BPM designer, so while you can add more than 8 in the UI, the back end service will, as  you have seen, throw an error when you try to save.

I wanted to give you an alternative suggestion to the expansion of these.  Given your requirements, it seems to me that using outcomes to select people is the wrong way to go about it. What happens if you needed the list to be dynamic, what happens if you have 100 people to choose from, and what happens in the mobile app or the tasks UI.  I think 8 is a reasonable maximum limit on outcomes, so then we need to maintain this and solve the problem you are trying to address. 

In our long term thinking we have always had the notion of "addtional custom fields" that can be added to each outcome, such that when the user chooses the outcome, if addtional information is required they would be prompted before they can complete the task. This addtional information would be passed back into the BPM context which you could then operate on as required.  In your case, you would be able to create an outcome called "Assign" and add a custom field to provide a drop-down list of co-workers to select.  I believe this will be a far better and more flexible longer term solution for the Hornbill platform and would solve your specific need. 

Does that make sense?

Gerry