The CAI Plug-in creates the Incidents from the Requests in the Requester Console as the Remedy Application Service. In a similar fashion, if you use Kinetic Request the Submitter will be KD_WEBUSER unless you do something to change that value before Submit.
I know I had to add workflow to set Submitter = Requester in ITSM 7, just like I did in previous Help Desk versions, but I also always exposed or added an "Original Submitter" field so that I could record who created the record even after the Submitter = Requester code had run. This retained information about who submitted the ticket _and_ allowed customers with Read licenses to edit their cases in Help Desk, which ITSM 7 isn't really designed to do directly. If I create an Incident in ITSM 7.0 (or a 7.5 system upgraded from the customized 7.0) as a support staffer, the support staff ID goes into Original Submitter and the customer ID goes into Submitter. We built it this way when we were first customizing Incident 7.0 after seeing that the OOTB notifications send customers a link directly to the Incident, which they can't see without Incident Viewer or edit without being the Submitter on a Submitter Locked system, so we kept the customizations. Later we found more problems with the design (rights to the incident did not allow a customer to add a Work Info entry) so we disabled the OOTB customer notifications entirely. I think it was just one more inconsistency (of many) in the design of ITSM 7.0 which was leading towards moving customer access to SRM before that product was even designed. If you route all customer access through the Requester Console, or a portal app like SRM or Kinetic Request, and do not give the customers ANY access at all to ITSM, technically it should not matter what value is in the Submitter field, or even if your AR Server is Submitter Locked (someone from BMC can correct me if I am wrong). In our case, the support staff are used to using and interpreting the values in Submitter and Original Submitter a certain way, and have many reports built on those values, so we continued to use them the way we did in Help Desk 5.5 and earlier. You can customize your system too if you have good reason, but ITSM 7.0 and 7.5 seem to have made Submitter less important to the overall function of the application; the trick is to avoid any code that tries to CHANGE the value of the Submitter on a Submitter Locked system; ITSM 7.5 failed that test right out of the starting gate (see Active Link HPD:HPS:OnSubmit_004 which will prevent saving changes to the Incident Management Settings in configuration). 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 Tim Rondeau Sent: Tuesday, August 11, 2009 10:13 AM To: arslist@ARSLIST.ORG Subject: Remedy Application Service ** Hi, Arsystem 7.0.1 patch 2 ITSM suite We are looking to make sure requests from the Requestor Console come in from the user and not from the Remedy Application Service user. This functionality on the Changes comes in from the actual user when submitting via the requestor console. The Incidents however come from the Remedy Application Service as the submitter. Before I put changes into the workflow, I am wondering if there is some setting I am missing? Thanks Tim _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
