Limit of Actions of Capture Process


Hello UiPath Task Capture Team,
at first thank you for this great tool, it works without any problems and it is very easy to use. :+1:

In UiPath Academy in the RPA Testing course I saw this:

RPA Development is equal to Software Development. Yes, this is a very good and realistic approach. In Software Development we have a lot of rules for “good” coding, e.g. KISS = Keep It Simple and Small. In this context for example we defined a limit for a the maximum count of code lines in a module. In our case between 150 and 250 lines of code (LOC). This is how you keep track of things.

In UiPath Academy course about Task Capture I read in the section Using Capture Process: " To generate an informative Process Definition Document , it is recommend not to exceed 500 actions per document."

Don’t you think that the limit of 500 is basically too much?

I tried it with a business process from my colleague with 136 actions in 22 windows. It was very difficult. In my opinion is a less limit of actions better. Why was the limit set so high? In your experience, which limit has worked best?

Thanks and best regards

Hi @StefanSchnell,

Apologies for the late response and thanks a lot for sharing this feedback and really reasonable points! The thing is that we’ve received a lot of reports from customers who had recorded the 700-1000 actions in 1 document. As a result, they encountered some sort of issues with the application such as lower UI performance quality and export errors. And that is quite expected actually as the application consumes memory resources to process and render all the images and the PDD file for 1000 images can not be created properly. The main reason this situation happens is in a misunderstanding of the application purpose, in some cases capturing of really huge processes and generating screenshot for every action.

To sum up, we decided to resolve this issue by letting users know about the number of actions we recommend not to exceed in order to generate informative, clear documentation and not get into unexpected behaviour :slight_smile: so answering your question ‘why the limit set so high’ - it’s because that’s some sort of starting point when let’s say ‘things may go wrong’. We expect that the users won’t get to it but if for some reason they need to capture a lot of actions then we want to inform them about that recommended limit point. And a minor spoiler about the upcoming 20.10 release - we added an in-built system of warnings when the 500 actions limit is reached, meaning that users will be notified about this during their interaction with the app. Anyway, if we’ll get more data and feedback about this number being too high, we’ll definitely change it.

Hope that answers your question. If there is any more feedback on a product or Academy course that you would like to share, I’d love to hear that :slight_smile:

Kind regards,



Hello Anna,

thank you very much for your detailed reply. :+1:

Great to hear that you implement a warning if 500 actions be exceeded. :slightly_smiling_face:

However, my question was less about the technical necessity and more focused on another aspect: Do business processes with more than 250 activities make sense at all?

In my environment I observe that complex processes for experts are difficult to automate. This shows the need to break down the business process into smaller units, with a smaller number of activities. These smaller units are easier to understand, easier to automate, easier to reuse and easier to handle the support and maintenance.

In my opinion we shouldn’t make the same mistake as when introducing ERP systems, to believe that technic is only good if it unconditionally submits to the business requirements. We must have the strength to see business processes from a different perspective, e.g. botability in combination with usability. Here, so my thoughts, we can adopt many rules for RPA, that have been consolidated in the programming. Your Workflow Analyzer goes in this direction. Maybe we will find some business rules there in the future, ST-BUS-001 or ST-MRD-018 like: To Many Activities in the Workflow. :slightly_smiling_face:

What do you think about this approach?
What is your experience how to handle business processes which involves many activities?

Thanks and best regards