Best Practice for Defining Constants Used by a Catalog Item

[ShumaS]

Hello everyone,

I would like to ask about the best practice for defining and managing constants that are used by a specific Catalog Item.

Example

Let's assume we have a Catalog Item for requesting additional storage capacity.

• Maximum allowed capacity increase: 100 GB

This constant needs to be referenced in multiple places:

1. Catalog Client Scripts / UI Control

   • Display an error message when the requested value exceeds the limit.
   • Show additional input fields when the threshold is exceeded.

2. Process Automation / Flow Logic

   • Requests within the limit are processed automatically.
   • Requests exceeding the limit are routed to a responsible person for review and approval.

Options I Am Considering

1. System Property

My current thought is that this may be the closest approach to a best practice.

Pros

• Single source of truth.
• Easy to update without modifying multiple artifacts.

Concerns

• The value is only relevant to a specific Catalog Item, so I am not sure whether a system-wide configuration object is appropriate for such a localized setting.
• If many similar properties are added over time, could this have a negative impact on instance startup or performance?
• I assume properties are loaded only when referenced, but I would appreciate confirmation.

2. Decision Table

Pros

• Centralized management.
• Can potentially support future scenarios where thresholds vary by conditions.

Concerns

• It feels more like business-rule management than a simple constant definition.
• ServiceNow developers would understand it, but administrators or support personnel without platform knowledge may find it less intuitive.

3. Catalog Variable

Pros

• Easy to implement.
• Works well for UI Policies and Catalog Client Scripts.
• No additional server-side lookup is required, which minimizes latency.

Concerns

• Since the value exists on the client side, it could potentially be be manipulated.
• I am hesitant to use a client-side value as the basis for flow decisions or business logic.

4. Separate Catalog Variable and Flow Variable

Pros

• Easy to understand.
• Avoids relying on client-side values for automation decisions.

Concerns

• Creates duplicate configuration points.
• Lower maintainability due to double management of the same threshold.

Question

For a constant such as a maximum request size that must be referenced by both Catalog Client Scripts and Flow Designer logic, what would be considered the recommended or best-practice approach in ServiceNow?

If you have implemented similar requirements, I would be interested in learning:

• Which approach you selected.
• The reasoning behind the choice.
• Any performance, maintainability, or security considerations that influenced your decision.

My primary goal is to maintain a single source of truth while balancing maintainability, security, and performance. I would appreciate any guidance on how experienced ServiceNow architects and developers typically approach this type of requirement.

Thank you in advance for your advice.

[l457]

If it's just for one item just make it a choice. Consider the time used for the config now vs the update cadence for the value, how many catalog items will use it now/in the future ie. the future time save.

For server side just store the value in a system property, unless there is some logic to the choice then you could use a decision table. Decision tables are just a graphical ui for an if else block. System properties are cached in the application layer so they are fast to retrieve and you probably won't be creating enough properties to cause performance issues. And if you want to surface it client side then just use a display br

[ShumaS]

Hi @l457 ,

Thanks for the comment!

In my case, the requested capacity is entered as a numeric free-text field and users can request any value between 0 and 100 GB.
Because of that, using a Choice variable does not seem practical.
In that scenario, would System Properties still be your recommended approach?

[l457]

I see i didnt formulate my answer properly regarding the choices. It's always good to consider how users will input data. The distribution could be skewed left enough that you don't actually need small values and users might tend to enter in multiples of 10 anyway. Just for UX reasons i would use choices. If you have a valid thought out reason to actually have it freeform then that's fine.

As for the system property, it is probably easiest if you are using an onchange client script to validate the input and want it all to be updateable from one place. Just glideajax it in an onload script.