Great news! This is indeed also one that has come up most from customers when they are moving to the new action.
I was also wondering if any work is being done around the attachments? At the moment only a fixed/static attachment in the automation can be sent, however it would be great if that could have more flexibility.
I'm thinking about:
Ability to use a smartvalue to add one or more attachment from the work item
Possibly using a regex/filter to attach certain (filtered) items from the work item to the mail (this could be through a prefix or word in the file)
At the moment we're looking at a use case where a Change exists with documentation attached to it. This could be an implementation plan or just documentation about the Change for certain stakeholders/end-users.
It would be great if we then could use an automation to send them this documentation at the time of release/implementation.
Atlassian Team members are employees working across the company in a wide variety of roles.
April 15, 2026 edited
Hi everyone,
Just sharing we have now implemented CC/BCC functionality on Send customized email action. This was our last blocker for migrating from the legacy action.
Once again, thank you so much for your valuable feedback. I'll keep sharing updates as we roll out the migration.
Unfortunately I don’t have a specific timeline to share yet for dynamic attachments on emails, but I can confirm we’re actively working on improvements here. I’ll make sure to follow up when there’s news to share.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
I'm glad that this migration is complete. And I'd like to offer some feedback about the impact it had on our Enterprise-level org. It was not flawless, and I'm still fixing things.
Throughout the hundreds of Jira automation flows defined in our Jira Cloud, there were some that used the prior "Send email" action. Those actions WILL fail now, after the migration.
What I have seen in the flows that I have manually mitigated so far is that the "Send customized email" action has two new fields and both are required to have values. Those required fields were left blank during the migration. This problem still silently sits in some of our flows. It won't become evident until that action is executed, then they will fail.
One field is the new "Email name" field. The migration could have filled in that field with a reasonable default value. My first thought would have been the flow name. But now I have to track all of them down myself and manually fix them.
The other field is the "From" field. Also required, it was not left with a valid value post-migration. The ones I have manually mitigated show only one valid value in the drop-down. Again, a case of a seemingly obvious default value that could have been filled in during the migration.
I don't need help or ideas about tracking down or mitigating all the rest of our broken flows and actions. I can do all that better than most. My point here is I shouldn't need to do all that work at all.
As I wrote here on 26-Feb-2026: "It's [...] critical that any eventual cutover to the new email component not impact the rules we already have running across our org".
Most here know I am a strong Atlassian fan, and have been for many years. And this migration included some problems which look to have been quite avoidable. I'm still a fan, just unhappy about the results of this migration on our org.
33 comments