The 2022 Internship ended a couple weeks ago, after 45 days of hard work and research from the participants. It was quite a journey, with plenty of growth opportunities – both for the interns and for us.

We’re glad to conclude that everyone involved had their share of Development, be it RPA or personal development. 🙂

Out of 100+ internship applicants, 11 made it with the final project by submitting a fully-functional, end-to-end automation they have designed and built on the UiPath Platform. Congratulations are in order to the below finalists, for their patience, dedication and, above all, willingness to learn (alphabetically ordered):

• Anjali Dahiya – India, with ”RPAStars”, demonstrating a lot of technical know-how by completing difficult automation challenges. 
• Devendra Singh – India, with ”Supply Chain Bot” – an automated assistant that speeds things up in handling supply chain issues. 
• Garima Karve – India, with “Insurance Bot”, a robot that helps people gather insurance related data in a quick way that is easy to access.
• Getheswari D – India, with “HR Employee Onboarding”, an automation suitable for the HR Department, that automates the process of enrolling a new employee into the company 
• Mohammed Waseem – India, with “Balance Sheet Account Reconciliation”, automating the process of verifying balance sheet data and informing the business user of any errors found. 
• Mohanraam Pillai – India, with “Train Status”, a very useful automation for anyone that rides the train, providing the user with useful data related to the train they are about to board.
• Sameer Adhikari – USA, with “RealEstateBot” – a bot that searches different real estate websites with the purpose of finding advantageous locations to rent/buy.
• Sawaira Nawaz – Pakistan, with “PakWheels”, a useful automation that searches different car-selling websites and returns the results in an easy-to-read format.
• Tache Stefan – Romania, with “PartsAdvisor” – an automation that could eventually become a standalone product. It searches the web for consumables for any vehicle and returns the best deals in a very easy to read format.
• Tijani Abdullah – Nigeria, with “AutomationChallenge” – an automation that goes through a series of RPA-Related challenges and solves them in an efficient manner.
• Tejaswini Yadav – India, with “WeatherBot”, an automation that provides useful weather-related data to the user.
• Yunus Tijani – Nigeria, with “Invoice Processing Bot”, an automation that automates the data extraction and data entry from different invoice types.

If you’re interested in our future Internship Programs, feel free to follow us on LinkedIn or stay tuned on our blog – more is yet to come with the best project submissions and feedback from the participants!

Time. To learn.

Our last internship was a great success having over 80 enrolled interns from all over the world. We had participants from Romania, USA, UK, Argentina, Spain, India and Nigeria that worked with us on building their UiPath Automations. Most of them continued as RPA Developers in some of the top companies in their country (and are still active).

We are looking for the next brave and ambitious interns that are willing to learn UiPath and develop automations together with us.

The internship will happen online and it is open for everybody, no matter where they are physically located. Our goal with this internship is to grow the RPA community by providing anyone that is interested in becoming a RPA Developer in UiPath with the proper guidance from a team of people that have been doing this successfully for years.

Here is what Ovais says about our internship:

“My experience with Aggranda as an RPA Intern has been amazing. The hands-on experience has helped me secure my job as a full time RPA Consultant at the largest IT company from Pakistan. For someone who is new to RPA, this experience is priceless. They taught me tips and tricks regarding UiPath and shown that they really care about their Intern’s success.”

Here is what Meena says about our internship:

“At the time of completion of Advanced UiPath RPA developer certification, the internship at Aggranda has given me an opportunity to apply my knowledge and explore more about UiPath and RPA. It helped me to gain knowledge about RPA in a practical way. The experience of RPA intern at Aggranda led me to get my full time job as an RPA developer. Thanks Aggranda, for providing this opportunity!”

Internship structure

The internship is unpaid and will have a total duration of 6 weeks. Every week there will be a 2 to 3 hours meeting with the interns and two Senior Developers from our team. During these meetings all interns will get the guidance and training necessary in order to successfully develop an end-to-end UiPath Automation project at a high quality standard. You will learn from real life use-cases that we faced during our automation journey, along with the best practices and tips & tricks that will be valuable throughout your own journey in automation. 

Benefits

• Get help in developing an end-to-end fully functional UiPath Software Robot
• Learn from our best RPA Developers & Business Analysts
• Accelerated learning curve by practicing
• Experience at Aggranda as intern
• Personalized Certificate of Completion
• Presentation on the Aggranda Blog along with contact details (LinkedIn, Email Address)
• Exposure to other RPA Companies
• Recommendation Letter
• Possibility to join Aggranda

