Hello,

I am new to Microvellum and throughout my on-boarding process and training program, my account manager and I have identified many instances of friction regarding implementing "construction customizations" into my product library.

We have different design paradigms, depending on the type of cabinet in question, and we have developed some joinery techniques over the years that influence our efficiency and productivity, as well as contribute to our brand identity.

One notable point of friction is that we use different joinery techniques to connect straps/stretchers with cabinet gables than we use to connect bottoms/decks with cabinet gables. Within product prompts, there isn't a way to distinguish between these joinery methods from what I understand. The solution is to customize cabinets and save them as new products, with new names to distinguish them from the base global library products.

The trouble is that the base global library products are updated from time to time with library updates/database updates and could have new product prompts, sub assemblies, etc added to them. Since our solution to the previous problem is to create discrete entities as new products, they will be unaffected by any new library updates rolled out by Microvellum. This is both a good thing and a bad thing, as our customizations are "unharmed" during updates, but our cabinets will not have access to any new features and must be rebuilt each time we would want to include any changes from Microvellum library updates.

My account manager has said that the idea of cabinet carcasses being re-coded as sub assemblies would completely alleviate all of these issues, as we could keep the "database default cabinet" and simply "branch out from there" using sub assemblies as children of the parent cabinet. This would allow customizations to remain unique to sub assemblies while allowing for database updates to correctly make changes to the "default cabinet" as features roll out.

It seems that right now, we're attempting to use "work-arounds" to side step some limitations, while adding a lot more work for both our account manager and myself, and deepening the divide between Microvellum as a default software interface and our customizations.

We would prefer for my above example and other customizations to remain "trade secrets" as opposed to features implemented for everyone. The sub assembly framework would allow for this to be the case, and add a feature that would allow many other businesses to do customizations to cabinet joinery and other aspects, while retaining the ability to use new library updates without additional steps (and the ability to forget to update all discrete products).

The cabinet carcass assembly would cease to have any real data behind it and it would instead become a shell; within that shell, the sub assembly of the cabinet carcass would become the first layer of customization.

Please let me know if this is an unreasonable request. From what I understand, before the global unification of the databases, the "American" version of Microvellum had this sub assembly nature by default and was the foundation upon which all cabinets were coded and built.