Workflow and ServiceDesk Community

Dear All,

We have three Service Desk 7.5 groups - Frontline, Level 2 and Level 3 and we get lots of trouble where Frontline users keep assigning Incidents to Level 3 and so Level 3 get swamped with Incidents, so we have worked out that we need to restrict groups such that:

Frontline can only assign to Level 2 or themselves.

Level 2 can only assign to Themselves or Level 3.

Level 3 can assign as they want.

I have tried opening up the SD.IncidentManagmentSimple (where the Reassign form is), but it is REALLY locked down.

Does anyone know how to do this or is this possible at all?

Regards,

QuietLeni

Really, the best way would be to modify the incident management workflow. And by "best", I mean that it'd be the cleanest solution. However, I can think of a couple silly work arounds. They should work, but it isn't pretty.

1. Setup a workflow based on the "Send Incident to Workflow" template that stores in a DB table a running list of where this ticket is and has been assigned.
2. When a ticket gets assigned, it goes to this workflow.
3. In the workflow, it checks to see if the assignment is valid. If so, it goes through just fine. If not, it kicks it back to the queue it came from (based on that DB table).

Option 2 would be more or less the same thing, but instead of a table keeping track, you would just have the workflow look to see who did the reassignment and based on their group/queue memberships, would evaluate if it was acceptible or not.

But really, hacking up the IM workflow would be easier, though not supported and you'd have to re-implement it on every upgrade. You could just change what queues show up in the drop down list based on the logged in user.

michael.george,

Thanks for the response. I agree with not editing the regular workflows - the less that needs to be fixed on an upgrade is always the best!

However, when looking at the "SendIncidentToWorkflow" template, I see that the Incident object (below) does not include the assigning user in there. If the Assigning User was available, then I would have thought of this. I thought that the logged in user would be the user that the Workflow runs as?!

Thoughts?

QuietLeni

Good point. Off the top of my head, I'm wondering about using the process history to figure out who did it. When a task is reassigned (in IM at least) a note gets added to the history. This is a "ProcessMessage" type comment and is left by the user who did the reassignment. You could pull out the process history and order it by date so the newest message is first (or however you want to make sure the right data is grabbed) and find the name that way.

Michael,

Hmmm. The next hurdle is that I am looking at the [ReportProcessHistory] table and I see that when I Reassign the Queue for the Ticket through the Reassign Task/Action UI, it shows up with a ComponentExecutedMessage of "Work or Resolve Task Reassigned", but when I edit the Incident itself, then that shows up as "Ticket Data Updated". The Process message seems to be different as well in the Incident.

I wonder if I am looking in the wrong place?!

I think I had envisioned the "ReportProcessStatusHistory" table. Reassignments seem to have a status message of "Status Changed to: <b>Assigned</b> from: <b>Assigned<b>." and the username seems accurate.