UiPath Integrations

QA Guidelines

All partner activities to be published on Go! marketplace need to pass through security and functionality testing. To support and speed up the QA testing process for the Partners’ custom activities is recommended to follow the guidelines presented below.

Prerequisites

  • The user documentation and help (if applicable) should be complete.
  • The documentation should be context sensitive and explain how to achieve common tasks.
  • Both NuGet Package and Source Code solution should be provided.
  • If 3rd party software is used (integration), 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.


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.