You can create multiple custom fields, one for each "State" grouping. We have a similar situation internally and the custom fields work well.
Different States for Different Case Types
For my purposes, issues and requests have different lifecycles and, therefore, need different values for states. I'd like to filter the values that appear in the state list. I suppose I could create a validation rule that prevents one from using the wrong value. However, I have a lot of distinct values that create noise when they're all lumped in together. Is there a way to do this?
Thanks in advance!
Please sign in to leave a comment.
That thought had crossed my mind, but I held back fearing unforeseen problems. So some follow up:
- Are the values entirely custom in the picklist too? (ie, there's no way to pull the existing values from the "real" state field is there? Bizarre thought, I guess, but...)
- How do you keep those straight, from a naming perspective? Did you specify type in the name, .like, "Issue State," "Request State"?
- Did you have to rework a bunch of reports as a result?
- Any unforeseen consequences I'd need to be mindful of?
1.) You can type any values you would like as picklist options, so they can be the same as the original State field. You can even write a rule that when you change your custom field it will update the main State field as well.
2.) You can already create custom fields specific to Issues, Bugs, Requests, and States. Let's say there were two different sets of Requests, you could name the custom fields "IT Request State," "Marketing Request State," "Feature Request State," etc...
3.) Yes, you will likely have to update your reports to reflect the proper state field unless you want to have all state options in the original "State" field and have the custom fields only contain a subset of those states.
4.) In your views, you will have to be aware of the state field you are using. This should be fine if the naming is unique and descriptive as mentioned in item #2.