Subscribe

UiPath Marketplace

The UiPath Marketplace Guide

Standards for Quality Content

Identifying the use case

The ideal use case for pre-built 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 publisher should ask:

  • whether it would enable employees to delegate tasks they do each day to their robot - like taking action to 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 case 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 pre-built 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 smaller, fragmented, and can run with human supervision.

The naming of the Project

  • While developing the process for pre-built automation through UiPath Studio, the “Name” and “Description” of the project are of utmost importance. Each pre-built automation:
    a. 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.
    b. Should have a relevant and concise “Description” of the functionality.
    c. While developing the automation, the “Name” and “Description” can be entered through the “Project Settings” wizard in the UiPath Studio as shown below.

Configuration and Startup

At the first run, pre-built 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 pre-built 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 pre-built 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 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.

Publishing the process

All pre-built automation for Assistant should be published as a NuGet package in UiPath Studio. It is because UiPath Assistant can consume only a NuGet package.

Best Practices

The NuGet package should contain the following metadata:

  • Tags: These are the relevant labels indicating the component’s category/functionality
  • License URL: Please specify the license URL based on the type of license you selected for your component
  • License Acceptance check mark needs to be checked
  • The name of the NuGet package should use the following convention: CompanyName.. If you are not affiliated with any company, you should use the following convention:
  • 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. Here is a sample user guide template that can be downloaded and updated with the relevant information.
  • A video demo showing execution of automation with UiPath Studio or UiPath Assistant. 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, parameters must be supplied in the customizable input fields in UiPath Assistant. These fields can be accessed in the 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.

Updated 16 days ago


Standards for Quality Content


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.