Hi Laurie, Just realised you replied to this some time ago. Sorry I didn't get back to you sooner. At least now i can tell you how things have gone in production.
I have settled on a similar solution to the one that you have suggested. I now have an escalation that keeps the number of open tickets per support staff member up to date. It uses filter guides and is always accurate and is self correcting. For a while we had the escalation running infrequently as I was using the logic that increments and decrements the ticket count to trigger recalculation. In the end though it seems there is at least one flaw in the ticket count logic that I haven't found so it was easier to just run the escalation more frequently. We've been live for a few weeks now. With the exception of the issue where the open tickets weren't all being kept up to date I've had no technical issues. Until I hear otherwise I'm assuming that the enhancement is meeting the business needs also. Thanks for your help Laurie, Rod 2009/5/6 Muhlethaler, Laurie <[email protected]> > Hi Rod ~ First let me say that there are two known issues related to > this open for BMC to fix: > > > > SW00269521 > > People "Open Tickets" count not updating correctly > > > > SW00275463 > > Only < "Resolved" s/b included in Open Ticket count > > > > That aside, I had to address several aspects for this to work: > > > > · Set minimum attribute on Number Ticket Assigned field to “0” so > the number wouldn’t be negative > > · Created a temporary escalation to fix the Number Ticket Assigned > count in the CTM:People form > > · Modified existing workflow to ensure that reassigned and closed > tickets were being updated appropriately > > o Disabled filter, HPD:INC:UpdateAssignmentTicketCount_ReAssign_010, > and duplicated with the following modified Run If: (( 'Assignee Login ID' > != 'DB.Assignee Login ID') OR ( 'Assignee' != 'DB.Assignee')) AND ( > 'DB.Status' < "Resolved") > > o Disabled filter, HPD:INC:UpdateAssignmentTicketCount_ReAssign_011, > and duplicated with the following modified Run If: ( 'z1D_Previous Assignee > Login ID' != $NULL$ ) AND ( 'DB.Status' < "Resolved") AND (( 'Assignee > Login ID' != 'DB.Assignee Login ID') OR ( 'Assignee' != 'DB.Assignee')) > > o Disabled filter, > HPD:INC:UpdateAssignmentTicketCount_TicketClosed_013, and duplicated with > the Run If modified to query “Resolved” rather than “Closed” status > incidents. Didn’t make sense that only those tickets moved to “Closed” > status would decrement the query. > > · Created new filter to ensure reopened incidents increment Number > Ticket Assigned appropriately (this was a byproduct of modifying the > HPD:INC:UpdateAssignmentTicketCount_TicketClosed_013 filter) > > > > I tested in lab and found that the number was still getting skewed somehow > and since I wasn’t entirely sure how it was happening, I left the escalation > on and I currently have it running every several hours to fix the count, > since it doesn’t appear to be a rampant problem (still scratching my head > over this). I hate going the escalation-fix route but my users were > definitely chomping at the bit for the auto-assignment so I’ve bit the > bullet for now and will revisit at some point. > > > > I also created custom assignment rules but it looks like you probably already > have that under control. If not, refer to the March 2009 ARSLIST thread, > *ITSM individual assignment process by assigned group rather than by > company*. Big “THANK YOU” to Doug Blair for his help on the auto-assignment > part – I’m not sure I thanked you previously! > > > > I hope this helps you, Rod! > > > > > > *From:* Rod Harris [mailto:[email protected]] > *Sent:* Tuesday, May 05, 2009 1:51 AM > *To:* [email protected] > *Cc:* Muhlethaler, Laurie > *Subject:* Re: Open Ticket Counts > > > > Hi Laurie, > > > > How did you get on with this? > > > > I too have got the same (or similar) issue. I'd like to implement a slight > variation on auto assignment by capacity and I likewise need the open > tickets count to work as it should. Right now many people have thousands of > tickets supposedly opened though this is definitely not right. > > > > I suspect that the filter HPD:INC:AR_002_ESCALATOR_AutoCloseGotoEnd is the > culprit. It basically skips all the filters when a ticket is auto closed. > The other thing that fails as a result of this filter is that the matching > request is not closed at the same time as an incident. If he incident is > later modified for some other completely unrelated reason then the matching > service request is mysteriously suddenly closed. This would also send a > closure email to the client, perhaps many months after the ticket has been > automatically closed. I'm planning on shifting this skip filter down the > execution order a little so that at least the request is closed and the > count is decremented as it should. > > > > I have patch 9 of ITSM 7.03 installed on a patch 6 7.1 server. > > > > If you are interested I'm trying to implement assignment via capacity such > that if there is no capacity available, auto assignment is deferred until > capacity is freed. OOTB I assume that it still allocates over and above > capacity if nobody has any left though this might be compromised by the > totally incorrect open ticket counts that we have. > > > > Rod > > > > 2009/3/7 Muhlethaler, Laurie <[email protected]> > > ** > > Listers ~ it appears as though the Open Tickets count in users’ PPL > profiles is grossly inflated. I’ve verified that it’s incrementing and > decrementing as designed but somewhere along the line it either wasn’t > decrementing properly or the incrementing went haywire (real technical, I > know). At any rate, I just thought I’d throw this out there and see if > anyone else has stumbled across this. I’m trying to implement > auto-assignment based on Number and obviously I can’t do that until I’ve > figured out this issue. Also, can someone tell me why the OOTB Incident > functionality only decrements the Open Tickets count when a ticket is closed > and not resolved (HPD:INC:UpdateAssignmentTicketCount_TicketClosed_013 > filter)? Doesn’t really make sense to me… > > Thank you in advance. > > > > Windows Server 2003 > > SQL Server 2005 > > * * > > *7.1.00 Patch 002* > > AR Server > > MidTier > > Admin > > Client > > Approval Server > > > > *7.0.03 Patch 006* > > Service Desk > > Asset Management > > > > Assignment Engine - 7.1.00 > > SLM - 7.1.00 Patch 001 > > CMDB - 2.1.00 Patch 002 > [image: [First Republic Bank logo]] > ------------------------------ > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. This message cannot be guaranteed to be secure or error-free. > > First Republic Bank and its related entities do not take responsibility > for, or accept time-sensitive instructions sent by email including orders, > funds transfer instructions or stop payments on checks. All instructions of > this nature must be handled by direct communication, not email. > > We reserve the right to monitor and review the content of all email > communications sent or received. Emails sent to or from this address may be > stored in accordance with regulatory requirements. > > First Republic Bank is a Division of Merrill Lynch Bank & Trust Co., FSB > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers > Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
