Automation Anywhere Reusable Bots: Build It Once

Automation Anywhere reusable bots are child bots you build once, store in a shared folder, and call from any parent bot that needs that step. If you have built the same login routine four times in four different bots, you already know why this matters. You are not slow. You are paying a rework tax on every build, and that tax compounds the first time a password policy changes and you have to patch four bots instead of one.

I spent 16 years building enterprise automation, and the biggest jump in my build speed never came from a new tool. It came from treating bot logic like parts on a shelf instead of one project at a time. This post is the standard operating procedure I use to get it there.

Key takeaways

• A reusable bot in Automation 360 is a child bot that a parent bot calls through the Run action in the Task Bot package.
• A child bot can only receive and return values if its variables have the “Use as input” and “Use as output” check boxes selected when the variable is created.
• Parent and child bots have to live in the same workspace. A private bot cannot call a public bot, so you check out or clone the public bot first.
• Quick map auto maps parent and child variables that share a name and data type, and output returns either as direct variable mappings or as a dictionary keyed by the child bot’s variable names.
• The PARTS Method gives you a repeatable way to extract a reusable child bot from work you have already finished.

Why copy and paste is the most expensive habit in RPA

Robotic process automation (RPA) means software bots doing the same clicking, typing, and data moving a person would do inside an application. The work is repetitive by definition, which is exactly why bot builders end up repeating themselves.

Here is the pattern. You build a bot that logs into a vendor portal and pulls a report. Next month a second bot needs the same portal, so you copy the login steps and change two values. Four minutes. It feels efficient. Then the portal adds a second authentication step, and you own four bots with four slightly different copies of one login. The four minutes you saved cost you a day.

Copied logic is not reused logic. It is duplicated maintenance with a delay fuse on it.

If you are still at the stage of building your first A360 bot, the copy habit forms fast, because the first few bots are small enough that duplication does not hurt. The pain arrives at bot number five.

The PARTS Method for Automation Anywhere reusable bots

PARTS is five steps for turning a chunk of a finished bot into a child bot anything can call. Run it on one piece of logic at a time. Do not try to refactor a whole bot library in a weekend.

P: Pattern spot

Find the logic you have built at least three times. Three is the threshold because two could be coincidence and four means you waited too long. Common candidates: application login, file archive and rename, date formatting, reading a configuration file, and writing a run log.

Document work is usually the richest hunting ground, because every document type repeats the same read, validate, and route steps. The walkthrough on building a document automation bot in A360 is a good place to spot those repeated blocks.

A: Abstract the inputs

For the block you picked, separate what changes from what stays the same. In a login routine, the URL and the credential reference change. The sequence of clicks does not.

Everything that changes becomes a variable in the child bot, created with the “Use as input” check box selected. Everything that stays the same gets hard coded inside the child bot, where it only exists once. Values that need to travel back out to the parent get the “Use as output” check box. A variable that does both gets both boxes.

Credentials never become a plain input. Pass a credential reference and let the vault resolve it, the pattern I walked through in the post on the Credential Vault for bot logins.

R: Rename for the shelf

A reusable bot nobody can find is not reusable. Name the child bot for what it does, not for the project it came from. “VendorPortal_Login” works. “ACME_Report_Bot_v3_FINAL” does not.

Automation Anywhere’s documentation recommends a variable naming standard with a prefix for scope: i for an input variable, o for an output variable, and io for a variable that is both. So the login URL input becomes iStrPortalUrl and the returned status becomes oStrSessionStatus. Six months from now that prefix is the only thing telling you which variables the parent is expected to fill.

One naming rule bites people: Control Room bot paths are case sensitive. A path like Bots/Shared/VendorPortal_Login will not resolve if you type the folder in lower case.

T: Test in isolation

Run the child bot by itself before any parent touches it. Feed it sample values by hand and confirm three things: it succeeds on good input, it fails loudly on bad input, and it returns the output you expect.

That middle one is the one builders skip. A child bot that swallows an error and returns an empty string will take down every parent that calls it, and the failure will surface far away from the actual problem. Give the child bot its own error handling so it reports its own failure. The post on Automation Anywhere error handling covers the specific blocks for that.

S: Store and document

Put the child bot in one folder reserved for shared logic. Then write two lines next to it: what it does, and what each input expects. Two lines, not a document nobody opens.

How the Run action actually passes values

Here is the sequence, for a child bot that takes one string in and returns one string out.

