Business rules can change as processes evolve. If those rules are hardcoded directly into SuiteScript, every change may require a developer to edit, test, and redeploy the script.
Designing scripts with maintainability in mind can make future updates easier and reduce unnecessary rework.
Scenario
A business team uses a SuiteScript customization to apply specific logic.
Examples may include:
- assigning a default reviewer
- setting a processing status
- applying a threshold amount
- selecting an email recipient
- choosing which saved search to run
- deciding how many days before follow-up
Over time, the business rule changes. If the value is hardcoded in the script, even a small update may require a code change.
Solution
Move frequently changing values out of the script when possible.
Instead of hardcoding every rule, consider using configuration options such as:
- script parameters
- custom records
- custom lists
- saved searches
- custom fields
This allows administrators to adjust certain values without changing the core script logic.
Example
A script assigns a reviewer when a request amount is greater than a certain threshold.
Hardcoded logic may look like:
if (amount > 5000) {
reviewer = 123;
}
This works, but if the threshold changes from 5000 to 7500, or the reviewer changes, the script must be edited.
A more maintainable design can store the threshold and reviewer in a script parameter or custom configuration record, so the values can be updated without changing the main script logic.
Common Values to Avoid Hardcoding
Consider making these values configurable when they may change:
- employee IDs
- saved search IDs
- status values
- threshold amounts
- email recipients
- date offsets
- approval routing values
- processing limits
Not every value needs to be configurable. The goal is to identify values that are likely to change.
Ways to Improve Maintainability
Use Script Parameters for Simple Values
Script parameters are useful for values such as saved search IDs, employee IDs, limits, or default settings.
Example:
const script = runtime.getCurrentScript();
const thresholdAmount = script.getParameter({
name: 'custscript_threshold_amount'
});
This lets an administrator update the value on the script deployment instead of editing the script file.
Use Custom Records for Larger Rule Sets
If the rule includes multiple related values, a custom record may be easier to maintain.
Example configuration record:
- Rule Name
- Threshold Amount
- Reviewer
- Active
- Effective Date
This works well when there are multiple rules or when the business wants a clearer configuration table.
Use Custom Lists for Controlled Values
If the script depends on statuses or categories, custom lists can help keep values consistent.
Example:
- Pending Review
- Approved
- Rejected
- Needs Follow-Up
This helps reduce errors from inconsistent text values.
Keep Script Logic Clear
Even when values are configurable, the script should remain easy to understand.
Use clear function names, comments where helpful, and consistent error handling.
References
- SA: Script Deployment (ID: 49287)
- SA: Script Parameter Preferences (ID: 10571)
- SA: SuiteScript (ID: 31709)
- SA: SuiteCloud (ID: 1014757)
Notes
- Make frequently changing values configurable.
- Avoid hardcoding employee IDs, email addresses, thresholds, and saved search IDs when possible.
- Use script parameters for simple settings.
- Use custom records for more complex rule tables.
- Keep configuration names clear so admins understand what they control.
- Test configuration changes in sandbox before production.
- Document which values can be updated without changing code.
Summary
When a business rule changes often, SuiteScript should be designed so updates are easier to manage. By moving changing values into script parameters, custom records, custom lists, or saved searches, teams can reduce code changes and make the script easier to support over time.
The goal is to keep the script stable while allowing the business rules around it to change safely.
Disclaimer: The sample code described herein is provided on an "as is" basis, without warranty of any kind, to the fullest extent permitted by law. Oracle + NetSuite Inc. does not warrant or guarantee the individual success developers may have in implementing the sample code on their development platforms or in using their own Web server configurations.
Oracle + NetSuite Inc. does not warrant, guarantee or make any representations regarding the use, results of use, accuracy, timeliness or completeness of any data or information relating to the sample code. Oracle + NetSuite Inc. disclaims all warranties, express or implied, and in particular, disclaims all warranties of merchantability, fitness for a particular purpose, and warranties related to the code, or any service or software related thereto.
Oracle + NetSuite Inc. shall not be liable for any direct, indirect or consequential damages or costs of any type arising out of any action taken by you or others related to the sample code.
Share your insights and experiences in the NetSuite Admin Corner.
