On the operator Work tab there is an option to specify a substitute operator or workbasket.
Our requirement adds an extra level of complexity in that we want the routing rule to depend on the case type. So while the above screen allows a decision tree to be created, the context of the decision tree is Data-Admin-Operator-ID while the work objects which are routed are generally Company-App-Work-CaseType. So if we want the decision tree to route based on .pyLabel inside each case, how would we define this rule?
On a further note: this functionality will end up being used by end users - ordinary employees in our customer's organization with approval tasks. Decision trees are slightly complex to explain to the less IT literate staff so we may have to create a registration screen to simplify the process if and when we can solve the above problem.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
In theory, creating a registration screen and generating the decision tree from that by replacing values in a predefined template is possible but the problem is our use case is more complex than that above: the number of branches in the decision tree depends on the number of roles the user has in the company multiplied by the number of application form types. We could create a template for each permutation of 'roles x form types' but that would quickly become unwieldy: ideally we would want to outright generate the XML from the user screen. Any pointers as to how this can be feasibly built would be appreciated.
As our registration screen is completely custom we could structure it to be easy for the customer to understand and create an activity to do the necessary conversions to populate the data page; the customer never has to touch the decision tree.