When to Use UiPath Activities vs Built in application function

Help
, ,
1

Hello!
We are trying to find a best practice for when to use UiPath activities to automate something vs using already built in application functionality. We’re thinking it makes sense to use an already written excel macro (and just kick it off with UiPath) instead of re-writing the macro function in UiPath. Similarly, it seems to make more sense to do things like export a report/generate a pipeline of files, etc within an application, and then have UiPath pick up before/after to automate the task, but we can’t find a best practice sheet or anything like that, and want to be doing things the correct way from the onset. Can anyone weigh in regarding best practices? Thank you!

2

Hi,
according to my knowledge, uipath offers you various activities to utilize them to implement your logic.
you don’t need to implement anything right from the scratch if you already have workflows or custom activities already created.
you can just invoke them when ever required and use them in your workflow to implement your logic.

3

You are on the right track. You have to rely on your policies to establish best practices instead of fully relying on a software to dictate the terms.

Let us consider your approach to Macros. If you move the logic from the Macros into UiPath code, you are asking your RPA team to own the liability of the business logic entirely. If there are changes to the logic, the RPA team has to scramble to make changes to the Automation. But if the business owns the Macro, then your Robot can be a facilitator in executing it and the business can change the logic as long as the signature of the Macro does not change.

We have this system in place and it has worked very well for us.

Your teams can similarly make calls based upon the nature of the processes being automated to arrive at an agreed set of best practices.

Some of the other things we have in place are:

Policy for Attended Automations
Splitting your process into a series of Attended automations give business teams better control.

Example: If a business process has multiple human decision steps in between, then the mechanical parts of the process (such as running a macro) are moved into automations. This way the mechanical steps get divided into a series of automations, and the human owner runs each automation after checking the accuracy of work before running the next automations.

In some cases, we simply cannot automate end-to-end. For example, in one of our Invoice payment processes, the accounts manager removes customer records who just posted a payment from the downloaded Tableau Report that the Robot uses to send overdue payment notifications to customers. In some cases, the customer would’ve just replied to the accounts manager that they will be posting payments by EOD. Again, as a courtesy, an overdue email cannot be sent to them. These are purely human interactive decisions that cannot be fully automated in the near term.

Policy for Complete Automations
Is it faster to get data via an API call or by imitating a human user?
*Example: *
We have a CRM system that has a horrible API structure. If our back office has to build an API based process, they have to generate at least 6-7 API calls before they can generate a Report.
But if the RPA Team replicates human steps, it is just 3 steps - Login, select report and download
Finally, can the business team fall back on the past process if the automation fails. In case of the API process they can’t because they become IT dependent, but in case of the non-API approach they can!

General Infrastructure and Investments Viewpoint
Does the business team have a manual process that they are performing by working on an application that they have spent a lot of money to get up and running?
If yes, RPA can be used to automate that application preserving their expensive investments instead of totally moving that functionality out of that application into RPA