1 Reply Latest reply on Feb 18, 2013 8:49 AM by Carl.Simpson

    Service Lifecycle Process as suggested in 7.5 design ideas guide

    johnoxley Apprentice

      There are some suggestion in the design ideas guide on how to set up a service lifecycle process. However, it does not suggest which core object to set it up in. There is no core object in Asset wher the services are stored so I am assuming that the service lifecycle would be on the change core object. Anyone got any other ideas?

        • 1. Re: Service Lifecycle Process as suggested in 7.5 design ideas guide

          We do not use the full lifecycle but from what I know (which isn't that much) each area is it's own thing.  Change, Incident, Problem, Request, etc are all self contained.  However, they can also work together as you need.  We currently use just Change and Incident.  We use them independently except for 1 situation where an Incident gets transformed into a Change.  CI's, analyst, end users are all universal.  I would think it really depends on your situation as to what you really need.  We don't use Problem because the developers have a specific application for that that and they like it a lot.  If you need a formal process for that type of work then it would seem that you use it as you best see fit.


          Within process by selecting an action, an incident can create a change, problem, request, etc.  In that respect, I think you will find that they are each self standing but link to each other.  I found out that many actions need to be available on the Open element or you can't link the different types of data.


          Maybe someone else has a lot more experience with all but this might at least get you going.  We started with Incident first and then added Change on soon after.  My guess is that the same would be true with all other modules.