5

I want to push the code which has email alerts. However, it is not allowing because in the email alert its using org-wide address.

I searched and it seems not possible at this moment(v50.0). However, putting (somewhat duplicate) question to know if is there any way to bypass the issues for the pushing the code.

E.g. any setting in config file to mask the error. It's fine if it didn't create the org-wide-address which I can create later.

PS - This is mainly requiring for CICD. There is additional overhead while deploying to actual sandbox to replace the string in workflow email alert.

Improve this question
2
  • It sounds like you already found another question on this on SFSE. Which one was it?
    – Phil W
    Commented Oct 8, 2020 at 14:37
  • salesforce.stackexchange.com/questions/244217/… It was similar, we do have unlocked package and mdapi so i can use both, only thing troubling is what if tomorrow someone forgot to change similar setup.
    – Ysr Shk
    Commented Oct 8, 2020 at 14:56

1 Answer 1

Reset to default
0

I would suggest you to rethink what you are going to deploy to your scratch org, and also not to deploy metadata that relies on the org's configuration that can not be deployed.

The reason not to deploy this, in your situation, is that org wide addresses are org-specific, not project-specific. So you will face issues deploying that. You can't even deploy those as change sets if you wanted to (the addresses, not the emails).

Think about it this way: scratch orgs are a convenient way of deploying an application's metadata for testing and development. If your app were to be installed in an org, you wouldn't want to set the org addresses for the package's subscriber, right? This is a task the administrator should do after installing/deploying the app. So, logically, it should be left outside the project/repository.

This logic works for many other components too, such as case support processes and milestones.

Improve this answer
6
  • As of now, we're changing the word only to make it work. As i said, as a part of our CICD process we need to validate every change for scratch org as well(so that new devloper can create and work on scratch org swiftly). For sandbox &/or prod we're creating before deployment so that it won't break deployment.
    – Ysr Shk
    Commented Oct 8, 2020 at 15:39
  • Regarding change-sets, we're not creating on-the-fly orgs so its fine there.
    – Ysr Shk
    Commented Oct 8, 2020 at 15:40
  • 1
    Packaging is not an exclusive feature of AppExchange apps. You can develop internal apps for your own organizations and customers. They don't need to do this every time you deploy your package (unless your admin is using a scratch org too, which is advised against, since it is an environment suited for code development).
    – Renato Oliveira
    Commented Oct 8, 2020 at 15:48
  • 1
    The idea is to deploy the "base app" and let admins configure it on production. A custom apex action, for example, which can be used in a flow, should be developed and tested with a scratch org. Once deployed, the admin can add it to a flow on a sandbox. Bug fixes and new deployments of the same app (but different version) won't undo the flow configuration (so there is no rework for the admin).
    – Renato Oliveira
    Commented Oct 8, 2020 at 15:50
  • 1
    Actually we'll be using that email alerts for different modules[PBs to be specific](not at single places) of package, so if I remove it out of package it will not work. So as of now its hard to remove. But for future packages will surely consider to make those out of packages.
    – Ysr Shk
    Commented Oct 8, 2020 at 16:34

You must log in to answer this question.

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