CA Service Management

I'm developing a series or request workflows in service desk and beginning to find a pattern where i'm continually creating new status types when inserting a new area.  For instance the last request workflow had about a dozen custom stages that might occur through the workflow and I'm wondering if I'm approaching this appropriately. Multiply all of these custom statuses across roughly 20 or 30 request applications we are porting into SDM and you can see where I am going with this. The problem is many of these request processes are very much a snowflake unto themselves and I'm concerned that if I try to re-purpose some of the status types to any other request workflow we may run into problems where the status triggers off a custom PAM process specific to how that area operates. 

So do I …

continue spinning up new sets of custom statuses for my work area's depending on need?

or

re-purpose ticket statuses as much as possible?

or

Some third avenue that I have yet to discover?

Any insight or guidance is greatly appreciated. 

Without knowing more details but having spun up PAM to hand off multiple changes and requests; I would say to try to re-purpose as many ticket status as possible and then use PAM to read values from the category / ticket and any interactive tasks from the contacts to move through the workflow. 

The idea being that you then don't need more custom status for each category but progress the workflow and update the stakeholders using custom 'in progress' notifications.

J.W.

Thank you J_W. If I'm reading this correctly you would have all areas inherent one stub workflow.

Are you suggesting depending on the area/category or whatever observations on the ticket, in PAM we keep PAM active on the request while the request is open regardless of its state?

So far I've done a few different request systems all of which are quite different.The first one we had a very large workflow that had multiple swim lanes and several IRF's. 

A few problems I've identified with this:

• First is that we have users in Service Desk that are very comfortable with SD and are not so comfortable with PAM's interface and way of doing things. They weren't too excited to see yet another interface they had to work with and preffered to see one console to manage their tickets.
• Second is that this introduces two asynchronous processes working the same ticket record. This creates all sorts of confusion as to how to interact with the workflow. Users will be presented with IRF's to interact with the request ticket but also they can interact with the ticket via service desk. Problems occur when these two systems come out of sync with each other and a tug of war ensues. 

To combat this I went with a more short winded approach with PAM where I spin up a PAM process that is only a few steps long and performs more specific tasks and then closes itself out. 

For instance:

1. A request is submitted to a department
2. PAM starts up for that request area.
3. PAM relays the request back to the submitter's supervisor for approval before commiting it back to the intended department. This is Handled via an IRF.
4. The submitter's super approves the request.
5. The status is updated and the team is notified.
6. PAM closes out and SDM handles the rest of fullfillment.

Based on what you are describing are you suggesting that I poll the request to check it's state and then react appropriately?

I've done this before but I'm seeing that this introduces load issues when compounded it against several thousand requests. 

Looking at the long perspective, we have many many many request systems in various platforms that will be ported into Service Desk and I'm feeling my way through to a plan of implementation for all of these. As I become more familiar with the product I've become more confident in our direction and decidedly faster at implementation but it's these little gremlins in the design path that if I don't get a good hold of soon I feel as if they'll come back and do a real number on us. I'm hoping that the more experienced users might have some insight on the bigger picture and how to handle hundreds or thousands of different request processes, each of which having their own little neuances. 

Many Thanks