- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-26-2013 06:42 PM
Hi All,
We have implemented SN recently and by default all users have a single email address. eg username@example.com. Every morning we get an upload of user data via a MID server. All of this functions correctly however it has only recently come to our attention that a large number of our users are actually using other company alias. These alias when they are emailed to the instance will create a Guest incident.
What I need help with is how would I get, if I had a list of email alias @hotmail.com, @gmail.com etc, the inbound action to check that list and then raise the Incident as the user in our system
Any assistance would be grateful.
Thanks in advance.
Gareth
Solved! Go to Solution.
- Labels:
-
Orchestration (ITOM)
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2013 11:50 PM
1) Table "email alias" (u_email_alias)
a) 2 fields minimum (u_email, u_user sys_id) + active, domain... (optional)
2) inbound action
a) gliderecord (u_email_alias)
b) query (u_email == email.from)
c) current.caller_id = u_email.u_user
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-27-2013 08:20 AM
Hi Gareth,
What is your requirement, "One possible alias or N possible alias".
In the first case, it's a new field on the user table
In the second case, it's a table "email_alias" linked to the users (1 user, N email addresses)
And then, you just have to update your inbound action to find the users in this "email alias" table.
In case people with a "personal hotmail / gmail" issue read the message:
If I were you, the first thing i would check is "Does the current situation accepted by the CIO?" because before modifying the tools, i think you have a potential security issue as the personal hotmail/gmail addresses doesn't have any corporate security rules (strong password, change your password every x weeks...)
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-27-2013 03:38 PM
Hi David,
Thanks for finding the time to respond. Ideally option 2 a table would be ideal. Don't worry about hotmail or gmail as aliases they were just examples. How would I get the inbound action to go through the table and check again all the email aliases and link them to a user in the system.
Regards.
Gareth.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-29-2013 11:50 PM
1) Table "email alias" (u_email_alias)
a) 2 fields minimum (u_email, u_user sys_id) + active, domain... (optional)
2) inbound action
a) gliderecord (u_email_alias)
b) query (u_email == email.from)
c) current.caller_id = u_email.u_user
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-11-2014 04:28 AM
Hi all
Looking at possibly implementing this, as we have a few users who have both internal address and external ones (as they are external companies. our policy is that all email addresses in our internal AD must be internal addresses)
at times some of the users forget to correct the outgoing address so they come in as Guest or bounce.
However, I do have a few of questions
First,
when a new record is raised, I have the line
current.called_id = current.opened_by;
- What determines the current.opened_by - can this be amended to reflect the email address in u_user_email or will it only ever work off the user table ?
- If 1 cannot be achieved, is there a sys_id that would be returned to identify a guest record so I can then lookup against the u_user_email table and get the correct user sys_id ?
Second, on the update actions, I do not see anywhere where it is establishing the name of the user, so I guess that goes back to my first question in the point above as it must be looking up against just the user table.
cheers