Thanks for the $LASTCOUNT$ tip. I overlooked this handy keyword and may have been trying to reinvent the wheel by creating workflow to increase integer fields to just get what searches and lastcount should give me. I'll explore this in the morning. Though another part of this exercise I didn't mention, is to define the average time each ticket has been open per tech and status. I don't see how I'm going to get this info without a tableloop style arithmetic solution... without using flashboards. I still find it mystifying how escalations handle the creation of new records in mass... based on a "push fields if" qualification that was supposed to create a new record only if a duplicate was not found otherwise modify it. I may still need to find a solution for this using filter tableloops or move to direct sql in order to get avg time open/per status... but I digress.
In the end, I image you are correct that I'll be best off using direct SQL commands in order to minimize system impact. Btw... Thanks for the form idea to define escalation status via escalation qualification matching. That's a keeper! On Jun 30, 8:31 pm, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > Dear BrLloyd, > > I could be wrong, but it sounds like you have an escalation running > against your main ticket form that does a push action (from many > records in the ticket form) every hour. If that is the case, then it > is possible that it takes more than 1 hour to finish the first pass > through the many tickets. When that happens then you might end up with > multiple records created because the Push action is evaluated per > record and when the clock goes past 60 minutes, then a new record > would be created. (Even though the counting was not complete from the > first pass.) > > I could be wrong, but it sounds like you want a count of tickets by > assigned individual and a total count of open tickets per status. ( > But your post did not totally parse for me. So I may not yet > understand what results your after yet.) > > So you want numbers like: > > Status = "New" Count = 5 > Status = "Assigned" Count = 7 > Status = "WIP" Count = 7 > Status = "Fixed" Count = 9 > Status = "Closed" Count = 100 > > Total Tickets created this hour: 128 > > Does that sound about right? > > If so then I think I would take this approach..... > > 1) In your custom form... make a field for every count that you want to > collect. > > 2) Change your escalation to run against a much smaller form, and have > a qualification that would only match ONE record in that form. > I often use a "Configuration form" so that I can, with a data > change, prevent or enable and escalation by changing a status value on > a single data row in the config form. However, you can choose to do > that or not. > > 3) Have the escalation always push a new record into your custom form > to collect the stats. > The Push action could include a "Search condition" that the status > should use to make this more flexible. > It could also include the form name to search. (If you want to > get real fancy and try to make this form collect stats from multiple > forms. etc... Again.. you can choose to do that or not.) > > 4) Have filters on submit that either do a set field action that > "return first matching" and set $ LASTCOUNT $ to one of your stats > fields. ( Use the qualification based on time[ supplied from the > escalation ] in combination with each status value to get the > individual counts. Yes that means one search per status value that you > want stats for. ) > > 5) Get the total count of all tickets too. > > You may found that ARS workflow is "to slow" for this kind of > counting. ( And if you want things like a count by each 'Assigned to' > person in that hour, then you likely will have a much harder time > trying to use ARS workflow to even build that list of distinct > 'Assigned to' persons in an hour too.) So you may also want to look at > using direct SQL to get the counts. You may even want to go so far as > to use direct SQL to get all of the values and stuff them into a table > that you construct so that you can point an ARS View form at the RDBMS > table. ( You need a Field 1 value, 15 char or integer that is a unique > key for the table, so that ARS can use the table as an ARS form.) > > I am sure I skipped over those two very distinct ideas very quickly, > and I am still not sure I fully understand the question. However, feel > free to clarify what your after and I am sure someone on the list will > have a few ideas for you. :) > > Oh yea.. and you might also consider Flashboards for this kind of > functionality too. :) > > HTH. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > > On Mon, Jun 30, 2008 at 7:44 PM, BrLloyd <[EMAIL PROTECTED]> wrote: > > Hey group. This my first question to the group and involves populating > > a custom form with the total count of open tickets per status. > > > I'm using an escalation with a push field action to set a tmp integer > > field with a value of 1 on a custom form. The Escalation has a create > > record condition; when a record doesn't exist with a matching assigned > > individual and the record's create date isn't within the last hour. > > (The most frequent that the Escalation would run.) A filter completes > > the desired outcome and is set to run on submit/modify on the custom > > form. It's has a set fields action which adds the ticket count integer > > field and tmp integer field (+1) together and then nulls out the tmp > > field. (Which may be redundant.) > > > The resulting records are not as I expect. The escalation seems to > > both create one new record for each match and update the ones it just > > created in the same execution. If it did one other the other > > consistently I would be able to keep track of what is happening but as > > it stands I'm finding this a bit unpredictable. > > > Can anyone explain this behavior? Also I would be open to other > > approaches to the generate the same report but the goal is to generate > > this without any user interaction and email it. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > Platinum Sponsor:www.rmsportal.comARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
