Ask Search:
Jon RaneyJon Raney 

Triggered alert from Sandbox not firing when logged in as non-admin

In my sandbox I have a triggered email alert set up based on a change in a record. I have it sending the alert to my personal email address (I gave up on my work email. it just won't do it). It works just fine when I (the admin) triggers the change. But I was logging in as the team user (with lesser privileges) it doesn't fire. I'm really not understanding how that could be. How is the process contingent on who is changing it? There is no such "who changes" criteria in the Process builder, only the record itself. 

Stumped. Any ideas?
Best Answer chosen by Jon Raney
Pattie HeintzPattie Heintz
".invalid" is one of those special cases that Salesforce uses to completely interrupt an email going out.  If the address ends with .invalid it won't even attempt sending an email, it just stops entirely.  I recommend changing one of your non-admin user's Email addresses to your own personal email address. 
Then test out the process using that newly customized user, without .invalid on it.

All Answers

Pattie HeintzPattie Heintz

Wild guess, because I'm not sure if it is right, but have you adjusted your Email Deliverability settings to All Email? (Setup - > Email Deliverability)
Maybe because you are admin the system considers it System Email and allows it through, while a regular users is just stopped?

I think anything deeper will require screen shots of your process and the Email Alert that you have created.  If you post those, some of the experts here might be able to spot the issue.

Jon RaneyJon Raney
Hi Pattie,

Yes the deliverability setting to All was the first thing I did. Otherwise it's just tumbleweeds from the Sandbox:) As far screenshots. I suppose I could but this is kind of oddball case. The logs seem to show that there is no triggered email sent unless I'm logged in as an admin user and trigger the change.

It's a combination of process builder - that writes and stores the previous value in a field and a triggered email that alerts a supervisor and shows the new value and the previous values in the body of the email . I have myself as the email alert recipient and no one else. The other users - to not cause problems have the standard .invalid email suffix in the sandbox. But even if they were sent to that invalid email somehow, there is still nothing on the log and they are not delegated as recipients on the email alert
Pattie HeintzPattie Heintz
".invalid" is one of those special cases that Salesforce uses to completely interrupt an email going out.  If the address ends with .invalid it won't even attempt sending an email, it just stops entirely.  I recommend changing one of your non-admin user's Email addresses to your own personal email address. 
Then test out the process using that newly customized user, without .invalid on it.
This was selected as the best answer
Jon RaneyJon Raney
Brilliant Pattie. That is indeed the answer. It doesn't send it if the user's email is invalid regardless if that person is the person triggering the change is the recipient. Pretty odd since the action is validated... but there you have it!

one for the books.

best

jon
Benjamin PirihBenjamin Pirih
This is not the expected behaviour and users with .invalid email would send email alerts up until recently (Two weeks ago).  I have an open case with saleforce regarding this issue.    Not sure where Pattie found documentation of this change or why she believes this to be the case but up until very recently - Last two weeks this worked as expected.  THIS SEEMS VERY WRONG!!  Jon this effects all email, workflow, process builder, apex..   This causes issues with testing and validation.  We had just performed a full validation in our sandbox with this functionality working before MAY 31 and users with .invalid email were sending email alerts..   IT STOPPED WORKING TWO WEEKS AGO AND THIS IS NOT THE EXPECTED BEHAVIOUR!! 
Pattie HeintzPattie Heintz
Hi Benjamin,  you seem to be very upset about this, heh.

Salesforce has always obfuscated user email addresses on sandboxes, however it changed how it obfuscates recently.
Originally it would append the sandbox instance to the users email address, and not the keyword '.invalid'.  This would allow the attempted emails to go out (however, the would bounce back because the email address doesn't exist.)

Here is an article that explains the changes that occurred:
https://help.salesforce.com/articleView?id=000333417&type=1 (https://help.salesforce.com/articleView?id=000333417&type=1)

There is also a link at the bottom that explains how to update the email addresses for everyone if you need, you can always change their email addresses 'back' to the old obfuscated way to make everything work like it used to :)
Benjamin PirihBenjamin Pirih

Hi Pattie.. Thanks for the follow up comment.  Those articles still don't address the issue we are seeing.  We have multiple emails alerts and processes that sent emails with .invalid users right until the 28th of May.  Yes this has caused issues with testing / validation in our sandboxes.  

We did search and cannot find any other reference to this issue unitl Jon posted this on May 31st.  I understand your want to be correct here but do you have proof that this didn't work before May 28th?  As we have many emails and a team of validators who say it did.. :)   The behaviour you describe in your answer is not how the system worked until very recently.  If this is a recent change then we would like to see some sort of documentation.  Regards, Ben

Pattie HeintzPattie Heintz
Hey Benjamin, I am not trying to be right here, just a regular salesforce user trying to help out others.  I cannot say exactly when salesforce changed it's sandbox obfuscation method.  I know it was around the end of May when I first noticed it was changed from email@domain.com@example.com to email@domain.com.invalid.

The .invalid keyword has blocked email going out for years, though.  I know because I have used .invalid for my queue email addresses in my production instance to squelch emails being sent.

I learned how .invalid works a couple years ago from this article: https://help.salesforce.com/articleView?id=000323036&type=1&sfdcIFrameOrigin=null (https://help.salesforce.com/articleView?id=000323036&type=1&sfdcIFrameOrigin=null

I also believe you and your team of validators are correct, stuff did work before, when the email addresses were in a different format.  If you change all your user email addresses to the old format and try your tests again, maybe they will work?

​​​There was this post here from April 28th that noticed the change to user email addresses: https://success.salesforce.com/answers?id=9063A000000ippGQAQ , so some sandbox servers were updated with this change around that time.

When I get back to my office tomorrow I will see if I can look through the past salesforce release notes and maybe I can get the date range of when they released this change.
Jon RaneyJon Raney
If I may chime in here. Do I have proof. Well yes, as far as I'm concerned. Salesforce email log files. The emails didn't go out to valid email addresses when the action was performed by a user with an invalid email address - that user was not the recipient of the email. All other emails from the workflow process produced emails. As soon as the user with an invalid email was changed to a valid email, the recipient (who still had the valid email) now received the email. I can't think of any other reason for this. Seems like clear cause and effect to me.
Benjamin PirihBenjamin Pirih

We have over a 150 rows in the email log that were sent from 5/15 - 5/28 from user with .invalid ( see example below).  After 5/28 we do not see any more emails from users with .invalid when the functinality stopped working.. 

All of the emails were .invalid at when this sandbox was refreshed on 4/9/2019

Something has changed prior to 5/31 and this BROKE the existing functionality where users with .invalid email could send emails.  

Example log row:

5/21/2019 15:1471/35-18966-BE514EC5Dopportunityapproval=1-2eply4gndw992fqg7ihc4fx7duokv601fcd84almxx4e0pf0y8.1b-dbtgea0.cs25.apex.sandbox.salesforce.com@1b-dbtgea0.apex.cs25.cmp.mail.sfdc.netluser=company.com.invalid__0-7zlrz7o60693yh@u4xuh0557uclnn.1b-dbtgea0.cs25.bnc.sandbox.salesforce.com10.246.65.2141976005C0000003SY1Y<_ZSvi000000000000000000000000000000000000000000000PRV10P00a9Edq7kDSMKlKuvYA3Daow@sfdc.net>08.485672    :unverified

Screen shot of email alert generated from user with .invalid email prior to 5/31.

User-added image

 

 

Pattie HeintzPattie Heintz
I can see where you are coming from, so I can understand why you are frustrated.  It must be another issue than what prompted Jon to submit a question here.

I don't know what else Jon and I can provide you about your issue, beyond recommending you try the same fix, which is ensuring your sandbox user email addresses do not end in the .invalid keyword, and as you have already mentioned, you contacted salesforce support.

​​​​​​If you find any more details about salesforce changing how invalid works or other facts, please post them on here so you can help out anyone else that stumbles on this thread :)
 
