I have an issue where I am not able to deploy workflows to my scratch org because the workflow contains email alerts that specify an Org-wide email address as the sender. The error I get is: You must specify a verified org wide email address for this sender type.

I understand that the error comes from the fact that for an org wide email address, it must be manually verified by clicking on a link sent to that address after it has been added to Salesforce. For the scenario of deploying these to scratch orgs, I considered it unfeasible to manually setup 5+ different org wide emails as a pre-deploy step, especially when the email accounts are owned by my client and not myself.

I also considered creating a script to manually change the sender type of these email alerts to send from the default user instead of an org wide email address (according to the metadata API, that would be changing the senderType and and senderAddress tags in the XML file). However, I would still have an issue where even if successfully deployed these workflows with a modified sender, if a developer made workflow changes and pulled them using sfdx force:source:pull, then they would pull down those script changes which we wouldn't want to commit.

This seems like it would be a relatively common problem, yet I haven't found any similar questions online. Does anyone have any experience dealing with this issue or have any suggestions?

  • I have this issue as well, did you have any luck in resolving this?
    – Andreas86
    Feb 20, 2019 at 12:28

2 Answers 2


something so simple and still such a big blocker. For now here is what we have been doing.

I have a nodejs script that replace




I marked the line in my meta.xml file by commenting <!--orgwideemail--> so I know the one I want to update. Then I make sure I don't commit this changes to my branch.

Another option is to take it out of your metadata and make that config a manual post deployment step.


You can create the Org Wide Email Address via the REST API (POST) and then subsequently issue a PATCH request (empty body) against the new record and it magically becomes verified.

This is surely an 'undocumented feature' that might be fixed some day but until that day, it's a rather painless workaround to a significant gap in SFDX and metadata support.



  • That day came a while ago, this hack no longer works
    – Andy Ray
    Oct 22, 2022 at 21:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .