AA: Dictionary Variable Is a Little Special

Dictionaries often come in handy when housing or grouping similar data. Sure, you have Lists, but they merely “house” data.

Read on and you will understand what I meant by that.

Lets Talk About Houses

Lists provide their tenants with full access. They can occupy any room they please, at any given time but their “occupation” is relatively fixed. Once they enter a room, they have a tendency to remain there.

Put it another way, there are no walls or doors to separate them from each other, so they all live in one massive studio apartment, which sucks for the landlord.

How are you going to collect their rent?

Which is why the developers decided it was time for an upgrade.

Introducing, Keys and Values

While Lists are used to store data, the Dictionary was created to store grouped data.

Sure, you may create a List of Lists, but that leads to a lot of unnecessary complexity.

Hence the inauguration of the Dictionary Hotel Suite.

The Rooms Are a Little “Unique”

Each apartment within the Dictionary Hotel Suite comes with its own access key. No two rooms will contain the same key, which means your guests have been allocated individual rooms.

They have their privacy and it becomes easier for us to “call” them out when required.

Lists merely offer their tenants with room numbers, which tells us nothing about the tenant itself. To call out the tenant we wish to interact with, we have to keep track of the order in which tenants were brought into the apartment.

We only refer to tenants by their numbers, when said “tenants” are in a prison.

You can give the key any name you like, as long as it makes sense to you and to the end user.

It becomes much easier to pull out data you wish to interact with, because the key itself behaves as an indicator of what it will contain, as opposed to keeping track of the indexes of each item in a list.

If Derrick Thomas was allocated to Room 101, he gets to keep its key.

$DictionaryVariable{Room 101}$ -> “Derrick Thomas”

A realistic example of this would be storing data from a configuration file.

If you store the company URL into a Dictionary, this is what it will look like.

$DictionaryVariable{CompanyURL}$ -> “https://companyurl.com/”

You will understand from the Key itself, that it contains a URL.

That’s Alright I Guess, But What is “Special” About It?

Automation Anywhere has taken it to the next level by creating the Key and Value pairs for us – in certain cases.

What? How Is That Possible?

A handful of Loop Action Iterators accept the Dictionary Variable as an Input. The loop stores whatever it is looping through into our Dictionary dynamically, which won’t make much sense right now since we haven’t seen it action yet.

So let’s see it in action.

Loop: File in Folder

During runtime, the dictionary is populated with the two Key-Value pairs:


But you have to be careful here.

You can’t simple plug in:


And expect the bot to interact with the file. It won’t be able to find the file unless you provide its extension.


But that won’t work either.

You have to pass in the Full File Path like so:


Now you are set.

Also, you have the option of assigning the keys to multiple variables to the loop, as shown in the screenshot below:

There isn’t a need then, to add a Dictionary to the Loop, but it operates on the same logic(Splitting the File details into Key-Value Pairs)

PDF: Get Property

This one isn’t assigned to a loop.

Its an Action that gets the details of a given PDF as shown below:


This is really useful when you require details present inside the PDF which can’t be easily retrieved by opening the PDF. It is hidden away in the options, so this set of Keys help us a lot.

Loop: For Each Mail in Mail Box

This is by far the largest set of Key-Value pairs that is auto-generated during runtime.

Here, have a look:


The Email Subject and Email Message are what I deal with most, so I haven’t had a chance to use the others.

Maybe you will get a chance to use them.

In Conclusion

The team over at Automation Anywhere has been working diligently, to make our work as RPA developers a lot easier.

They are slowly adding more new and exciting features, that not only improves end user satisfaction, but also for developers like us tasked with developing automations.

You will run into all sorts of interesting solutions, and not to mention, interesting errors, but that is what makes it “interesting”.

Some may substitute “interesting” for “nerve wracking”, but that’s just part and parcel of working in the IT industry.

RPA is a great area to work in, and the headaches aren’t as intense as they are when you work as a programmer.

I will write more on RPA, and why investing in this area is worth the effort.

Leave a Comment