How to Disable the “Add” Button in ServiceNow MRVS (Multi-Row Variable Set)

If you’ve worked with Multi-Row Variable Sets (MRVS) in ServiceNow, you’ve probably seen this requirement come up:

“Allow users to add rows sometimes… but restrict them in certain scenarios.”

This is where most people go down the wrong path like DOM manipulation, hiding buttons, messy client scripts…

But there’s actually a clean, controlled way to do this using max_rows_size dynamically.

Let’s get into it.

🎯 The Real Requirement

Not just:

• Disable “Add” button ❌

But:

• Disable it based on a condition ✅
• Enable it again when needed ✅
• Keep everything upgrade-safe ✅

⚡ The Approach

Instead of hardcoding Maximum rows in the MRVS record, we control it dynamically using a Catalog Client Script (onLoad).

💻 The Code (What I Used in My Scenario)

function onLoad() {
  var mrvs = g_form.getField('your_mrvs_name');
  if (!mrvs) return;

  if (yourCondition()) {
    mrvs.max_rows_size = 0; // disables Add
  } else {
    mrvs.max_rows_size = 5; // or whatever limit you want
  }
}

🧠 What’s Happening Here?

• g_form.getField('your_mrvs_name')
  → Gets the MRVS field object
• max_rows_size = 0
  → Removes the ability to add new rows (Add button disappears)
• max_rows_size = 5
  → Restores row addition with a limit

👉 So instead of static configuration, you now have full runtime control

🔥 Why This Approach is Better

This is where things get interesting.

✅ Dynamic Control

You can base it on:

• User roles
• Variable values
• Request type
• Stage / state

✅ No DOM Hacks

No:

• querySelector
• button hiding
• CSS tricks

👉 Which means:

• Upgrade safe
• Consistent across portals

✅ Reusable Pattern

Once you understand this, you can apply it to:

• Multiple MRVS
• Different conditions
• Complex catalog flows

⚠️ Important Gotchas

1. Replace your_mrvs_name

Use the exact variable name, not the label.

2. Define yourCondition()

This is where your logic lives. Example:

function yourCondition() {
return g_form.getValue('request_type') == 'view_only';
}

3. Existing Rows Still Show

Even when disabled:

• Existing rows are visible ✅
• Users just can’t add new ones ❌

4. Works Only on UI Level

If data is inserted via:

• Flow Designer
• Business Rules
• Script Includes

It will still work.

👉 This only controls user interaction

🧩 Real-World Use Case

In one of my implementations:

• MRVS was populated from an integration
• Users could edit only in early stages
• Once moved to approval stage → lock it

Instead of rebuilding UI logic, we simply did:

if (stage == 'approval') {
  mrvs.max_rows_size = 0;
}

Clean. Predictable. No surprises.

❌ What You Should Avoid

I’ve seen people:

• Hide Add button using DOM
• Disable clicks manually
• Inject CSS

All of these:

• Break easily ❌
• Are inconsistent ❌
• Hard to maintain ❌

👉 If max_rows_size solves it, don’t overthink it.

Final Thought

This is one of those small tricks that makes your implementation feel clean.

Instead of fighting the platform, use what it already gives you.