Jason,
Great stuff. The license issues come in because you can have customers submit work log updates without a write license. I believe SRM is setup that way or at least us to be if I'm not mistaken, so this would make a filter update a problem. If I went the escalation route I would setup a qualification to say only update the last modified date if the work log submit date is newer than the incident last modified date. For now we don't have customers adding work log entries, but we may down the road. Not sure if we would at that time say date last updated by support versus date last updated by customer. The challenge with the SQL route is going across various environments when porting code over (dev, test, prod). The SQL code may or may not have to be redone. We have multiple environments and multiple networks utilizing remedy. I do like direct SQL because a lot of times it is much faster depending on what you are doing. I'm going to play around with a few of these in our dev environment and figure out which one works the best. Brian ________________________________ From: ARSList <arslist-boun...@arslist.org> on behalf of Jason Miller <jason.mil...@gmail.com> Sent: Tuesday, May 29, 2018 3:39:08 PM To: ARSList Subject: Re: Incident Last Updated What kind of licensing issues are you thinking of? I probably would not create workflow around forcing an updated. That is a procedural issue, not a system issue (a common desire is to manage people via tech). I haven't researched if this would have a negative affect in ITSM, but at my last job we built our own incident management and change management apps and I made sure to include a filter that would update the main ticket any time an associated work log records was created/updated so there wasn't a situation where the last modified date was older on the main ticket than a work log entry. These apps had the same basic structure as ITSM where there was a main record and related work log records (although audit and work log were all recorded in the same form so you could see the full life cycle of the ticket by looking at one table field / report). You want to consider this route if want simply look at the last modified date on the main record (assuming it wouldn't be updated by an escalation giving a false update). Another thought is to have a SQL job that updates your custom field for capturing last user modified date. It would be pretty quick performance wise and wouldn't touch the core last modified by and last modified date fields. By doing this then you can add the custom field to consoles like you mention and allow for sorting by this value. Or you could use a combination of this custom field that captures only user update times with workflow on the work log record as mentioned in the last paragraph, many options here. On Tue, May 29, 2018 at 1:57 PM, Brian Pancia <panc...@finityit.com<mailto:panc...@finityit.com>> wrote: Jason - Thanks I was looking at that as a potential option too. Of course the challenge with the work logs is licensing related issues. I definitely want to make sure I don't kill all the functionality designed around the work logs with workflow forcing updates. One thing I was looking at for the escalation route is so the users can see quickly the last time the ticket was updated, which can be used in the out of box consoles easily. I may be able to use a display only field for that and do a join for backend reporting though. Brian ________________________________ From: ARSList <arslist-boun...@arslist.org<mailto:arslist-boun...@arslist.org>> on behalf of Jason Miller <jason.mil...@gmail.com<mailto:jason.mil...@gmail.com>> Sent: Tuesday, May 29, 2018 1:55:52 PM To: ARSList Subject: Re: Incident Last Updated I have seen these type of reports written against a join of HPD:WorkLog and HPD:HelpDesk. This way you do not need to modify any data (and in-turn you don't update the last modified date) like you would with an escalation. Jason On Tue, May 29, 2018 at 11:52 AM, Brian Pancia <panc...@finityit.com<mailto:panc...@finityit.com>> wrote: I'm looking at including the last date a ticket was updated either directly or through a work log entry. My initial thought is to create an escalation that checks to see if the work log entry submit date is greater than the ticket last modified date and then update the ticket with that date and user in the last modified fields. The goal is to be able to easily report on how many days since the ticket was updated. I'm sure this has come up 1000 times. Has anyone come up with other cool alternative methods? Thanks, Brian DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. -- ARSList mailing list ARSList@arslist.org<mailto:ARSList@arslist.org> https://mailman.rrr.se/cgi/listinfo/arslist DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. -- ARSList mailing list ARSList@arslist.org<mailto:ARSList@arslist.org> https://mailman.rrr.se/cgi/listinfo/arslist DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately.
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
