Hi John, Armando,
I have previous experience with both setups of teams altering the standard objects provided or creating a second bespoke 'extended' object. I have also worked with teams in that second option John listed. In the team that used option 2 (one where you didn't mix objects in a process) this lead to a lot more headaches than we had anticipated as it encouraged developers who thought they needed bespoke actions more than they really did, they ended up creating plethora of extended objects for various VBO's and having them related to specific applications work which meant a lot of work was duplicated and it was difficult to find anything useful or unique among them when you needed to. For example using a bespoke VBA sub to send an email via outlook was in 2 separate objects, there was one more action that sent a mail via outlook in vb code INSIDE and object dealing with 'Excel vbo extended' tools. This practice led developers down a path of creating extended functions to suit the projects they were on and when an object didn't fit heir needs fully they felt fully justified to make more extended objects to do what they needed. The real crux of that problem came down to not creating a team wide ethic that everyone was aware of whereby explicit rules were not conveyed to everyone stating not to make a million extended objects. I would not encourage anyone to go down the route of creating multiple extended objects unless they put proper criteria on why and when you make them without proper reviews on what functionality already exists in other objects. How you implement that in a blueprism environment is up to the team to create. Everyone will do it differently.
The other scenario of only using one object and not the other led to one complication in a team where someone had created an entire project and released it to prod and it was running smoothly but the a CR came in and some bespoke code had to be made to run it and ended up going in the extended piece so both object ended up being in the process without complication in the end but the far reaching affect was it created an ethos whereby nobody ever used the basic object anymore for any process ever to avoid this complication. From what I remember 3 of the main processes in Live uses the basic Excel VBO but every other process uses the 'extended' one which has caused the 'extended' object to become quite bloated (not the correct word because every action is important, they're not just waste) with quite a lot of bespoke actions, circa 50-60.
Ultimately whatever way you would like to create extended objects in blueprism the main problems you will face will come down to how you manage change management in the future if one object becomes large and super important for every running process in the team or how you manage functionality that exists and how the team creates more functionality to add into the code base. In my experience having the one extended object that was large worked out best as the team wrote good documentation on everything (which was a team wide enforced action) and there were some long time devs who were 'responsible' for the object as it had become a core piece for prod systems which meant it didn't get abused by new team members try to ad-hoc some code in that would wreck something downstream.
