Skip to main content

 

If you haven't heard about Product Club — the Pathfinder Community Product Club is a monthly virtual meetup led by Automation Anywhere product leaders that focuses on our latest proprietary product innovations. It offers a place for community members to stay informed, connect with product leaders, and gain insights into real-world applications of the latest innovations in intelligent automation.

P.S. If you can’t attend a meeting, no worries — we'll be dropping a recap of each month's session right here in our Product Club hub.

 

HOSTS

Kate Ressler, Community & University Marketing Director 
Vineet Pujari, Senior Product Manager, API-as-a-Service 
Matt Stewart, Director, Evangelism and Content Strategy 
Nirmal Mathimaran, Lead Technical Writer 
 

TOPIC

For September’s Product Club, we’re talking automation triggers and the huge benefits on the horizon with our cloud-based SaaS Triggers. So, pull up a seat and take notes as the Product Team covers this forthcoming game-changing tool and how you can participate in the beta testing before its A.35 release!

Here’s a rundown of the session:

  1. Vineet reviews automation triggers and introduces the brilliance of SaaS Triggers.
  2. Matt touches on the high value being able to respond to events in real-time with SaaS Triggers.
  3. Vineet shares how you can join the SaaS Triggers beta testing.
  4. Vineet and Matt answer live audience questions.

 

AUTOMATION TRIGGERS - THE BASICS

Right now, there are three ways you can trigger automations in Automation Anywhere:

  • Time-based: i.e. every day at 8AM
  • On-Demand: a human user launches the automation as needed
  • Event-based: Poll your applications at certain intervals and bring data into Automation Anywhere when a new event is detected


Each of these trigger methods is very useful for many organizations and use cases. However, what if you don’t know when an event will occur? There are times when companies need to be able to respond to events with an automation in real-time. A great example of this is fraud events that occur within financial organizations. That’s where SaaS Triggers have the potential to be a powerful solution!
 

THE SAAS TRIGGER DIFFERENCE

As the name suggests, SaaS Triggers are for events that take place in a SaaS-based application and instantly trigger an automation to run in Automation Anywhere.

SaaS Triggers differ from traditional event-based triggers because they leverage webhooks, which are automated events that occur in your system and send data to Automation Anywhere when something happens. Best of all, SaaS Triggers do not rely on bot runner infrastructure. Instead, they listen to events on the Automation Anywhere cloud (independent of bot runners) and push data back to Automation Anywhere in real time. So, not only does the webhook enablement simplify that development effort, but it also allows your automations to respond nearly instantly to things without hogging up your infrastructure and becoming a monitoring and maintenance mess.

SaaS Triggers will be available in API Tasks, UI automations, and within end-to-end processes. They can be used to start a process, as well as progress steps within a process, so you can consume SaaS Triggers in any workflow.
 

OUT-OF-THE-BOX TRIGGERS YOU CAN EXPECT

With the .35 release, we are offering 5 out-of-the-box triggers that power many real-time automations in your environments. Those are:

  • Jira
  • GitHub
  • Google Calendar
  • Office365/Outlook
  • ServiceNow


SESSION Q&A

Thank you to our audience for submitting their questions! Unfortunately, we aren’t always able to answer them all during the live session. We want to express our gratitude to our special co-hosts, Vineet, Matt, and Nirmal, for providing their expertise and responses.

**Please note that all answers were shared live during the September 2024 meeting, and are subject to change. We strongly encourage you to contact your account management team for any specific licensing and pricing inquiries.

Q: Is it available on cloud only? What license will be required?
A: Yes, available only for cloud customers—that goes for the beta testing as well. For licensing, it is available to customers with the Enterprise platform license.

Q: Until the SaaS trigger triggers the bot, do we still need the unattended bot runner license assigned to the bot user?
A: No, you do not need to have that hogged up, running at all times. The Control Room is handling the trigger itself. Once the bot is triggered, the attended runner will need to be available, and that's when the license would be used, but that means that one runner could theoretically be servicing multiple bots as part of it being in a device pool, and you only need to consume that license once an action needs to be taken.

Q: Will SaaS Triggers be forever listening in the Automation Anywhere Control Room or is there a "trigger" for SaaS Trigger listening?
A: It's a webhook where the system of record will be telling the Control Room to activate rather than the Control Room constantly polling or listening. For example, if you are interested in listening to events happening in ServiceNow, a new incident created with p.1 urgency. What you'll do as a developer in Automation Anywhere is create something called a subscription. The subscription will tell you: What's the system you're interested in? What's the name of the events? And what are some of the filters that you want to supply? Once you send this set of inputs to ServiceNow, a subscription is created for you in Automation Anywhere and then that subscription stays active. Whenever the event actually happens in ServiceNow, ServiceNow informs Automation Anywhere through a notification. So the SaaS Triggers are not actually actively listening. They are active, but they're just waiting there for somebody to send an event or notification so that they can then launch the automation.

Q: Is there a max allowed SaaS Trigger amount to be listening at any given time?
A: Right now we don't have any limits. But we may put some limits based on heuristic feedback in the future.

Q: What changes/development is needed from the SAAS system side in order to enable them to send the needed triggers to Automation Anywhere?
A: Taking an example again with ServiceNow - You need to make sure your ServiceNow administrator has enabled webhooks in ServiceNow and that's it. Once you enable the webhooks, you can use the same credentials that you use to connect to ServiceNow in a bot today. If ServiceNow supports all authentication, you'll need to ask your administrator to generate the client id, client secret username, password, and a certain set of scopes which this account needs to access. That's it. You can use these credentials to create subscription in ServiceNow and start listening to events.

Q: Will there any possibilities to create custom SaaS trigger?
A: Today, we have an option for you to create custom connectors or custom packages. You can create integrations with any application that supports REST APIs. But, custom SaaS Triggers is something on our minds. We want you to empower you to be able to create your own SaaS Trigger packages and configure them the way you want and make it as easy as possible for citizen developers to consume. That capability will not be coming in the .35 release, however. That said, I have that item on my roadmap, and we will definitely think about introducing something like a custom SaaS Trigger builder.

Q: We're working on introducing device pools. For the device pool setup we were advised to switch our triggers to time-based scheduled. Will SaaS triggers work within a device pool?
A: Yes, absolutely. Because SaaS Triggers is more about how you launch your automation, whereas Device Pool comes into the picture when you want to actually run your automation. You get the opportunity to assign either a device pool or a role while setting up your SaaS Trigger. So you have complete control over on what device your bot runs if it is triggered by SaaS Triggers.

Q: What are the pre-requistes to interact with SaaS ?
A: A connection to the SaaS app will be required to connect to the app. This connection could use any of the standard authentication types.

Be the first to reply!

Reply