Skip to main content

Note: All of this information is now available in the Nintex Help article found here: https://help.nintex.com/en-US/rpa/Actions/Unlock.htm

 

Intro

So you have a routine botflow that you want to run completely in the background, with no human touch to get it started? Sounds like a perfect candidate to run on a schedule, or in an “unattended” manner. Before we get into the weeds, let’s talk some basics.

 

The Basics of Attended vs Unattended

Typically, an initial deployment of a Nintex RPA botflow will involve a user opening Nintex Bot, maybe loading some data and logging into various systems and then finally clicking play to run the botflow. This might happen on an actual workstation/desktop/laptop but it could also happen in a virtual environment as well. This is what would be classified as an attended botflow, requiring a human touch to get it up and running.

 

A lot of people stop here. They’re perfectly OK with the amount of effort it takes to get this all setup and running. This is 100% fine, but in reality, stopping at this point cuts off the huge potential of Nintex RPA. What if the person responsible for running the botflows has a day off? What if they get really busy and forget to run it? What if they move on from the company? Why have such business critical processes depend on an individual when they could be running behind the scenes without worry.

 

An unattended botflow is what I would consider an evolution on the attended botflow. After you’ve done testing, putting it through its paces with an SME, and essentially ironed out all the kinks in the attended botflow, that would be an ideal time to begin the transition to an unattended state. As mentioned previously, an unattended botflow can run on a schedule or through various other triggers and can be setup in a way to run automatically without human intervention.

There are a few things to consider before deploying an unattended botflow, which I’ll highlight in a separate blog post later on, but the most important is using the Nintex RPA Unlocker capability.

 

What is the Nintex RPA Unlocker?

In order for Nintex RPA to run a botflow successfully, the machine (or Bot) it is running on must be unlocked. Normally, this might be an issue due to security concerns of always having a machine unlocked & readily available. However, with the Nintex RPA Unlocker, a botflow can unlock a Bot machine from the password input screen. This is going to be a critical first step in any unattended botflow. 

10202i07DACAC8F367B236.png

 

As you can imagine, though, there is quite a bit of setup required for the Nintex RPA Unlocker to work. We have a great article on our Help site that goes through everything, you can find it here: https://help.nintex.com/en-US/rpa/Actions/Unlock.htm

 

Using the Unlock Action

Now that all the setup is done and the requirements have been met, the next step is to actually put an Unlock action within your botflow.

 

The setup for this is fairly straight forward. You will need to first create a Credential that can be used within the Unlock action. This Credential should contain the password for the account that will be logged in when the unattended botflow runs.

10199i990E2C5A4AF31D36.png

With the Credential created, you can find the Unlock action under the Computer action category on the left hand side of Nintex Bot. It is the last action in this category (this may change in the future as more actions are added). Just select the Credential you’d like to use and confirm the password in the action builder, then click OK to save and create the action in your botflow.

10200i50CE4735064B60C3.png

Typically, you will want to use the Unlock action at the start of your botflow before anything else. If you want to be extra sure it is working, you can add an If action to check if the machine is locked or not. Using this you can setup a simple Label loop to keep trying the Unlock until it is successful (usually the first time, but redundancy doesn’t hurt).

10201iBAF48B6655240874.png

Another suggestion would be to have an Unlock action within your Error Task. With this, that would ensure the Bot is unlocked before any error corrections take place. This can help reduce errors reported due to the machine self-locking or timing out, etc.

To Wrap Up…

Using Nintex RPA Unlocker is really the first step in getting your botflows ready to run unattended. But it is the one step that is both the most important but also the most hidden, so to speak. This is a great feature available in Nintex RPA that I wanted to shed some light on. Keep your eyes peeled for my next post about other steps to take and considerations to make before deploying your first unattended botflow.

 

Let me know if there are any questions or points of clarification to make! If you this was helpful, spread the word! Sharing my blog with your colleagues would mean the world to me, and any Kudos you give are much appreciated.

 

Thanks,

John.

Be the first to reply!

Reply