CA Service Management

Hi All,

Have any of you been involved in requirements regarding creating and assigning a contact based on an Incident/Request being created from an email read by the maileater in CA Service Desk Manager (version 14.1.03). If the email is not known it will be created against the System Anonymous  (yes this installation allows for anonymous email and the extra spam-filtering and other security related issues will be handled on the mail-server) but this will then not enable any of the defined notification rules for notification to the Affected end user.  

The wanted behaviour is that instead of creating the Incident/Request against the System Anonymous user a new contact should be created for that email-address and preferrably also related to organization/tenant based on the domain-name of the email-address and set as the Affected End User. I understand that the most likely way of solving this is in spel-code, and my main question is if it is possible to update any attribute on the Incident/Request with the sender's email-address?

Best regards,

Geir Torsteinsen

Hi Geir,

I dont beleive there is a way to do this because there are required fields on the contact records that must be filled in to be able to save a new contact.  Even with spelcode, I dont believe that you would be able to parse an email and create a new contact based on the email address.  I think this would make for a great enhancement idea, however, I dont think it would be possible even with custom spelcode.   Thinking outside the box, the only way that I could see this being done is by using a two-step approach -  having some type of intermediate application which would act as a mail relay, first grabbing those emails before they get to maileater's mailbox, parsing the email, running a web services call to SDM to check if the contact exists for the "from address" and if not, then making another web services call to create that contact, and then forwarding that email on to the maileater mailbox.  Unfortunately that is outside of anything CA could assist with, but there may be other customers out there who have gotten something like that to work previously and may be willing to share their info with you.

Thanks,

Jon I.

Hello Geir,

What Jon said - and there are probably alternate ways of using the "in between" process. It could use pdm_load instead of Web Services for example.

If possible, you'd be best off capturing all of the client information in some third party system, and then creating an LDAP integration.

For example.

• All Employees would be part of an Active Directory (or similar).
  Load up everyone who conceivably raise a ticket.
  
  
• All Customers will probably come through a web "sign up" form of some type, somewhere. 
  Have all of their details loaded up.

This way, when they do come in, they're known, and the ticket is created as normal, using their Contact details.

The other big picture item is that you would need to plan for a Denial of Service type attack, where someone could send your system a huge number of emails and create Contacts. There would need to be a guard against that from the start. This is where having that "intermediate step" is actually a good thing, as it means that authentication check has hopefully already happened.

Thanks, Kyle_R.

Thanks for your input Jon and Kyle.

I will take your suggestions into consideration, but still think I will be able to solve this functionality with a spell-trigger and a supporting table for storing domain-specific information (which organization/tenant new users should be related to, contact type, access type etc.)

Is it possible to fetch the email-address from the sender and store that in a field on the Incident as part of a mailbox-rule definition or in definitions in the text_api.cfg?

Hi,

have a look into ITPAM, you can easily meet your requirements having PAM reading the emails, apply any logic you may want and create the contact and associated ticket in SDM will all the necessary information.

my 2 cents

/J

Of course. That is a great suggestion.

I sometimes have a blind spot for PAM (don't know why), but it really is very powerful.

Kyle_R.