Requirements

• UiPath Academy – RPA Starter – Fully Completed
• UiPath Academy – RPA Developer Foundation – Fully Completed
• UiPath Academy – RPA Developer Advanced – Optional, Highly Recommended
• English Speaking
• Self Learning
• Being ambitious, motivated and curious
• Problem Solving
• Self Learning – no, it’s not added twice by mistake – it’s just THAT important 🙂

Location: Anywhere

Application Deadline: 30th June 2022

Internship period: 13th July 2022 – 12th August 2022

Interested? Apply here

The goal for each intern is to build a working software robot using UiPath and have an amazing learning experience while doing this 🙂

During the processing, when an error occurs an exception is thrown. Those exceptions can be:
– Automatically thrown by having the timeout of an activity expire without the activity actually executing (e.g.: the robot cannot click on a button)
– Intentionally thrown by the developer using the ‘Throw’ activity. The developer can choose when an exception should be thrown.
It is important for the developer to throw exceptions in cases in which having an automatically thrown exception can be misleading. A good example of this is the following: After logging into a website, the robot fails the first ‘Click’ that it should do. This is generally caused by the robot not actually successfully logging into the website. The developer should first check if the robot successfully logged in and, in the case in which the login failed, throw an exception with a representative message. If the exception is automatically thrown, the user will see a message like: “Click ‘ButtonName’ Button Failed.” However, if the exception is intentionally thrown by the developer, the message would be: “The robot failed to login into the ‘WebsiteName’ website.” You can already see how useful intentionally throwing exceptions can be towards helping the user understand the issue.

Simply raising the exceptions however, is not enough to notify the user. Next up we have to send the notification to the user, who in this case is the person in charge of running the robot and, sometimes, the developer or the maintenance team.
There are certain events that the user should always be notified of. The following cases are:
– If an exception was thrown during the ‘Init’ stage
– If an exception was thrown during the ‘Process’ stage
– The robot finished processing all of the items
Other than that, there are also some events that can be useful to notify the user about, but are not considered mandatory and their importance is determined on a project-by-project basis. These cases are:
– Exceptions thrown in the ‘Get Transaction Data’ stage
– Exceptions thrown in the ‘End’ stage

In the majority of cases, the best way to notify the user of a certain event is by sending an email. The developer has to create a ‘SendEmail’ workflow by themselves that uses the activities required to send emails to the user’s specific platform (e.g.: Outlook, Gmail). When working on the ‘SendEmail’ workflow, the developer should make sure to allow the addition of screenshots to the email through the use of arguments.
Having a screenshot added to the email can drastically reduce the time of figuring out the source of the problem. A workflow for taking a screenshot is present by default in the REFramework and its name is ‘TakeScreenshot’. To use it, simply invoke it wherever needed and provide a variable for the ‘screenshotPath’ argument. A great example of the impact that it can have is when a popup that was not encountered before suddenly appears during processing. Without a screenshot attached, the developer has to waste time and effortto reproduce the popup in order to understand the error. If the email contains a screenshot then the developer will be able to see the message of the popup and this will make the whole process of resolving the issue significantly faster.

Screenshots should only be sent in the case of SystemExceptions (ApplicationExceptions). In the case of BusinessRuleExceptions, adding a screenshot is not really of any use, although it doesn’t have downsides either.
The other component of the email, besides the attachments, is the body of the email itself. The best method to store and use the body of the email is to get it from the configuration file and have it contain placeholders for relevant data. Those placeholders will then be replaced with actual values when the value is sent to the ‘SendEmail’ workflow as an argument.

The body should also contain a ‘Exception Details’ section. This is generally dedicated to the developer/maintenance team and should contain exception-related data. This data is stored in the exception itself and the most relevant fields to add to the email body are ‘exception.Source’ and ‘exception.Message’.

Once we have a working ‘SendEmail’ workflow, all that is left to do is invoke the workflow wherever it is needed. Generally, there are three places in which the ‘SendEmail’ workflow should be invoked:

– Inside the transition from the ‘Init’ Stage to the ‘End’ stage, when a System Exception has occurred.
– Inside the ‘SetTransactionData’ workflow, on the ‘BusinessException’ and ‘SystemException’ branches
– Inside the ‘End’ stage, after closing all involved applications

The ‘SendEmail’ workflow should be preceded by the ‘TakeScreenshot’ workflow whenever attaching a screenshot to the email is relevant.

Following the information described in this post should provide any developer with a great, solid, and extremely useful emailing notification system.

That’s all there is to it! Best of luck!