What's your preferred way of storing global settings for a NetSuite account? Here are different methods I've used in the past. • Use a form Suitelet as a settings page, and store the data in a JSON file in the File Cabinet. (I like this one the best, but I'd rather use a standard NetSuite page.) • Use a custom record type. (I don't really like this method since you could have multiple instances of the custom record type.) • Use script parameters, and set the "Preference" to "Company". (I don't like this because then the values are tied to only one script.)

Custom record type

Custom record type. Control access, block delete and creation via script if that's a concern.

storing settings in a file in the file cabinet makes the settings inaccesible for client scripts

I would just write a Suitelet to get the settings from the File Cabinet

But you can't block deletion or editing of the file external to the intended process, no? These are extreme edge cases, but it seems like extra steps to get to the same place.

the custom record approach has the benefit of a GUI for free

You can't access the custom record data without server API calls either. Not really much difference.

What? record is certainly available on the client side. For your sescond point, you can control who has access to a custom record as well.

@stalbert True, but I don't really mind creating my own form with

serverWidget.createForm()

.

createForm()

is one the weakest APIs in all of SuiteScript.

@Sandii Yes, there are functions available for searching and loading records via client, but those still do server requests behind the scenes.

But file.load for the JSON is a server request

IMHO there's better places to spend time than creating configuration suitelets to provide a UI for a record

@Nicholas Klug I never said it wasn't

Right, but why would I want to build a suitelet to do the middle step when there is already an API (using record or search) that already does it? It's the same idea as the form. I feel like it's akin to not wanting to use lodash and instead writing your own functions that do the same thing. Why reinvent the wheel?

Using a custom record, you save the values as individual fields (not a JSON blob) then load the record as needed (and with NFT that record is a natural JS object already)

This seems like a lot of work to make a square wheel.

creating a suitelet from scratch generally results in a square wheel

It's not that its harder/easier, it's just unnecessary work and more code to maintain.

You have to custom roll a form, middle suitelet to facilitate, lose all hierarchy, and gain no permission control? Or you can create a custom record, write a script that blocks all updates, creates, or deletes if the role != administrator

Yeah. My original intent was not to fight for using the file cabinet. Thanks for the feedback. I was hoping there was a way to create custom fields somewhere global like the Company Information page.

wait wait, so in what case is it ok to create parameters for a script and set it as a company wide field? I've been doing it like that since I started learning suitescript 5 months ago

IMO, company wide parameters aren't bad but the problem is being real clear on where they live

I always set them as company wide and I'll have them appear in the company settings page at the bottom of the "Custom preferences" subtab, but I'm still learning

I've seen people name script parameters "525_thingIDo" where 525 is the script internal ID

@Mr_Tib Yeah, I like that approach. You can use

config.load()

to get the field values from any server script.

personally, this is why I use a custom record approach. You have one hub that you can quickly config when migrating across several environments

@Nicholas Klug Your approach sounds interesting, I've never tried that. Is it considered a bad practice or trying to reinvent the wheel?

It's been standard practice at both of the consulting firms I've worked at, but your mileage may vary.

Got it. I'm only asking because I'm still getting the hang of everything so it's nice to know both approaches

No problem. Again, company preferences aren't bad, you just need to document in the event that you may need to delete a script later. Documentation is good, Documentation is life :)

Yeah I agree. I've also been having a hard time not hardcoding stuff sometimes, would you say is 100% possible to not hardcode stuff?

There's very rarely a reason to hardcode something

Yeah, I figured as much. Probably just bad architecture on my part.

Most likely. There are times you can kind of justify it though. Like system generated roles, payment options, things that should be immutable

I'm hardcoding the IDs of all 5 expense categories that are available in the environment I'm working in

Step 1 - make sure every single one of those hardcodings has // This is Meals/Entertainment etc. next to them. Step 2 - You probably should go back and make these a non-hardcoded value, but if they never change and you're a junior, I doubt anyone will hate you for it as long as it's commented

Yeah I did comment what the ID corresponds to. However I'm working on Sandbox so, for the final deployment to prod, I'm going to have to go and create those expense categories and update the Ids on my code

Ah. Stop right there. It's time to make everything either a script parameter or a custom record 🙂

Yeah that right there is the exact reason to not hard code lol

if you have a "production" code version and a "sandbox" code version, you're asking for trouble. Now, I've seen big 4 consultants do lazy things like detect if they're in the sandbox and do X, if in prod do Y. But you can be better than them and do it the right way

Yeah, that's how I figured I was not taking the best approach, sounds like you said, asking for trouble

Untitled

im in the custom record group

config record example

@Nicholas Klug That would fail if someone deletes the first configuration record for some reason. I prefer to get it via a search and take the first result.

It would. Unless you have a script in place that blocks creation and deletion of the custom record.

In practice, people (end users) don't care about or delete your custom config record #1.

Additionally, you can write a delete/create/edit blocking script for all but admins once, then reuse it for any custom record on any account.