Marketplace
latest
false
- Release Notes
- Overview
- Getting Started
- Marketplace Vendors
- Marketplace Customers
- Publishing Guidelines
- Publishing Guidelines for Ready-to-go Automations
- Security & IP Protection
- Other UiPath Listings
- Node-RED
- Setup
- Teams
- Microsoft Teams Scope
- Create Team
- Create Team From Group
- Get Team
- Get Teams
- Channels
- Create Channel
- Delete Channel
- Get Channel
- Get Channels
- Update Channel
- Chats
- Get Chat
- Get Chats
- Get Chat Members
- Messages
- Get Message
- Get Messages
- Get Message Replies
- Reply To Message
- Send Message
- Events
- Create Event
- Delete Event
- Get Event
- Get Events
- Users
- Get User Presence
- How It Works
- Technical References
- Get Started
- About
- Setup
- Technical References
- Azure Form Recognizer Scope
- Activities
- Analyze Form
- Analyze Form Async
- Get Analyze Form Result
- Analyze Receipt
- Analyze Receipt Async
- Get Analyze Receipt Result
- Analyze Layout
- Analyze Layout Async
- Get Analyze Layout Result
- Train Model
- Get Models
- Get Model Keys
- Get Model Info
- Delete Model
- Connectors
- How to Create Activities
- Build Your Integration
Marketplace User Guide
Last updated Apr 16, 2024
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.
- 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.
- 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 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 **.
- 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
- Same as Designer pane where applicable.
- All properties (except legacy WWF) should have descriptions on mouse hover **.
- Keep properties organized in the proper categories.
- 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.
