What is the best way to store "global variables" for use in different scripts? Like preferences, where my script can get the values. I'm against making/using files in the file cabinet, like an xml file to store those. Ideally, I'd want a UI where I can assign a user to change variables there whenever he needs to.

A config custom record is a common approach. https://stoic.software/effective-suitescript/suitescript-design-the-singleton-record/

the other alternative is Script Parameters

Config custom record affords control, visibility, flexibility, and power that you don't get with script params. Certain List/Record refs are not available; multiselect cannot be used; references to saved searches must be public; you have no control over how the field is display; there is no means of validating script param field input in the script deployment form; and on and on. Script params are basically the late runtime binding of NetSuite scripting--and they come with a similar set of advantages and perils. With config recs you can have custom forms and arrange the material in way that is intelligble and usable. Try looking at script or company parameters after you add more than a few: it's a mess. With config recs, you can use record- and field-level permissions and designate certain config params for some roles to maintain, others for Admin only, etc. Config recs can support lots of different functionality that may be important, depending on the env. For example, one could add metadata and UE logic for config-set start and end datetime for the purpose of coordinating configuration with deployment (one record is the "active" singleton, which maybe expires on a certain date coinciding with a important release, at which point a new config set with a new start date "takes over." System Notes on a config rec would be much easier to follow and more transparent than, say, putting something in place to track the company preferences (not to mention the fact that you can use permissions to expose certain config fields and not others -- this would not be possible with company-level script params). One advantage of params would appear to be built-in caching (not sure! it seems so and would make sense). With a custom config record, you would need to implement caching using N/cache achieve the performance of in-memory/in-session config data.

@zvictor is your implementation similar to how stoic software did it? or is there a significant difference that he did not mention?

@Mars That is a nice article, BTW - Stoic and Eric G. FTW! It is not about a config record - it is a more fundamental concept, which applies in the creation of a config record: the singleton pattern. Not every singleton has to do with config, but probably every config implementation is a singleton within its scope. Stoic's article shows you how to implement in NetSuite a singleton at the level of the record-entry: the UE is used as a mechanism to ensure that there always only one record instance. The examples I gave would/could enrich that, but it's the same underlying principle. You could, for example, have other records that were "inactive" -- in that case there would be multiple records, and the singleton concept would apply to the one record designated as the active config set. I have implemented that, actually -- and as you'd expect, it requires a few more lines of code in the UE and metadata fields on the record (or simply the built-in is_inactive field). Same backbone, though. The Stoic article is great, and if you get it, you can build on it.

When you don't have complex config requirements it makes sense to use script parameters, because is faster and easier to create or maintain. In the other hand when you are passing parameters on the fly to a Map Reduce for example that parameter value is only on memory and only accessible by that Map Reduce in that specific execution, you can't do that with custom records.