Triggered alert from Sandbox not firing when logged in as non-admin
Stumped. Any ideas?
Then test out the process using that newly customized user, without .invalid on it.
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.
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
Then test out the process using that newly customized user, without .invalid on it.
one for the books.
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:
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 :)
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
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.
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:
Screen shot of email alert generated from user with .invalid email prior to 5/31.
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 :)
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..
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.
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.
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.
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
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 :)
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
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