Skip to main content
Solved

Customize email recipients when bots unsuccessfully deploy

  • February 17, 2026
  • 3 replies
  • 19 views

Forum|alt.badge.img+1

Hello,

 

Is there a way to edit/update the email recipients list for when a task bot stops running because it is unsuccessful due to a timeout error or because the bot deployment was unsuccessful? When reviewing the email notifications within settings, there is not option to enter a desired email list for where to send these notification emails to, just that an email will be sent ‘to the user who started or scheduled it’. Our team has multiple people developing and scheduling automations and it is difficult to centralize and handle the error emails with them being sent to so many different people on the team.

 

Is there a way to make it so bot timeout errors and bot deployment errors can be sent to a specified list of email recipients instead of the default listed in the email notification settings?

Best answer by Aaron.Gleason

@jtowle That makes sense. Unfortunately, looking through the admin settings for emails, I don’t see the possibility of emailing different people for different types of events. It sounds like this is something you need, so I would recommend emailing support@automationanywhere.com to request an enhancement.

In the meantime, and this is not an easy feat necessarily, you can build an automation that calls the Automation Anywhere APIs and occasionally looks for these kinds of events. Since this is accessible via REST web service calls, you can build this log monitor inside of Automation Anywhere or outside of it. Is this ideal? No. Will it potentially solve your issue? Yes, until the enhancement you requested is implemented.

See the /v1/audit/messages/list API. https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/audit-log/audit-log-events.html

This topic has been closed for replies.

3 replies

Aaron.Gleason
Automation Anywhere Team
Forum|alt.badge.img+14
  • Automation Anywhere Team
  • February 17, 2026

@jtowle Using the Try … Catch actions, you can have the automation itself to send an email to a person, persons, or a distribution group (set up by your email administrator) if the automation fails. It’s probably best to not rely on the Control Room picking up errors from bot runs to send emails. Why? Try … Catch masks the error and could make a failed bot run look like it succeeded.


Forum|alt.badge.img+1
  • Author
  • Cadet | Tier 2
  • February 17, 2026

@Aaron.Gleason Thanks for the response. We do implement try catch activities within all of our automations. The scenarios we are encountering do not allow for execution of the catch sections within the bots themselves.

On failed deployments the bot does not open/activate and does not execute any actions, therefore, we only receive the default error email notification from control center that a bot failed deployment (sent only to the user who set up the schedule/bot run).

On bot-run timeouts, a good example is if there is a message box within the workflow that runs on a virtual machine. The bot is stuck on the message box and times out, closing without executing any closing/catch actions. Again, we only receive the default error email notification from control center that a bot timed out (sent only to the user who set up the schedule/bot run).

We would like to update the default error email notification from control center to send to the entire team instead of just the user who set up the schedule/bot run. Thanks.


Aaron.Gleason
Automation Anywhere Team
Forum|alt.badge.img+14
  • Automation Anywhere Team
  • Answer
  • February 17, 2026

@jtowle That makes sense. Unfortunately, looking through the admin settings for emails, I don’t see the possibility of emailing different people for different types of events. It sounds like this is something you need, so I would recommend emailing support@automationanywhere.com to request an enhancement.

In the meantime, and this is not an easy feat necessarily, you can build an automation that calls the Automation Anywhere APIs and occasionally looks for these kinds of events. Since this is accessible via REST web service calls, you can build this log monitor inside of Automation Anywhere or outside of it. Is this ideal? No. Will it potentially solve your issue? Yes, until the enhancement you requested is implemented.

See the /v1/audit/messages/list API. https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/audit-log/audit-log-events.html