Emails in Non_prod environments.

(0) Share

Report

Posted on by Community Member

Hi,
Can someone direct me whats best way to handle emailing in Non-Prod environments.

We want to set "EmailTo" to some dummy email address if its non-Prod environment.

As per my research

- One way could be take care of in code where ever there is email is being sent out. Change the "EmailTo". Do i have to go through whole code base and find out where the email is being sent out ?

- I see there are three basic class in d365 which handles emails. SysMailerExchange, SysMailerSMTP, SysMailerEML. Should i customize sendEmail in all three class ?

Any help is appreciated.

I have the same question (0)

All responses (4)

Answers (0)

Sort by

André Arnaud de Cal... 305,823 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Manishspatel,

Are you considering creating customizations for a non-production environment only? To be able to do proper testing, the production environment should have the same code base.

To prevent sending emails, you can remove the settings for email integration.

When you want to test it, you can also change the email addresses from the users to one single email address (User options not the login email).

Was this reply helpful? Yes No
zhifeng Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

Agree with Andre that to avoid email confusion, you can prepare a script to update user email address once you complete database refresh.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!
No , code wouldnt be different from Prod but there will be coniftional statement .. for example below code snippet. This is from our legacy system in which we were using only one Email Class (SysMailer). In D365 there are atleast three built in classes which could be used to send email.

if (!OIProductionSafety::inProduction()) { oiProductionSafety = OIProductionSafety::find(); if (!oiProductionSafety.OverrideToEmail) { // If there is no redirect email, toss out an error and then return // OIL872 = "There is no override 'To' email entered in the OIParamters form" error("@OIL872"); return; } // If we are not in production, change the 'To' values to just be the test account // and blank out the 'CC' values tos = this.tos(); tos.clear(); tos.appendAddress(oiProductionSafety.OverrideToEmail); ccs = this.ccs(); ccs.clear(); subject = _COM.subject(); this.subject(strFmt("%1_%2", subject, conpeek(str2con(new SqlSystem().loginDatabase(), "_"), 1))); } //BP Deviation Documented _COM.send(); }

Was this reply helpful? Yes No
André Arnaud de Cal... 305,823 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Manishpatel,

To me, it just doesn't feel like the correct approach to create coding which is changing the behavior of a non-production environment. There are alternatives as mentioned above. Each change on the environments will have a certain risk and cost of ownership.

OIProductionSafety seems to be a custom table. What happens if you forget maintaining this table? You are forced to change the contents of this table to ensure you are not sending emails to normal users or customers. Instead of this table, why not just removing the e-mail parameter settings? In the email send status, you can then check if mails are being generated and if the contents is correct in a non-production environent.

Besides, what would happen if Microsoft replaces the three send methods with a new fourth class and send method and you are not aware of that...?

Was this reply helpful? Yes No