We do the same thing here with all our custom applications (15), when the submitter updates thier request (Either via email of via the Customer Portal (web), we notify the assigned the individual, if there is no individual we then update the group, based on their group preferences (Manager, all members, etc.) In addition we create an “Audit record”, and then close the loop by notifying the submitter, that their update has been posted and the responsible support resource has been notified. (Best practice)
(In most of our applications, we even allow the submitter to request “Contact” making a contact phone number mandatory.) Doug From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Wallace, Kelvin Sent: Saturday, December 01, 2012 5:19 PM To: arslist@ARSLIST.ORG Subject: Re: OFFLIST - Incident Submitter and License terms - Dear BMC have you mislead us? ** We run a customized Incident app here and we allow anyone to modify – but when they do, it triggers a notification (to the assigned tech) of the changes. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG]<mailto:[mailto:arslist@ARSLIST.ORG]> On Behalf Of Jason Sent: Friday, November 30, 2012 4:57 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: OFFLIST - Incident Submitter and License terms - Dear BMC have you mislead us? ** I'm actually all for not allowing submitters/end users to modify their incidents. Support techs don't re-read tickets. If somebody gets assigned an incident, reads it, then somebody modifies that ticket, how is the assignee supposed to know what was changed? At least forcing them to add work info updates adds a time stamp to their update. Something an assignee could see and know what information is new. And yes, somebody will point out auditing. But that means the tech has to know something was changed, open the audit log, look at the new entries, and then look at previous entries to determine what the previous value was. And if you create a notification to the assignee? Well, that's just one more thing for their auto-delete rule. Bottom line... The locked submitter mode is part of the Action Request System functionality. The ITSM apps are a different product and can't assume everything carries over. Exhibit B: 7.6.04 User Tool. Been one of those days. Jason ________________________________ From: Timothy Powell <timothy.pow...@pbs-consulting.com<mailto:timothy.pow...@pbs-consulting.com>> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Sent: Friday, November 30, 2012 2:39 PM Subject: Re: OFFLIST - Incident Submitter and License terms - Dear BMC have you mislead us? ** And I will venture on to say that I understand that there are some application Role dynamics in play here. Not allowing a DIFFERENT user to make mods to a ticket that’s not theirs or where they are not a member of the assignee/owner group is completely understandable. But I am still confused on the business logic behind not allowing a user to update their own ticket beyond work info entries (which of course is really a separate submit). tp From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: Friday, November 30, 2012 12:07 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Incident Submitter and License terms - Dear BMC have you mislead us? ** I did a search of this year’s listings before I asked this question, so I apologize if I missed a thread and am dragging up an old subject. I did see some similar discussions, but nothing specific to this. BMC/Remedy has always promoted the fact that if the server was set to Submitter Mode-Locked (SML) that any user could submit and modify their own records (where $USER$ = Submitter Field ID 2). In ITSM 7.6.04, that level of permission equates to Incident Submitter. So I have a user that is set up as Incident Submitter with a Read license attached to that role and a Read AR license. The user can submit tickets BUT cannot modify their own incident tickets (where $USER$ = Submitter Field ID 2). There is actually workflow in place to prevent this. In order for them to modify their own record, I have to bump that user up to Incident User level, which then requires a Fixed or Floating license. So my question is: Is that not in conflict with one of the major sales arguments BMC made to our organizations, that being our users could submit and modify their own records without a Fixed or Floating license? Tim Powell _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ This email is subject to certain disclaimers, which may be reviewed via the following link. http://compass-usa.com/Pages/Disclaimer.aspx _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
