You can leave all the configuration in globalconfig provided you have no complex configuration requirements. Changes to globalconfig are not persisted so anything you wrote there would be lost on restart of the API Sandbox. For my purposes, globalconfig is only suitable as a configuration input, but not as a master record. In particular, I generally want to have more complicated configuration options than would be reasonable to put in globalconfig (consider the dynamic rules system in GroupInitiative). Additionally, I want to provide a way that configuration can be adjusted at runtime, which means I need to persist in the state. The globalconfig does provide some assistance here. Steve added a property for each script's configuration area named 'lastsaved' which contains a timestamp when the script was last saved (which equates to the last time the configuration was adjusted/created/enforced) that can be used to know if a configuration happened in the globalconfig since the last time your script took those settings. If you look at the current released version of Bump, you can see how I've been using it (look at checkInstall() and checkGlobalConfig()). BTW, it is handy to have globalconfig writable for testing, but I otherwise agree with Brian's sentiment that you don't want to be in the habit of writing to globalconfig with any expectations.