Automation Anywhere has been approved, everything is set up, and your organization is chomping at the bit to get some productivity gains from the automations that can be created using this new software. YOU are the person responsible for leading the organization in and through this automation journey. No pressure, right? One of the first challenges you’ll likely face is answering the question “What types of processes should we automate?” In an effort to help answer that question - and provide you with a maturity framework to answer that question in a different way as you continue to build experience and expertise with your automation deliveries - we’ve created a Solution Pattern Modeling Framework. The Automation Anywhere Solution Pattern Modeling Framework is designed to be applied as you evaluate and work through new automation use cases to help speed up the process of building out your automations, documenting your automations, and ensuring that your production implementation has robust error handling and the least privilege roles.
Think of this modeling framework as the patterns you’ll want to be on the lookout for as you evaluate automation opportunities. As your automation practice continues to mature and scale, we’ll be looking at more complex solution patterns that will open up doors to new types of automations that you may consider taking on. Not only does this help you to focus on the patterns that matter most for right now, but it also provides a framework for you to grow into so you don't get stuck in the rut of thinking that ALL automations have to start on a schedule and run on an unattended machine.
As we break down each of the Solution Patterns in this Start phase, make note of different use cases that you’ve heard within your organization that might fit into one of these patterns. Additionally, be ready to describe these patterns as you work with various lines of business within your organization so they too can be thinking about use cases that may fall into one of these solution types.
A final note before we break down some of these Solution Patterns. Be sure to check the links for each Solution Pattern type, as we’ve included a host of available assets to get you started, including sample automation frameworks that you can use/customize as needed, as well as some sample documentation and custom roles that you can use to give your team a head start in documenting your automations based on the solution pattern that they follow.
Run Remote Via Schedule
This is the bread and butter of automation...that is to say, this is likely the most common type of solution pattern you’ll be creating, especially in this Start phase of your automation journey. An automation that is created to Run Remote Via Schedule is an automation that is initiated using the Automation Anywhere Control Room Scheduling Capabilities to run one or multiple instances of the same automation on one or more unattended bot runners.
In practice, this may look like an automation that is scheduled to run at 3:00AM every day to generate a report to help guide prioritization decisions for an operational team, or it may look like an automation that runs every 2 hours to check for files in a specified network share for processing. Obviously, these examples aren’t exhaustive of every scheduled automation running on an unattended bot runner, but just some sample use cases to get your wheels spinning as you think about how this solution pattern may fit with some automation opportunities you’ve been thinking through at your organization.
Run Remote On Demand
In some cases, an automation running on a schedule is overkill for the situation, and what’s really needed is an automation that can be executed on demand. An automation that is created to Run Remote on Demand is an automation that is initiated directly from the Control Room, designed to be executed ad hoc to run on one or more bot runners as needed. While the development/design of the automation itself may not be significantly different from that of a Run Remote Via Schedule automation, its execution is quite different in that it’s only executed on demand.
In practice, this may look like an automation that is run to perform audits of transactions once all work for the day has been finished, initiated by a team lead once everyone has completed their work. Or it may look like an IT Support-related automation, designed to move large amounts of data from one system to another in support of a migration, executed on the weekend to limit any impact on production running systems.
Just like with the Run Remove Via Schedule automation type, take note that this solution pattern can be easily run on one machine or multiple machines concurrently...something to keep in mind as you think through use cases, throughput, and capacity planning.
Run Local On Demand
So far, all of the discussed Solution Patterns have been about executing automations on an unattended runner...likely a virtual machine running on a server somewhere. Have you considered that automations can also run locally? An automation that is created to Run Local on Demand is initiated from the Control Room ad hoc, and set to run on the local user’s machine as opposed to an unattended/headless machine hosted on some server.
The most obvious benefit of a locally run automation is that it can operate in the current user’s context, taking advantage of any already opened windows/applications , and possibly taking over a transaction that is midway through processing. This might look like a case that needs to be migrated from one system to another. Instead of the user hand keying that data from one interface into another, an automation is executing locally on-demand to kick off that data migration process.
As opposed to the previous solution patterns discussed (all unattended so far), this solution pattern represents an attended automation use case where the target machine for the automation to execute is actually attended by an operator, but an automation is initiated to give them a lift in processing speed/accuracy.
Run Local Through AARI
Sometimes an automation taking over a local user’s session isn’t specific enough to that user’s situation. In those cases, Run Local Through Automation Anywhere’s Robotic Interface (AARI) is the desired solution as it provides the ability for the initiating user to fill out a customizable interface to provide data/details that the automation may need for processing. An automation that is created to Run Local Through AARI can be initiated from the Control Room or it can be initiated through the AARI desktop shortcut that gets installed on the desktop for users with the Bot Agent installed.
The huge difference here versus a bot that is Run Local On Demand, is that Run Local Through AARI bots have a customizable user interface that enables an experience where users can be prompted for data, files, credentials, and selectable options, etc. This interface can enable users to further customize the parameters by which their automation can execute. Like the Run Local on Demand solution pattern, Run Local Through AARI automations execute in the current desktop user’s context so any already opened applications and/or local files are fair game for use within the deployed automation.
Conclusion & Actionable Takeaways
As you start to build out the first use cases for your organization, it's important to familiarize yourself with the various solution patterns that can be built out using Automation 360. Know that the Solution Patterns described here, however, are only the start. As you continue to build experience in Automation 360 and mature in your automation practice, be sure to check out the Solution Patterns in the Accelerate and Scale phase, as they will continue to open up additional use case opportunities for your automation practice.
- Download the automation frameworks/templates provided above to familiarize yourself with each of the Solution Patterns for the Start Phase
- Consider creating sample test bots for each solution pattern to understand how the framework works, and to have a demo-able asset to drive conversations with other users.
- As you talk through automation opportunities with business analysts, other developers, or users within your organization, think about which of the Solution Patterns would work best for the opportunity at hand
- As you brainstorm potential solutions with users, consider if a different solution pattern may enable a bot to be used in a different way, or if the description of a certain solution pattern sparks an idea that they may have previously thought was outside the realm of automation.
- Leverage the provided custom roles for each framework to ensure that any roles that are established for Run As users are correctly set up.
- Consider these the baseline custom roles. Depending how the runner is being used, you may add multiple roles to various Run As users to enable them to execute automations in support of multiple solution patterns.