1. In the child bot, open the Variables panel and click Create variable. Set the type, name it, select the “Use as input” and “Use as output” check boxes as needed, then click Create.
2. In the parent bot, add the Task Bot action and then the Run action to the flow.
3. Set “Task Bot to run” to the Control Room file option, click Choose, browse to the folder, and select the child bot. A File variable or a path expression starting with Bots works here too.
4. Under Input values, select each child input and supply a value or a parent variable of the matching data type.
5. Under the option to save the outcome to a variable, either use Add variable mapping to connect each child output to a parent variable, or select Dictionary and read values back with the child variable name as the key.
6. Click Save and run the parent.

Two features in that dialog save real time. Quick map maps parent and child variables that share a name and data type, and creates parent variables for any child variables with no match. The Run action also carries repetition settings, so a child bot can run a set number of times or for a set number of hours.

Example scenario: three bots, one login

Example scenario, not a client result. You own three bots that each log into the same vendor portal and pull a different report.

Pattern spot finds the login block in all three. Abstract the inputs gives you iStrPortalUrl and a credential reference as inputs, and oStrSessionStatus as the output. Rename for the shelf gives you VendorPortal_Login in a shared folder. Test in isolation confirms it fails loudly on a bad credential instead of returning an empty status. Store and document puts two lines beside it.

Now each parent calls VendorPortal_Login with the Run action and checks oStrSessionStatus before continuing. When the portal adds its second authentication step, you fix one login, test one bot, and all three parents inherit the fix.

That is the whole return on this work. The build gets slightly slower and the maintenance gets dramatically cheaper. If maintenance is already your bottleneck, pair this with how you sequence the runs themselves, which I covered in the post on workload management queues.

Your action steps this week

1. Open your last five bots and list every block of steps that appears in three or more of them.
2. Pick the block that appears most often. Just one.
3. Build it as a standalone child bot with input and output variables, using the i, o, and io naming prefixes.
4. Test it alone against good input and bad input before any parent calls it.
5. Point one parent bot at it with the Run action, create the shared folder, and write the two lines of documentation. Leave the other parents alone until that one runs clean for a week.

Frequently asked questions

What are reusable bots in Automation Anywhere?

Reusable bots are child bots built to do one job well and called by other bots through the Run action in the Task Bot package. Instead of copying a login or a file archive routine into every bot that needs it, you build it once and every parent bot calls the same copy.

How do you pass a value from a parent bot to a child bot in Automation 360?

Create the variable in the child bot with the “Use as input” check box selected, then in the parent bot’s Run action supply a value or variable for that input under Input values. To get a value back, select the “Use as output” check box on the child variable and either map it directly to a parent variable or capture the result in a dictionary keyed by the child variable name.

Can a private bot call a bot in the public workspace?

No. The parent and child bots have to be in the same workspace. Check out or clone the public bot into your private workspace, build and test there, then check both bots into the public workspace together.

Do reusable bots make troubleshooting harder?

They can, if the child bot stays silent when it fails. A child bot with its own error handling and a clear output status makes troubleshooting easier, because the failure is reported at the step that failed instead of showing up as bad data three steps later in the parent.

Recap

Automation Anywhere reusable bots turn duplicated logic into one child bot that every parent calls. The PARTS Method is how you get there: Pattern spot the logic you have built three times, Abstract what changes into input and output variables, Rename it so you can find it on the shelf, Test it in isolation against good and bad input, then Store and document it in a shared folder.

The mechanics are the Run action, the “Use as input” and “Use as output” check boxes, Quick map for variables that already match, and a dictionary when you want several outputs back at once. Mind the workspace rule and the case sensitive paths and you will not fight the Control Room.

One reusable bot does not look like much. Twenty of them is the difference between a builder who dreads a platform change and a builder who ships the fix in an afternoon. Systems win, not effort.

If this is the kind of build detail you want in your inbox, subscribe to the blog and follow along.

References

Automation Anywhere. (n.d.). Using the Run action. Automation Anywhere Documentation. Retrieved October 27, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/aae-client/bot-creator/commands/using-the-run-action.html

Automation Anywhere. (n.d.). Example of passing a value between bots. Automation Anywhere Documentation. Retrieved October 27, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/aae-client/bot-creator/commands/example-cloud-dictionary.html

Automation Anywhere. (n.d.). Your variables (user-defined). Automation Anywhere Documentation. Retrieved October 27, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/aae-client/bot-creator/using-variables/cloud-user-local-variables.html