Editor's note: At the time this post was originally written, there wasn't a way to build custom activities with ease while aligning with best practices. There is now - the UiPath Activity Creator extension for Microsoft Visual Studio.
This will take care of the 'plumbing' and allow you to build the entire structure you need, while setting the standard for all future custom activities. Take a look at this demo to see it in action or go straight to the written documentation.
There’s no doubt that Robotic Process Automation (RPA) is one of the fastest growing sectors right now. This means that, at the moment, a lot of developers are building and learning to automate things on the fly.
Therefore, since we know how much all developers love building unit tests and following best practices (let’s also not forget about writing documentation—it should definitely get an honorable mention here), I thought we should also have a short post about some of the best practices that should be followed when building custom activities for UiPath Studio, since they are the components on which every process automation is based.
What you need when developing a custom activity:
3. UiPath Studio: for testing your custom activity (Studio is available for the free Community Edition)
This post focuses on 7 best practices when building a custom activity, but for those of you looking for a complete guide on how to build a custom activity from scratch for UiPath Studio, check out this guide.
Also, if you want to start from an already existing template, my awesome colleagues from the Integrations team have built this easy-to-follow guide that will get you a custom activity in 5 minutes. I would also like to thank them for having these development guidelines that you should also check out (some of them are present in this article too).
This post is written for RPA developers who are already somewhat familiar with UiPath Studio, basic programming principles, etc. If you’re not there yet, don’t worry! You might find it more helpful to stop here, review Level 1 - Foundation Training in UiPath Academy, and then come back to this post.
7 best practices to know when building your custom activity
1. Programming best practices
- First things first—you are developing the custom activity using C# & the .NET environment. This means that everything that’s been written about best practices in programming applies! Yes, I know—it’s a lot of work and if you’re working on something more complex it’s going to become really tedious. All this is worth it, though, when you know that your Robot runs squeaky clean.
Some things I’ve seen worth noting are:
- Don’t forget to close those streams and resources when you don’t need them anymore—because we should collect our own garbage!
- Don’t just write all your code inside a method. Have SOLID principles!
- Use self-explanatory names for methods and variables (yep, still needs to be said).
- Make sure you validate all user inputs. Validate, validate, validate!
- And for those more complex projects—design patterns should be taken into account.
Oh, and don’t forget about source control—UiPath Studio is also integrated with Git. Even though it isn't specific to building custom activities, it’s worth noting that this awesome, sought-after integration now exists and you can manage your workflows easier!
2. Error handling
Even though we all like to add a generic Exception and use it for every type of exception, the practice of adding a generic Exception will surely backfire at a certain point! Using this practice combined with Console.Log or Console.Error is not exactly the approach that will yield a highly reusable component.
Make sure that you stop using these practices, even if they’re just for debugging. This will mean that a proper Try-Catch can then be implemented inside the Workflow and the Robot will be able to handle different situations better!
3. Design your custom activity: Windows Presentation Foundation
This is a reminder that custom activities can also have a design. This means that you can make it easier for the user to enter the variables and parameters from inside the Studio when using your activity through a user interface (UI). If you’ve tested different activities, you’re probably already aware of this.
Here are two good resources to check out:
- WF4 Custom Activity Designer
- How to create a Custom Activity Designer with Windows Workflow Foundation (WF4)
Well, now you know to keep this in mind when thinking about the types of inputs and outputs your custom activity will have—which brings me to the next best practice.
4. Parameterizing (yep, that’s a cool word!)
Most of the time your custom activity will need to receive some user input, process it, and then output a result. In the instances when this is not the case, the best practice is still to have at least one output parameter.
Through this parameter, you can let the user know if the operation has been executed successfully. It’s way easier to reuse a custom activity that outputs True/False, than an activity that doesn’t output anything when the activity has been executed successfully (and that just throws an error when it fails).
Parametrize and make a Robot happy!
5. Property names, categories, and descriptions
Since the user doesn’t see your source code, it’s important that the Properties panel for your custom activity has the right structure and functionalities. This can make the difference between someone using your activity for their Robots or closing it and searching for another similar one. Therefore, for your custom activity, make sure you:
- Add a description for each property/argument using [Description()].
- Similarly, use[Category(“”)] in order to separate visually the Input, Optional, and Output parameters inside the activity’s property pane.
- Add a description for each activity in the DesignerMetadata.cs file. This description will be visible when the users hover your activity in the Activities panel.
6. Best practices when creating the NuGet package—NuGet Metadata
Whew, you’re almost done! Once you have your Activity.dll, you will need to create a NuGet package, which is what UiPath Studio needs. When adding the metadata, I’ve noticed that some fields are really easy to forget about—we’re human, after all. The mandatory fields that UiPath Studio will look for and then display in the feed are:
- ID: please complete with the package name (which, for UiPath Go!, has to follow the publishing guidelines)
- Package version: so users know which version they’ve used before, in case of a breaking update (for those really, really rare occasions when you can’t assure backward compatibility)
- Description: when describing your component, always keep in mind that users will see it in the Go! Studio feed
- Tags: make sure these are relevant since searching in the feed is also based on them
- License URL
Optionally, you can also fill the fields for the Icon URL (make sure you don’t use a local path for it!) and the Language (if the component is localized).
For more details about these metadata fields, please check out the UiPath Go! Publishing guidelines.
7. Adding dependencies
A lot of the times we’ve seen external dependencies packaged inside the NuGet package. Don’t forget that since these are subject to change and can be linked separately, the best practice is to add them as dependencies for the NuGet package, and not as package contents!
Even though these 7 best practices for building your custom activity for UiPath Studio are just a small part of the best practices you need to pay attention to, your Robot is going to be happy that you follow them.
Oh, and you’ll also make your users happy and make it really easy for them to reuse your custom activity in their workflows. At the end of the day, let’s not forget that it’s about making users’ jobs easier—and their jobs are to build (awesome) Robots. :)
PS: If you respect all the best practices and submit your custom activity on Go!, you will be able to have it available directly in the UiPath Studio Go! feed just like this:
Do you know about UiPath Go!? On the Go! Marketplace, we welcome and accept all kinds of automation projects and components. You can see how bringing some awareness about best practices helps UiPath in curating all the submissions for Go! (yes, basically more work for the Robots and less of the repetitive tasks for us humans).
We encourage you to take a look over the Go! Marketplace and submit your component or, if you don’t have one yet, just head over to UiPath Connect! where you can submit all your ideas regarding Robots and automations. You can also find collaborators on Connect!