locked
Change Request Notification and WorkFlow RRS feed

  • Question

  • Hi,

    Need a Suggestion, i am having very unusual request for a Change Request WorkFlow.

    If we open multiple Change Requests but the outage notification should be sent to whole company once containing the total downtime if required.

    or

    any other way to achieve this ?


    BR, Phaixan

    Tuesday, December 23, 2014 7:18 AM

All replies

  • Maybe it is because I haven't had my morning coffee yet, but I have a hard time understanding your question.

    http://codebeaver.blogspot.dk/

    Tuesday, December 23, 2014 7:59 AM
  • may be i had my coffee twice this morning, thats why i made it difficult :)

    actually i customer is having custom solution for change requests, but i have deployed service manager to change the existing system, now they need the same way of workflows and notifications as they are using it now.

    actually when you create one change request it triggers the notification, the other will generate another notification and so on. but they need if they have to make multiple change requests like one for server1 and other for server2 another for server3, but the notification email for the outage should be only ONE.

    how to make this possible? i hope youve got my point..


    BR, Phaixan

    Tuesday, December 23, 2014 8:22 AM
  • So in a nutshell you want a single notification for multiple change requests?

    Who should get the notification? When?

    How do you know they belong together?

    I would make a template based on the review activity class (or manual, doesn't matter much) and make it approve automatic (select from approval condition). The change manager or whoever should be responsible for this notification then adds the review activity to just one of these change requests, triggering just a single notification.

    Alternately create a service requests and add dependent activities (as many as there are change requests). These will complete when a specified manual activity in the change request completes, hence all activites must complete before the service request completes (triggering notification).

    My personal opinion is that they should change their process. If they want one notification for multiple changes those changes probably belong together.


    http://codebeaver.blogspot.dk/

    Tuesday, December 23, 2014 10:29 AM
  • Wonderful.. :)

    i have suggested the same but the ITIL expert here denies it :(

    notification should be sent company wide once approved.

    yes we cannot relate them to each other or we cannot come to know if the belonf together.

    what i have done is to create multiple CRs as per their requirement and create one parent CR where all other CRs will be added into the related work items. now i am trying to find the notification criteria where i can tell if all the child workitems are approved they an email notification should be generated. by this means all the CRs will be related to eachother. m i right ?

    what do you suggest ? will this work...


    BR, Phaixan

    Tuesday, December 23, 2014 11:07 AM
  • How often can the whole company be interested in a change request?

    I need to get the console in front of me before I could say whether that would work or not, but for the simplicity I would still recommend the solution already suggested:

    Alternately create a service requests and add dependent activities (as many as there are change requests). These will complete when a specified manual activity in the change request completes, hence all activites must complete before the service request completes (triggering notification).


    http://codebeaver.blogspot.dk/

    Tuesday, December 23, 2014 12:31 PM
  • i want to cut to the chase, procedure wise, and ask why they need separate change requests anyways?

    if there is one change to multiple systems, have the change record specify that it will affect multiple systems. they can leave their existing notification methods in place, since there will only ever be one notification becuase there is only ever one CR. 

    the problem here is that the ITIL expert is over-specifing what needs to be in a change request, rather then letting the definitions and procedures drive the process. if you CAN summarize the whole thing with one notification, it should be one change, even if that change has a million implementation steps or modifies a million systems, it's still one change BECAUSE you can describe it once. 

    on the other hand, if you to make two changes to different systems on the same server, then it should probably be two changes, even if it's in the same screen. two different audiences implies two different changes. 

    On the other hand, if they are doing a change window that has multiple changes inside of it, like monthly maintenance, then it really is a different thing, and they should consider creating a new type of work item for that new type of thing and setting up notification rules for it that can be special and separate. i have personally used Release Records to specify change windows like this, but it's kinda a hack, process wise. 


    Thursday, December 25, 2014 4:50 PM