We are running HEAT 2015.2 and created a new object in our system to handle these requests. Same challenge you mentioned, keeping separate from client Incidents (and related metrics) and allowing us to manage this body of work independently. Then we have notifications to the requester and owner based on request type, priority and status. We are not currently using the Change Management module, so I am not sure if this would meet the mark for you, but we are finding it valuable to track requests, route to assignees and provide visibility.
It sounds like you just need to create a relationship between Change and Service Request. After you create the relationship, you'll want to update the layouts for Service Request and Change so you can view and access the associated records. If you build a Service Request quickcation to create and insert a child record, that should meet your requirements. The Requestor of the Change could be set to the customer's name, and then your currently configured notifications for Change records should notify him/her accordingly.
1 of 1 people found this helpful
I'd probably create a new status for service requests called something like 'In development' - this can then be ignored on your escalations.
Then as described above you need a relationship from ServiceReq to Change (probably many to many or one to many).
As part of the request offering workflow you could add an Insert Child Object block using this new relationship and setup whatever change parameters are needed.
As the change status is updated you will then want it to update the servicereq status so your self service users can tell where it's upto - you may need another relationship on the change side back to service request but i'm not sure without testing?
Create a serviceReq quick action which will be used to update the status to 'In Development' and then add a trigger in the change business rules to react to a change of change status and run for child the new quick action.
May be easier ways but its an idea
The good news is that you can do this in the box
There's already a relationship between Service Request and Change (2015.2 onward anyway).
I suggest you create a new offering to capture the basic info you'd need to make the requested change in the SR Parameters and configure the workflow to insert a child object and complete the necessary info the get the change logged from there. Using the SR fields and SRO parameters you can populate fields on the Change. Then add a "Wait for child" block before before completing to let the client know their request is done.
If you need any help, let me know.