Email Properties - help with incoming

[Rob Sestito]

Hello SN Comm,

Looking to get a little help with incoming emails to the system, when the user is set to Inactive.

When a employee becomes termed, their SN account is set to Locked out and Active = false, per our integration with Workday. If there is a user that is termed, and their current email is connected to their account in SN, they email into the system, their email is ignored.

I have to manually set their user account to active, while still locked out, and reprocess their email. When I do, the email is then moved from the Junk inbox to Reverenced inbox. Then it is processed.

We have heard that some of the "alumni' type of roles can help with this. However, that is not becoming true as this has been tested.

Does anyone know if there is a system property when it comes to a situation like this, that can be adjusted? If the incoming email matches a user account, but their account is Active = false, we still want their email to process correctly.

If there is no email matching to an account, then the Guest account takes it from there. So that is fine - but we need some help in figuring out what we can do about emails matching accounts to users that are inactive. We don't want to go around and keep everyone that has been termed, active.

Any help is appreciated!

Cheers,

-Rob

[michaelj_sherid]

Hi Rob,

Typically the account is de-provisioned when the employee is past the Employment End Date, so the company email would be inactive. In New York we introduced the functionality for email replies to be recognized from personal email addresses. This is the key for communicating with New Hires and Alumni. 

Regards,

Mike

[Rob Sestito]

Hey Michael,

Okay, and I do understand that logic. And our system does recognize their personal. IF it is captured in workday. Only a third of our employees actually have/use a "company" email address. The rest have none OR user their personal. If I have an employee using their personal for the main email address, it is tied to the main email field in SN from WD. When the employee is termed and emails into the system, their personal email address while still being the placeholder for 'email' - will make it to the system. However, they are termed, so they become inactive and locked out. So their email goes to the Junk folder in our SN mailbox (same logic is applied to ongoing cases if the employee becomes termed during an active case - their replies will go to the Junk mailbox).

When I see this in the inboxes, I have to go to the user account, make them active, reprocess their email, and then it hits it target. It's a daily thing for me that I have to do this.

If I have an employee that had a company email address, yes that email goes away. When they email into the system, a couple of things can happen. If they had a personal email in the personal email field, their account will be picked up and the system will allow their email to create/reply to a case. If there is no email matched then they are Guest.

That is fine - but my issue is when the other scenario happens. Email is matched, they are an inactive employee, their email goes to Junk.

I have been told before, by SN and a 3rd party group (The Anti), that the Alumni role could help with this - but it never has. 

Hope this sheds more light on where I was going with this post.

Thank you so much!

-Rob

[Michael Jones - · Accepted solution]

There isn't a system property, attribute or role that would bypass this particular core functionality that I have ever found. Generally the proposed "solutions" are: 

1) Use Locked Out instead of inactive - as you've discovered, with the correct property inbound actions for a locked user will process. It sounds like this one is not really an option for you. 

2) Remove the e-mail address of inactive users - this could be done via a business rule when the inactive flag is set. I typically suggest moving the value to a custom field if you want to keep it. 

3) Similar to #2, you modify the e-mail address when the inactive flag is set, such as by prepending DISABLED_ to the value. That way it is still present, and human readable. 

Both #2 and #3 you are taking advantage of what you already mentioned - by ensuring there is no match on the e-mail address, the guest user is used to process the request. 

Unfortunately these are the only work-arounds that I've seen. 

If this was helpful or correct, please be kind and remember to click appropriately! Michael Jones - Proud member of the CloudPires team!

[Rob Sestito]

Hey Michael,

Thanks for your suggestions - and yes #2 option was something I considered. Like you stated, guest would basically take over. But the email address would still be there/visible to the case worker to work with the end user.

Going to mull over the options and see what we can come up with.

Again, thank you for the suggestions.

-Rob