There should at least be a banner or something that shows what is and isn't respected by the rule.

What I'd love to see is an option to dis/allow automations to respect when outgoing mail is disabled. A child toggle, basically.

Definatly a bug +1,
at very least should be clearly documented as current behavour on the outgoing mail configuration screen.

When it says "Outgoing Mail: DISABLED" my expectations are set that ALL outgoing mail is disabled.
If it is not then it should clearly state the caveats to that alongside this setting.

This has potential to cause serious reputational harm to your users, especially during migrations.

Loss of trust in your product as what other undocumented "Features" will we roll into next because its not been treated as a bug and solved or as a feature and documented clearly on the admin screen.

+1 for bug. It is not neccessary for sending out E-Mails from a sandbox instance when outgoing E-Mails are disabled.

Users receiving emails from automation rules running in an environment with global email disabled creates confusion. I agree, this is a bug.

This is a bug. 

I see this is a "Suggestion". Can you please revisit this as it is clearly a Bug.  If I disable emailing on an instance, I expect no emails to be sent out.

If emails still go out  ==> it is clearly a Bug.

It's maybe a known bug, but it's still a bug; especially since there is absolutely no hint of this limitation in the interface.

—

Impact is huge, especially for migrations.

Imagine you are preparing / testing a migration and  have hundreds of automations that you need to test. Some (many of them) trigger emails as well. You are confident that no emails will be sent out (since emailing is disabled); and you are anyway on a Sandbox instance. You have assured the customer as well that no emails go out

You start testing and emails do go out. Now imagine the avalanche of confused end-users and the, at best, disappointed customer.

Seriously?

+1

We're having this issue with a sandbox environment used for our Server to Cloud migration. Users are getting confused by notifications about old tickets since the sandbox is not up to date with the Jira Server.

Hi. Since July 1st 2023 I have experienced behavior matching the expected result explained above. That might be okay for some, but for me who have created email integrations with other systems, this is causing problems. I used to have made an agreement with our receiver system that emails from Jira comes from no-reply@automation.atlassian.com and not from automation@{my-jira-address}.com which suddenly is the case. Has anyone experienced something like this?

This is a major issue and needs to be addressed.  For the most part, we build our Jira structure and automations in the sandbox first and do a considerable amount of testing (often using real reporters as ticket creators).  With automation sending out emails from our test efforts in sandbox, it results in a lot of confusion.