Thanks for the quick response, John. These look interesting, and may be able to do what we are looking for. Our Launcher completely hides the Requests table because the only thing it displays OOTB are the Kinetic Requests, which immediately close after generating the appropriate Incident or Work Info entry over in ITSM. They do not remain open, and they are not updated by the ITSM record that they originally generated. Rather than have to explain "there's nothing to see here... move along," we just hid the whole thing in our Launcher. Virtually all of the email notifications going out of the system are directly from Incident Management or Service Level Management anyway, so customers never see any reference to the Kinetic Request record that they actually employed to create those records in ITSM. We had to customize those notifications so that customers were always pointed back to the Kinetic Request Launcher (and never to mid-tier), where there are service items for reopening, closing, or updating an existing incident.
Since we never exposed the Requester Console in version 7 (in testing, the CAI plugin-driven interface wasn't even remotely as reliable at generating Incidents as Kinetic was), and we don't have SRM, there are no surrogate request records left open for the customer to view that get updated by changes to the Incident. It was actually a cleaner and much more reliable process, but it left us with no effective way to present the open ITSM records to the customer in the only interface they have access to - Kinetic Request. Re-customizing the Launcher to query for ITSM records for the logged-in user should provide the answer, and of course we can create different launchers for different purposes since we have departments that submit multiple requests and want to be able to see all of them at once - as customers. We look forward to seeing the documentation on how to do this, and to being able to extend additional functionality to our customers. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of John Sundberg Sent: Thursday, January 28, 2010 9:00 PM To: arslist@ARSLIST.ORG Subject: ADV Re: [ARSLIST] Displaying open requests for Customers and SRM Documentation ** I am sitting in Dallas Airport (DFW) waiting for a delayed plane. (Big weather here today - but good meetings none the less) Chris/gang, Kinetic Request can do what you are asking about. See example: http://img.skitch.com/20100129-fca5mkwenyed1rery2t8nrnttq.jpg Basically the "Catalog Page" which we call a "Launcher" is a collection of Remedy queries that get rendered through what we call a "partial". Or possibly multiple partials. A partial can actually have more than one source (Requests, Incidents, Changes, Purchase Orders, Complaints, etc...) A launcher can have 0 to many queries (from any Remedy source) to display what you want. The samples we ship with do not do this -- as we do not assume you own ITSM or anything on Remedy. (In fact - we have users that exclusively use Kinetic Request for their request management (meaning no Incidents or Changes etc.... created). ) Kinetic can actually be a fulfillment target itself. However - people do use Kinetic Request for front ending ITSM, CSS, Purchase Orders etc... To get it to work - is a matter of configuring the Launcher partials. (Basically - change the queries (or add additional) to point to the proper source form - with proper criteria - then modify the partial to display the columns and look/feel that you want.) Example of showing worklog from an incident in ITSM 7: http://img.skitch.com/20100129-dj6anufe1fu7wuud6kt1xx1jxy.jpg Generally I would shy away from discussing "incidents" and "incident numbers" with an end-user -- as all things should be Kinetic :) -- more realistically - I think you want to think of the "fulfillment" as blackbox and where and how something is fulfilled is not of concern to the requester. The thing a requester should think of is their "request" -- with it's ID (if relevant). Again - more realistically - people do actually have Incidents (without requests) -- and it would be of value to look at them. So - the capability is there. (I expect we have this written up in a how-to of some sort -- I will look it up and send directly) Have fun!!! and enjoy the Texas weather -- MN is -9 tonight. (That is not 9 degrees below freezing -- it is 41 degrees below freezing (as in the difference between 73 and 32 -- yet again 32 to -9)) -John _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
