The most important part of the options' settings is Field slug.
The two most essential concepts:
1) slugs are unique across the site; you cannot have two options with the same name; when you try to save a new option with the existing slug name, it will display the error and will suggest an alternative name;
2) you have to save option with a new slug to DB to actually make this option operational;
To be operational, options must be saved with 'Save to DB' checkbox. It means that options' settings are stored in data base (DB). When you use a certain option in this or that product you create options' instances.
By doing sync/unsync you connect/disconnect an instance to saved to DB copy of settings of a certain option. When the option is synced and you make any changes in its settings and save them with 'save to DB' checkbox this operation actually overwrites option's data. Individual option's data ONLY! Such operation does not modify any other instances of same option in any other products! When you go to another product and open its builder mode and reviewing its builder content - you are reviewing option's instance data. It may not be the same as the data stored in DB for this option! So, by changing settings and saving them with 'save to DB' you actually overwrite this option and all other instances in any other products may become broken!
You may ask "why you make it like that then?". First, to let users re-use same option again and again without duplication same objects in DB. When you just re-use same option and do not modify it at all - it works perfectly well! Second, to actually give a possibility to change the appearance of the option's instance and re-use same option again and again. If you need to change the way how the option looks like in particular product - change its settings which ARE NOT marked with a yellow triangle and save WITHOUT 'save to DB?' checkbox. And again - you are safe by doing so.
1) Add new option by dragging and dropping it from the builder panel to the builder content.
2) Open options' settings, on General tab (the first one) choose connect or duplicate, then click on 'blue arrow' icon to fetch the list of options' of the same type stored in DB.
3) Click 'Submit' button.
Done! You successfully re-used stored in DB option by creating its new instance in another product!
The following procedure is a proper algorithm of re-using (i.e. using again same option, by creating its new instance in another product) the option when you want to edit the option and/or when you want to change the option's field slug!
1) Open module's settings modal window and click on unsync button
2) Change the option's slug as you usually do. Or change any other settings you like, especially those which are marked with a yellow triangle.
3) Save the module setting with "save to DB" checkbox checked
When you change setting NOT marked with the yellow triangle
Additionally, you can change any option's setting which is NOT marked with the yellow triangle in a certain option's instance and save it WITHOUT the checkbox 'save to DB' and this options' instance will continue working and you will not break any other instances of this option in other products. In this case you can change option's visual appearance, even its label, its fields conditional logic to be customised for this specific product where this option's instance is used. Very handy!
WooCommerce has its own 'duplicate' functionality. By using it you can duplicate the product. But sometimes it just fails and did not copy over some meta fields, like NOVs or maybe something else. So, I would suggest using Duplicate and/or Import/Export configs functionalities available in the pro version of Uni CPO.
👉 Duplicate and Import/Export configs functionalities are available in the PRO version in General Settings modal window, the fourth tab.
By duplicating product's configuration you are copying over the new product all the Uni CPO related data. Everything. So, the new product receives the exact copy of the same configuration used in the chosen product. All options' instances are connected and operational. All NOVs, formula conditional logic etc - everything is copied.
By importing product's configuration you basically do the same as per duplicating, but this time you do not choose another product that is existed in your site, but use config's data from the file. Another difference is that all options' instances may not work as you may not have them saved to DB on the site where you do import. That's why I would suggest using 'remove pid attribute values from all the modules' checkbox upon import. Since product's config contains also options' internal IDs, this setting actually removes them during the import. So, then you just have to open each options' settings and save them with 'save to DB' checkbox to make options' instances operational.