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> 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> on behalf of Jason Miller < > 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> > 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 > 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 > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
