Hi,
What you mentioned around having temporary processes and objects and pasting into a master is typically how I've always done it in the past, sticking with the 'out of the box' approach.
If you are going to build like this frequently, I'd recommend breaking the objects required for the build down (potentially per application if there are multiple) and assigning different team members an application each. If the applications don't break down as a 1-to-1 per team member or the amount of steps to build in each application required is not evenly split (very much a perfect world scenario!). I'd split the applications down further into sections (screens for example) and the functionality assigned to those (providing you are working from the basis of an object-per-screen methodology) and assign team members to each. This can make the need for temporary objects and pasting into a master lessen for portions of a build or the entirety. With a process it is obviously a little more difficult and we try to tend to keep most of the actual process build primarily with one person to negate this, but if not possible or it is a very big process. I'd take the same approach with the process e.g. splitting it down into multiple key sections covering the key steps in the process and have people independently work on each before having someone bring it all together in the master process.
Providing you haven't ran any of these temporary processes or objects from control room it should then be fairly straightforward to delete them after they have served their purpose. If you have any issues deleting them, search the community for the error you are presented with and you should find a solution as I imagine it's a fairly common thing, if not reply here and I can assist.
🙂------------------------------
Adam Greenwood
Automation Development Team Lead
Blue Prism
------------------------------
