Standards for Quality Content

Identifying the Use Case

The ideal use case for a ready-to-go automation is the attended automation processes that empowers each employee of an organization or a department to benefit from that automation.

Before zeroing on a particular use case, the developer should ask:

whether it would enable employees to delegate tasks they do each day to their robot - like schedule meetings, perform research and run reports, or analyze, manage, and maintain data.
whether it would give employees easy access to automation.

A typical example of such a process is a work productivity-related use cases in which an employee can trigger an attended robot using Assistant that will quickly prompt him with a form regarding meeting attendees, description, and time constraints. The robot takes this information and automatically compares options across invitees and meeting room calendars. The meeting day, time, and room options are then presented for the final validation by the user, and when confirmed, the robot sends out meeting invitations.

Recommendations for High Business Value

A use case that can run with general-purpose software such as MS Office, Adobe Acrobat Reader, Google Chrome, etc. is highly recommended since if it works with rarely used software then maybe only limited end-users would be able to reap its benefits.
If the automation demands an unusually high need of training to configure or use it then it would be a turn-off for the citizen developer to run it even once. There are high chances that another category such as Custom Activity, Solution, or Tools is potentially better suited to develop such a use case.
The use case should be universal and scalable. For instance, consider a ready-to-go automation that performs auto-login for daily used applications. There will be a limited advantage if the scope is kept restricted to only one or two applications. Hence it should either provide auto-login for more applications or there should be room to add more applications.

Developing the Automation

As a general rule, attended automation processes are fit to be run using Assistant. These processes should be designed so that they are small, fragmented, and can run with human supervision.

The Naming of the Ready-to-go Automation

While developing the process for a ready-to-go automation through UiPath Studio, the “Name” and “Description” of the project are of utmost importance. Each ready-to-go automation:
1. Should have “Name” starting with an action word or a verb. It should be descriptive so that it is easy for the users to understand the value right away.
2. Should have a relevant and concise “Description” of the functionality.
3. While developing the automation, the “Name” and “Description” can be entered through the “Project Settings” wizard in the UiPath Studio as shown below.
  
  Important:
  For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the UiPath products that are used in the automation or that are compatible with your automation, and the role that they play.
  
  Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on the UiPath Marketplace without express authorization from the third party.

Configuration and Startup

At the first run, the ready-to-go automation should display a “Startup Info” screen that suggests to users what to expect from this automation, mentions any pre-requisites before running the automation, and provides instructions for use.

Some attended automation processes run in the same way for everybody i.e. when the user clicks Start in the Assistant, the pre-defined steps are carried out without any variations. But in other cases, the way a process runs depends on parameters that are unique for the user or the context, such as email address, location of the folder, or a message string. In such cases, the process should be built by the developer in UiPath Studio with arguments or customizable input fields.
The configuration details that do not generally change for the users on a machine where the ready-to-go automation runs e.g. Email server, Port, File Path, etc. should be available as arguments to Assistant in the “Show Process Details” screen.
UiPath Assistant can display only the following argument types in the “Show Process Details” screen, hence if there is a requirement to pass any other type as an argument, then a form can be used for this purpose:
- Int32 - enter a number.
- String - enter text.
- Boolean - select or clear a checkbox.
- DateTime - pick a date or time.
Passwords or sensitive information should not be exposed or recorded by the workflow.

Providing the Status of the Execution

The interim status of execution of the ready-to-go automation should be conveyed on the screen through callouts, auto-closing message box or panels at the corner of the screen. This window should stay on top of the screen while the automation is in progress. It should provide short update messages or a Progress Bar to the user interacting with the Assistant.

Implement exception handling so that users receive meaningful messages when errors occur.
If the outcome of the execution is an output text then it should be displayed in a message box or Form to the end-user as a copiable string.
- For instance, the following listing Shorten my URL link - RPA Component | UiPath Marketplace generates the output that can be copied for further use.
Consider another listing Get a full path to my file - RPA Component | UiPath Marketplace. All output file paths are readable and copiable.

Publishing the Process

All ready-to-go automations for Assistant should be published as a NuGet package in UiPath Studio, as UiPath Assistant can consume only NuGet packages.

Best Practices

The NuGet package should contain the following metadata:

Tags: These are the relevant labels indicating the automation’s category/functionality.
License URL: Specify the license URL based on the type of license you selected for your automation.
License Acceptance check mark needs to be checked.
The name of the NuGet package should use the following convention: CompanyName.<PackageName>. If you are not affiliated with any company, you should use the following convention: <PackageName> .
The NuGet Version Starts from 0.0. Every change made before publishing increases its "decimal" index. For example, when we publish the first or a new version of NuGet, we consider it a MAJOR update, so it becomes 1.0.
UiPath tag name should not be present in the ID/ dlls.
If the content is localized, “Languages” should be specified, even if the field is marked as Optional.
In case there is a need to edit the metadata after publishing the automation to a NuGet, then it can be done using NuGet Package Explorer.
A user guide document containing the necessary information to run the automation should be provided. Here is a sample user guide template that can be downloaded and updated with the relevant information.
A video demo showing the execution of the automation with UiPath Studio or UiPath Assistant should be provided. The guidelines for creating the video can be found on this page.

Testing the NuGet With Assistant

To test whether a process developed using UiPath Studio is compatible with UiPath Assistant, the first step is to install the NuGet package of that process in the UiPath Assistant.

To install or update the NuGet package from the Orchestrator feed, the robot must be connected to the Orchestrator.
Once the NuGet package is installed successfully, the next step is to configure any customizable input fields.
If the process is developed in UiPath Studio with any arguments, the parameters must be supplied in the customizable input fields in UiPath Assistant. These fields can be accessed in Assistant by clicking on 'Show Process Details' in the three-dotted menu of the corresponding process.
The values supplied to these fields can be saved so that the next time the automation runs, these values are used.