Related Posts
Additional Posts in Robotic Process Automation (RPA)
Any good book recommendations?
Who wants to be a millionaire?
Worst consulting company to work for ?
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.



One process as per UiPath definition per repo. I have seen complex repos (5-10 branches) and easy repos (2-3 branches). I prefer the latter, bc it fits in nicely with our deployment chain and way of working.
So usually you would have one repo per actual (sub-) business process, that is being automated.
In case of e.g. Worker-Dispatcher scenarios, you would of course have two repos. One for worker, one for either specialized dispatcher or global dispatcher, that handles multiple business processes (new branch —> develop —> finds its way back to prod).
We usually organize Projects per CoE. This comes with multiple advantages and disadvantages, but IMO advantages overweigh.
At scale, we also created a project for reusable components, that all CoE hubs were a part of, so that they could contribute. Here we would also share common best-practices, such as workflow analyzer templates, .gitignore, PDD/SDD etc. and other configuration files..
All of this is 100% subject to client environment. Some of the things mentioned above, we have also realized on network drives, Confluence etc. - whatever aligns best with client culture tbh..
Thanks- that helps. I’m inclined to keep it simple too so our client developers don’t get twisted up.
Anyone with a useful comment and experience with UiPath at scale?