I'm interested in how others might be handling Service Requests as Tasks.
As we're building out our Service Catalog we're increasingly coming up on Service Requests that have a number of Tasks that are required to process that request. Many of those Tasks are already stand alone Service Requests. For reporting, and workflow continuity, we'd obviously prefer that defined Service Requests always show up as such to the Team/User that they're assigned to, instead of being a Service Request sometimes, and a Task others. Then again, we like the OTB functionality of Tasks within the context of complex Service Requests.
I've seen some suggestions on the forum here about building out something special for the really complicated service requests like employee onboarding, but we'd like, as much as possible, to have a standard way of dealing with this because it's clearly going to be common to have Service Requests that have one or two tasks that are already a Service Request and we don't want to have to handle each one in some special way.
Fishing for ideas and feedback about how others have handled this.
Depends on have you categorized the tasks, if you did, you can create one step mapping Service Requests fields pick up Task value given there already have a relationship. If they didn't categorized, you can set the categories as generic one pick up Task Title as Request Title, Task description as Request Description, still run the one step to create new Service Request and read value from Tasks.
Well, since we are just spit balling it here, how about spinning up a service cart and linking all of the new service requests to it? That way you have the service requests instead of tasks to keep the SLAs, work visibility, etc. and you have a management container that automatically tracks completion and has notification mechanisms you can leverage when the set is finished. Really a low effort level way to bundle service requests with light management.
ScottExcalibur Data Systems
We've elevated Task and added the ability to link to the same specifics object that the service request uses, so we've thought about porting the data from one to the other as needed
I think this will definitely be part of our overall practice, especially with very complex service requests such as onboarding. For simpler Service Requests our inclination at this point is to create these tasks as service requests when there aren't any down-stream dependencies and tasks when there are
We decided to use separate service requests in this scenario for reporting consistency and to use the specifics forms we'd established. We wanted to avoid extremely large forms that we would have in some cases if we combined all the components needed into one request with tasks. For a few service classifications, we added buttons (that execute one steps) on the specifics form that generate another service request and copy relevant values over. (For example, when requesting a new server, there's a button to request the appropriate DNS service if necessary).
We are in the early stages of designing our Customer Portal and implementing an On-boarding process so I don't have any feedback yet on how this design decision may impact those components/processes.