UiPath Integrations

The UiPath Integrations Guide

Welcome to the UiPath Integrations guide. You will find comprehensive guides and documentation to help you start working with UiPath Integrations, as well as support if you get stuck.

In order to download the solutions mentioned here please visit the official UiPath Go! Marketplace here.

*Note that only integrations built in-house at UiPath are detailed below. For a complete list of UiPath's technology partners, see here.

QA Guidelines

All partner activities to be published on Go! marketplace must pass through security and functionality testing. To support and speed up the QA testing process for your custom activities, the following guidelines are recommended.

Prerequisites

  • User documentation and help (if applicable) should be complete and provided at the time of publication.
  • The documentation should be context-sensitive and explain how to achieve common tasks.
  • Both NuGet Package and Source Code solution must be provided at publication in order to complete Legal and Security review.
  • If 3rd party software is used (integration), a sandbox environment should be provided.
  • Test evidence should be provided by Technology Partner.

Packages

  • Package descriptions should be present and explain the purpose of the package.
  • External libraries should not be built in but referenced.
  • All dependencies should be properly listed in the NuGet package.
  • Licenses should be present in the package description.
  • Compatibility: packages can be installed and run properly on all supported version of our system.
  • Activities must be able to run from both Studio and Orchestrator.

Activities pane

  • Activities that are not created by UiPath should not use the UiPath namespace.
  • Namespace should respect the guidelines.
  • All activities should have short descriptions of their functionality on mouse hover **.
  • Activities names should be properly displayed **.

Designer pane

  • If activities are meant to be used in a scope but are not, they should prompt validation message **.
  • Mandatory fields should prompt a validation message if they are not or improperly used **.
  • All validation messages should be informative and user friendly.
  • Display names should never be cropped **.
  • Activities icons should be the same as the ones from the Activities pane.
  • If applicable, the properties names should not be cropped **.
  • If wizards are used, their functionality should never be able to output an invalid result.
  • If the activity features the minimize button, it should.
  • When the activity is highlighted, the F1 key should take you to the proper Help page

Properties

  • Same as Designer pane where applicable.
  • All properties (except legacy WWF) should have descriptions on mouse hover **.
  • Keep properties organized in the proper categories.

General

  • Be consistent! Consistency is key to quality.
  • If custom classes are used, make sure that the public methods and properties are documented.
  • Never assume that the end user has the same understanding about your target system, so make sure that the activities are user friendly and easy to use!
  • Make sure that there are no inconsistencies between the activity pack you want to publish and the documentation provided for it.

** Conditions should be met on all languages if localization is implemented.

Updated 3 months ago


QA Guidelines


Suggested Edits are limited on API Reference Pages

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