Discussion
Multiple worktype in same class?
Hi,
Could we have multiple worktype in same class?
-Thanks
A work type and its class are synonymous.
You can extend a class using Dynamic Class Referencing (DCR) perhaps.
You can also circumstance the Case Type rule for a given work type class if all you want is a different way to orchestrate flows.
Thanks Pedel.
Requirement was every functionality is same but the end user wants to name the Work Object ID(i.e - pyWorkIDPrefix) based on the values chosen in form.
Eg: 'xx'- chosen in Dropdown 1 and 'yy' chosen in dropdown 2.
then Work Object ID need to be xx-yy-101.
Will it be possible with the circumstance? or can i use the decision table in Model when creating a new work.
This is not a scenario for Circumstancing/Specialization, so I would suggest not to go with this approach if getting different prefix is the only requirement here.
You can set the pyWorkIDPrefix property on work page based on your requirement (dropdown/decision table ...). There should not be any harm in generating different prefixes for same Case. Only thing you will have to make sure is that Work ID Prefix column in empty in Application's Case And Data tab for this case, otherwise that value takes precedence over pyWorkIDPrefix.
Let us know if you have any other questions.
As PEDEL mentioned, You can circumstance the Case Type rule for a given work type class if all you want is a different way to orchestrate flows. This is called "Case Type Specialization". Remember that you should choose this option only when you have a case type with different variations but not 2 different case types.
Example:
Request Case type: PC Service Request & Laptop service Request - These are 2 requests but a little variation in their process. You should use "Case Type Specialization". In this case it's 1 class :)
Order Case type & Activiation Case type are 2 different case types altogether, so you shouldn't use "Case Type Specialization". In this case, it's 2 classes.
Assuming we have two cases VV-XX-101 & YY-ZZ-101 in a P7 application.
Do you expect both of them belong to a single work class OR two different work classes ?
- Different classes >>> Leverage "Case Type Specialization" using one of the properties in your work class. Also case type specialization is based on only one property (in our case pyWorkIDPrefix) once used it cannot be leveraged again for any other requirements. Specialized cases represent a small variance in the functionality however you had mentioned that the functionality is identical. So leveraging "Case Type Specialization" here is not a good design but somehow achieving the requirement.
- Same class >>> Say A-B-Work-C but different prefixes based on user selection. I bet its a bad way to segregate cases even if you somehow manage to implement it. Does not confirm with any existing design patterns I am aware of; might lead to issues later in reporting and upgrades/updates. Every case that belongs to a work class should have the same prefix. This is decided at RULE-APPLICATION > 'Cases & data' Tab > Case types > Work ID prefix if you are in P7.