DontDestroyOnLoad coding procedure

Been searching here for an answer to a procedural question with no luck so here goes: Our sim’s behavior relies on the users choices on a config screen. I know how to pass these via global vars using DontDestroyOnLoad(). However…When designing/creating/coding a new scene reliant on data from a previous scene, this data is not available til runtime. Other than testing every reference to the vars for their existence and accepting the processing overhead or creating dummy vars so scripts will compile and the accompanying waste of time for a lot of user choices, does anyone have some thoughts on workflow in this situation? Thanks in advance

We handled a problem like this, and there probably is a better way, but I can take you through what we did.
Similar to you we had a scene which took user choices and created objects used later in other scenes. We then wanted to be able to have loaded settings for each scene during dev/testing and not have to enter through the menus manually. We also wanted the to make sure the same process was used for the menus as it was for the individual scenes.

We ended up creating a spawn behaviour that on start checked to see if the scene had been entered through the menu via checking some static properties. If it hadn’t been the spawn behaviour would set up static references on the menu behaviour (essentially telling it to automatically load the level with a particular set of settings). Then the spawn behaviour would load the menu scene. The menu behaviour in that scene would check these statics at start and then use that data to load the level scene set up instead of waiting for user selections.
The settings used for configuration ended up being gameObjects with particular behaviours, and prefabs for this spawner were saved for common configurations. Simply add the spawner into the scene needing the data, configured properly for the scene.

After implemented I was suprised at how quickly the scene loaded for the switching, its only a split second of waiting. It was originally just a quick solution, but so far we’ve had no problems with it, and the workflow has been simple… so it has remained.