Customize Change Status Task
I have a business requirement that I need some advice on.
We have an issue where analysts resolve Work Items that they are not part of the support group. This causes an issue with reporting that needs to be fixed.
We are using the Assign to Analyst by Group Task with the custom code to clear the assigned user. This works great and has removed most of the issues.
What I have seen analysts do is take a call from a user, use the assign to me task and then resolve without changing the support group. I can not hide the Assign To Me task as this is used a lot.
What I was thinking of doing is to add more fields in the Change status Task. The idea is to add a Support Group and Assigned To field that populates with the same fields as what it is within the Work Item. This will allow the Analyst to check that values to ensure that it is assigned properly. As an added bonus I was thinking of adding the Classification/Area in there as well so that it can be classified correctly on resolving the Work Item.
I know that this should not be an issue if everyone follows procedures but as we know in real life it is difficult to enforce.
I was also thinking of creating a Workflow that checks the assigned to and resolved by user and change accordingly but there will be an issue with selecting the correct support group.
I know this is possible by creating a custom task and I have looked at the code but programming is not my strong point and got lost in the first couple of lines... :-)
If there is anyone that has had a similar situation or requirement, any help will be highly appreciated.
Regards
G
Answers
Getting the right support group assigned to the final state of the IR is vital in allowing you to use that field in reporting.
This is a common issue and I am sure there are community members out there that have come up with a solution for this in the past so I encourage people to share their solutions to this issue.
If I was going to solve this issue I'd solve it one of two ways:
- If my analysts were only ever a member of 1 support group, I'd create a workflow that applies a template that re-assigns the support group when set to user X, Y or Z. etc.
- If my analysts were a member of one OR MORE support groups, this would get a bit harder.
Custom code is a skill that if you are lucky enough to have makes life a lot easier. However, if you are like me and have zero to no Java Script skills, then the Cireson Consulting Services team can assist you.OR
Add some custom code to the Assign To Me task or on a manual re-assignment within the portal so it jumps directly to the right support group.
Some solutions could be:
a) Blank out the Support Group every time the user is re-assigned, therefore forcing the analyst to re-select a new support group.
b) Add the support group as a required field to the Assign to Me and\or Resolve tasks.
c) Remove the Assign to Me task and Disable the Assign to and Support fields in a Work Item and force everyone to use the Group Assign task.
As for your comment on also adding the classification\area to the resolve task, my opinion is don't do this. The classification of a work item should be VERY generic. The list should be very small.
Maybe even as simple as:
- Hardware fault
- Software fault
- Network fault
- User issue
- 3rd Party issue
No more.Why? because as soon as you get any larger, analysts can't be bothered working out the best classification and usually select either the top most value, a generic value or worse, OTHER! (Ewww)
Try enforcing Configuration Items to be related to all work items and the resolution category to be changed from the out of the box values to things like:
- Warranty
- Bug\Fault
- Configuration
- Malicious Damage
With these three pieces of information (Classification, CI and Resolution) your reporting will be a lot more accurate and easier for analysts to enter.I will be writing a blog soon on how less data can be more useful to explain this in more detail, as this post has already gotten much longer than I expected.
Let me know if you would like more detail on these approaches.
Brett