Boden ✭✭✭

I agree that there would be some details to work out to make this work effectively, but we run into this all the time. At least with Change records we can restart a process. I would also like to see the ability to capture some input upon task completion. Long run the ability to branch based on task input, short term just…

This is what we do. For example we have a category that's only visible to IT, and another that's only visible to HR. It's more roles to maintain but it works.

This is a good idea. We sort of work around it by prefixing all tasks name with the type of request, e.g. Onboarding - Create Account X, Onboarding - Create Account Y. Then we customize our task view to see more of the originating ticket info.

I really like this idea but specifically how it's implemented would be crucial. For instance, only some percentage of incidents relate to the computer that the incident was reported from. So from a UI perspective perhaps the ability for the user to indicate that the incidents is related to "this machine," and/or from the…

Hi! We're interested in the Intune integration, but I don't have a clear picture of the intent. It's mentioned that this can be used "instead of installing an additional discovery agent," but it seems like the information pulled is less rich than what we get with the agent. Is it intended to enrich, or for those who maybe…

Problem records need some serious love. As it stands, they only work for tying incidents together.

Just ran into this today. We have standardized SLAs per priority EXCEPT for one specific type of incident. In order to make the system work for us, we would have to create the same service level rule for every single category, and a different one for the exception category. At least that's how I'm interpreting the system.

Here's another fun aspect of this problem, I believe: when a user approves or denies a request, do you know where that comment goes? It might as well go into a black hole. We've had situations where somebody gives conditional approval, like "ok but only for 1 month," and we miss it. This of course indicates a process…

I'll pile onto some of the negative comments here, but want to be constructive. I've been critical of this product for a long time, to the point of nearly moving away, but it does do enough things nearly right that it's hard to justify making a change at this point. I don't blame the developers: in fact I was able to meet…

Ours doesn't look too different from yours, and I like the way you frame category as "what you want to achieve!" This may be blasphemy, but I'm going to offer that using categories and custom fields to capture information that may be useful in the future is a fool's errand. It will be exceedingly rare that highly specific…

Sorry, but nope. Lots of ways to get almost there, but nothing that crosses the finish line. Not sure if anything substantial is coming to resolve this any time soon. I just realized that it's been over a year since this was posted - I thought it was like six months ago. Guess my advice is to not hold your breath and…

I've run into this as well, and I believe the short answer is that you can't do what you're wanting. We expose the Due Date field on Incidents/Service requests to our customers and manually measure against due date and SLA. Meaning that we march to the customer supplied due date, and if one is not supplied we measure by…

Yeah for the most part we like how Changes are implemented, especially being able to restart a process. Don't want to clutter up our CM process with service requests though. Trust me, if I do happen to figure something out I'll let the whole world know :) Been noodling around on this for wayyyy too long. I do think…

Yeah, unfortunately that doesn't work because you need to know the variable inputs for the second service request in advance, because once it's created those variables can't be updated. What we need is a mechanism to capture variable input in multiple stages during a request, or a way to provide an actual functional link…

Thanks for the input - this is the direction we're moving in. It doesn't quite solve the problem because there is no linkage between the two requests, and they both need to be delivered in our case at the same time. I believe this will introduce an incident management challenge but be better nevertheless.

I met with Kfir after my original post and we went over this topic and other issues. If I understood correctly, they are working (or planning on working) on at least one piece of functionality that could alleviate some of this problem. I don't see anything on the roadmap that is specifically related, but perhaps some…

Yeah, I think I tried that and if I remember correctly, the problem will be that the manager won't have access to the ticket itself, and tasks can't have dynamic titles. Thus the manager will get a random task to "Put in Service Request for New Laptop" without any context. Would love to find out that I'm wrong about that…

Actually, it *almost* solves one of my biggest issues. This requires having all of the necessary information in the originating request to pass to the downstream requests. Definitely handy for breaking up certain catalog items, but not if more information is required by the downstream requests.

This is great!! Might solve one of my biggest issues with the system. Looking forward to this becoming easier to implement.

Yes, that would be great. I believe that we aren't using the system as effectively as we could, but also that there are some feature gaps that are difficult to work around. Please let me know how we should get in touch.

It seems like you are or may be asking about several different things things here: Internal IT procedures: Solutions may work really well because they're very quick to create and edit. Unless there are compliance reasons to have robust revision control and approval workflows for IT procedures, flexibility is what you'll…

I was recently struggling with this issue. Our use case is: * We measure Low/Med Incident resolution based on Due Date if it is supplied by the customer, or SLA if no date is provided. * All Service Requests are measured by Due Date as supplied by the customer. Thus, in order to review daily numbers, the team must look at…