Email Debugging with Environment Variables in Power Platform
Every Power Platform team has a horror story: a test flow that emailed 4,000 customers by mistake. Environment variables fix that class of bug once and for all.
The problem
A flow developed in DEV that reads recipients from Dataverse will happily email real customers the moment it runs. Solution import between environments does not filter that.
The fix in one sentence
Store a DebugRecipient environment variable in each environment (DEV/TEST/PROD). In DEV/TEST it holds your address; in PROD it stays empty. Every email action reads that variable and, when it is set, overrides the To field.
1. Create the environment variable
- Type: Text
- Display name: DebugRecipient
- Default value: empty
Set a Current value per environment: your own email in DEV/TEST, nothing in PROD.
2. Wire it into your flow
To = if(empty(variables('DebugRecipient')), triggerBody()?['Email'], variables('DebugRecipient'))
3. Prefix the subject in non-prod
Subject = if(empty(variables('DebugRecipient')), triggerBody()?['Subject'], concat('[DEV] ', triggerBody()?['Subject']))
4. Enforce it via ALM
Include the environment variable in the solution. Each environment defines its own value at import time, so you never accidentally ship DEV defaults to PROD.
Bonus: same trick for HTTP endpoints
Store per-environment webhook URLs (Teams, Slack) in the same way. Your PROD flow calls the PROD channel, TEST calls the TEST channel, DEV logs nowhere - automatically.
Wrap up
Environment variables are five minutes of work and cover a whole family of production incidents. If your solutions do not use them yet, this is the highest-return refactor you can ship this week.