Last time, we learnt how to create and customize forms, and today, we will learn how to add rules to our forms.

Why add rules?

Because RPA is rule-based (get it?).

No but seriously, why bother adding rules?

I Need an Answer

If you’ve explored forms before, then you’d have noticed that there are validations you can enable, such as making fields required, disabling fields just to name a few (since those are the only ones I can remember).

In addition to that, you may also develop logical checks within the TaskBot using our trusty If , ElseIf and Else Actions.

The conditions are validated by retrieving data from the form before setting values back to it, or highlighting elements to notify the end user in case anything goes wrong.

Waaait, Where Did the TaskBot Come From?

Well you see,

When a Developer and a Control Room love each other very much, they g-

HOLD IT RIGHT THERE, That is Not What I Meant.

Ohh you meant to ask why we are using TaskBots.

That is because only TaskBots can breathe life into forms. Forms can’t act on their own because the whole point of using forms is so that the TaskBot can “communicate” with the end user.

The form behaves mostly as a medium of exchange.

We will explore how to connect TaskBots with Forms in the next article, because I don’t want to throw everything at you all at once and scare you off.

Now Back to “Why Rules?”

That is because it reduces complexity.

Imagine having to maintain each and every check and operation within the TaskBot.

Traumatic, isn’t it?

This is what the team over at Automation Anywhere realized as well, and decided to compartmentalize the operations to make it easier for developers like you and me to work with Forms without having to run into any panic attacks.

The bot should only trigger the form and handle inputs, instead of having to handle each and every aspect of the form.

It shouldn’t have to validate data as it is being entered into the form, such as verifying whether the field contains the right values or no values, or highlight elements if a certain operation has been performed (such as a button click) etc.

Thanks to Rules, we can avoid mashing operations together and separate them out.

If a validation fails, there isn’t a need to investigate the bot. The section devoted to rules is all we have to look at.

Example Time!

We will create two forms and compare the rule based form with the non-rule based form.

So lets create our first form!

Now that we have created our first form, we can now start adding the form rules.

Before that, let you tell you a little about the form we are about to design.

There are five options out of which only one is correct.

I was thinking of turning this into a 5-10 question long quiz section, but then decided against it.

The Text Area Element will tell you whether the option you have selected is right or not.

Now lets get back to creating the rules one by one.

What’s the Fifth One?

And with that, we have created our first rule based Form!

We will create the same form but without the Rules, and it can be done by cloning it and deleting the Rules.

I have developed the bots for triggering each form, which we will explore next week.

Lets see what it looks like after triggering it.

The rules work as you click on each option i.e., the bot plays no role here.

Lets have a look at the workflow – now remember, the whole point of adding rules is to reduce the complexity of the bot responsible for triggering the form.

We will look at both workflows side by side and I want you to tell me which workflow triggers which bot.

Its pretty obvious which workflow represents which form. The workflow is much easier on the eye and to debug which is always a plus point for developers like you and I.

I would recommend playing around with it on your own, instead of just reading through this.

I didn’t learn how to use this by merely browsing through the documentation, but by putting theory into practice.

.

.

.

You’re still here?

Then you might be looking for the last edition in this series.