The Company + Corporate ID makes a lot of sense IF and ONLY IF its use is enforced. It isn't pre-version 8.
Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Gareth Oliver Sent: Monday, April 08, 2013 11:16 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service BMC have implemented three options of sub-set data: Login_ID, Company + Corporate ID, FName + MInitial + LName. I haven't checked/confirmed if the same functionality exists for the Submit WS for Change/Release/etc, but the documentation doesn't reflect any updates (possibly more an issue with the documentation than the functionality). From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe D'Souza Sent: Tuesday, 9 April 2013 12:51 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service ** How has it been implemented if I may ask? I have not yet had the chance to look at 8.00 Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] <mailto:%5bmailto:[email protected]%5d> On Behalf Of Gareth Oliver Sent: Monday, April 08, 2013 9:05 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service Hi Shawn, While it doesn't help you on your current version, the requirement you describe has been implemented in ITSM 8.0; the online documentation is here >>> https://docs.bmc.com/docs/display/servicedesk80/HelpDesk_Submit_Service Regards, Gareth From: Action Request System discussion list(ARSList) [mailto:[email protected]] <mailto:%5bmailto:[email protected]%5d> On Behalf Of Joe D'Souza Sent: Tuesday, 9 April 2013 8:38 AM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service ** An alternative (given your challenges) could be to build a custom web service, with a 'Get Operation' to fetch the right user where the inputs required to get the right user would be as many inputs as you would require (First Name, Last Name, email address, Remedy Login ID, Phone Number) to correctly identify him. There is a 'instanceID' field 179 that has a unique index which you could use to set in that form (customizations will be required off course). You could use this instanceID then to feed into that create WS. I mentioned Phone number, but if you choose to add this to the search, you might need to standardize the input of phone numbers. This way you are more likely not to face issues in picking the wrong user. Given the nature of your challenges, there may still be holes in this as even with a filtered search, there is a chance 2 exclusive users might still match.. Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] <mailto:%5bmailto:[email protected]%5d> On Behalf Of Pierson, Shawn Sent: Monday, April 08, 2013 4:56 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service The specific integration that the email would be used for is originating from within one of our own company, but we have grown so quickly that we do have a lot of data issues right now. We even have duplicate login names (across domains with trusts) that have wreaked havoc on some of our systems, including Remedy where I previously had no requirement to facilitate multiple domains and was assured that login names would be unique even amongst the different domains (and one day, when they finish manually changing each duplicate they will be.) For the user that I am dealing with this on today, there are four people with the exact same name. I leverage an Active Directory integration via vendor forms with LDAP, and I have several vendor forms pulling different data from each domain since there is no standard format yet and dumping that data into a common processing form that does some data cleanup and validation then creates the CTM:People record. For a People record to be created, I require a First Name, Last Name, Email Address, Login Name, and either a Company or a Manager listed in Active Directory (who has a valid Company associated with them.) I match to the CTM:People record based on Login Name for the purpose of updates. The Remedy Login Name field is basically their AD login name with their domain included so I can guarantee some level uniqueness there. There are certainly potential holes in this process, but I have validations in place to try to mitigate those and either not create or update the CTM:People record if they fail certain conditions. Also, a lot of this should be addressed by the domain and HR application consolidation that we're going through. Anyway, thanks for your input. We use that form for web services and an email integration so it's becoming more critical than it used to be for us. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:[email protected]] <mailto:%5bmailto:[email protected]%5d> On Behalf Of Joe D'Souza Sent: Monday, April 08, 2013 3:29 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service ** I haven't used that particular web service designed for that form, but I'm familiar with that form and the web service, so that's the way I would go too. Or use the login name which is a guaranteed piece of unique information on CTM:People. If you notice, there is no unique index on the email address, so there is no guarantee that email addresses will continue to be unique, even if right now they are. I have seen small to even organizations where a group of people share the same email address if they are customer facing, e.g. [email protected] and do not have a specific individual email address. If that might be a potential case in your case, I would stick more with the Remedy Login ID, which although it doesn't have a Unique Index defined on CTM:People or the User form, there are filter checks to prevent the creation of a duplicate Remedy Login ID. There is no such workflow for email addresses. Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pierson, Shawn Sent: Monday, April 08, 2013 3:49 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service That's what I thought, thanks. I will probably take a more robust look at that and add in the ability to search by username while I'm at it since that is also a unique value. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Sent: Monday, April 08, 2013 2:47 PM To: [email protected] Subject: Re: Setting the Customer*+ on Incidents through a web service ** There's no data configuration for it. Requires adding the Internet E-mail field to the web service input mapping and then updating the filter on the Interface Create form to use it when retrieving the customer information. Jason Bess From: "Pierson, Shawn" <[email protected]> To: [email protected] Sent: Monday, April 8, 2013 2:34 PM Subject: Setting the Customer*+ on Incidents through a web service ** Good afternoon, Perhaps this is just a limitation in my own thinking, but I have a few integrations using the HPD:IncidentInterface_Create form. Since the company is growing, we are running into issues where we have people with the same name but are different people under different operating companies, but the way the web service works it picks the first People record with a matching name. I have the user's email address and could probably obtain other information if necessary to make the name unique, but in looking at the BMC Remedy IT Service Management Integrations guide, I don't see where I can actually pass any of those fields. Based on the documentation, it looks like the only things you can match on are the Last_Name and First_Name, and then return the first result. How do those of you leveraging the web services or email templates get around this limitation, or is the documentation incorrect? I am on 7.6.4 but this issue has been around since before the upgrade. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here <http://www.energytransfer.com/mail_disclaimer.aspx> . If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here <http://www.energytransfer.com/mail_disclaimer.aspx> . If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here <http://www.energytransfer.com/mail_disclaimer.aspx> . If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