Benjamin PirihBenjamin Pirih

Thanks Pattie.. FYI - finished a phone call with SF support where they did confirm that this is not working as expected and the email should be sent.  I'll continue to update this thread as I hear more from support.  As you suggested we can update the emails but we shouldn't have to do this.. ( as we never have in the past ).. 

-Jon you are 1st lucky person to stumble upon this and report it.. 

Benjamin PirihBenjamin Pirih
Jon would you mind providing the sandbox instance you are on for support?  Thanks!
Jon RaneyJon Raney
CS96
Jon RaneyJon Raney
I have an interesting related problem in production. Salesforce will not send a triggered email alert logged in as a test user (its a Process Builder action connected to an email alert); it sends the email when action is initiated logged in as myself or another admin. The test user has all the privileges of a regular user to make changes on the test record but it won't trigger the email.  

Here's what I know, the test user was establised by another admin here, has his valid test email connected to it and has been used since 2016. It's not being blocked (for spoofing let's say) by gmail sending server. The emails not received are not in the Salesforce Send logs. 
Pattie HeintzPattie Heintz

Are there any error messages that you receive?

You could also add a simple record update to a field on the record before the email alert, just to pinpoint where the issue is.  If the record gets updated fine and no email, you know to start looking at something email related on the user/email settings.  (Have you checked the profile of the user and whether it has "Send Email" enabled on it, for example).

If the record update doesn't happen then you can focus on the criteria of the process builder or something else stopping the process from triggering entirely.

Jon RaneyJon Raney
Hi Pattie,

Thanks for weighing in . The Send email option is enabled in the profile. Just a background, the test user  has a cloned role and profile of a regular user with a few additional permission sets on the test fields as well as a special page layout for that profile. The original profile that it was cloned from has all the emailing options (I tested that too). As far as the process is concerned. There are 3 record actions that take place and at  least 2 of the 3 are successful on any profile test profile or no.  2 fields get written two in a Process builder, and the email alert is also kicked off in the same process builder alerting certain users to the change that has taken place.

I had a version that removes the email component of the Process Builder and used a Workflow version to send the email via Workflow rule. The result is the same. No email when initiated from the Test user login. There is something wrong with this profile and the way Salesforce looks at it from an email point of view. Salesforce doesn't send the email with the test user login. I have proof of that from the logs. And this quirk is really similar to the original I was describing. Salesforce somehow invalidates the email action of this test user.
Pattie HeintzPattie Heintz
You said a previous admin had created the user. Is it possible the admin programmed some security around the user so it cannot send emails? Just as a protection to make sure the test user doesn't accidentally email a salesforce lead, contact, or user? Is there a field on the user that categorizes it as a test user account (like a checkbox or flag of sort) ? If so you could browse user fields, open the field and click "Where is this used (Beta)" near the top of the page. That button may only be available to you in a sandbox, so you may have to refresh or create one and check the button that way. I'll brainstorm some other possibilities and let you know if I think of any!
Benjamin PirihBenjamin Pirih
Hi Jon,

Suspect that this 'test' user is using a different profile and that profile is not invoking the workflow rule.  Would suggest you limit scope of problem by ensuring that the workflow rule is firing( try creating a task or doing a field update ).  If you are sure the workflow rule is firing then next steps would be to determine why the email isn't being sent.  Same thing if using process builder.  Most likely a profile permission issue is preventing the rule from firing.. you need to troubleshoot to figure out what is wrong.  Missing field level security?  If the rule is firing you should see a log in the email log history which can provide more info to troubleshoot.  Regards, Ben
Jon RaneyJon Raney
Hi guys,

The email action is 1 of 3 actions specified by process builder. 2 of the 3 are executed without issue from the action initiated by the test user profile. So as far as I can see, the "rule" for setting the action is working as well as the subsequent actions - except the email action.

In terms of the Salesforce profile, it is one that was set specially to target the page layout and have unique privileges and permission sets to access and edit the object and fields in question. The profile is valid when applied to an existing user that has the test profile applied and can initiate all 3 actions including the email without issue. 

It's possible that there is some disagreement from Salesforce requiring a unique email-user association and doesn't allow for the duplication of the email address to another user account - as it applies to initiating email actions. Maybe this explains why the profile type applied to another user works, don't know.

But your guess is as good as mine :)
Benjamin PirihBenjamin Pirih

Interesting Jon.. So this isn't profile based but might be related to original issue with invalid email.   Similar to what we original issue you posted. 

FROM SALESFORCE SUPPORT: 'The behavior you are experiencing has stemmed up from our recent Summer Release, and the changes was made due to security issue. You should not be able to send email from email addresses that are not validated. In cases where its not possible to tell if the email address is not verified, the system checks the Login date and if they (users) have logged in, the system allows it.'     
 
This was communicated to me via a support but at this point there is no documentation regarding this change or how it should work..


So I would attempt to either update this users email address or do a direct login with password as this user ( don't use the login as user feature).  Regards, Ben

Jon RaneyJon Raney
Hi Ben,

So I guess this is a flavor of the same thing, the validity of the email. In this case that the email address of the user was already assigned to an admin user. We assigned a new unused email to the test account and the process builder generated email fired without issue.

So there you go. Another Salesforce mystery ...solved

'til next time

Best

jon
Benjamin PirihBenjamin Pirih
The orignial issue ( not sending emails ) has been documented as a bug:  https://success.salesforce.com/issues_view?id=a1p3A000001SHorQAG  and is pending a fix