🧠 ServiceNow Tip: Block Inline Editing Without Using ACLs

[Siddhesh Jadhav]

Hey #ServiceNow community 👋

Ever had a situation where you need to prevent inline (list view) editing on certain fields — but still want those fields editable on the form?

Most folks reach for Access Control Rules (ACLs). But here’s the thing… ACLs can be:

• Overkill for simple restrictions

• Difficult to maintain when you want context-specific logic

• Limiting when you want list control, not full table/field lock

So instead, I used a client-side solution that leverages the onCellEdit event and GlideModal() to block list editing dynamically — without touching ACLs.

---

✅ The Use Case

I needed to ensure that lifecycle-related fields like Lifecycle State and Lifecycle Stage Status were:

• Editable only via the form

• Completely blocked in the list view

• Clearly communicated to the user (not just silently blocked)

---

🔐 The ACL-Free Solution Using onCellEdit and GlideModal

📍 Step 1: Uncheck “Isolate Script”

Make sure to uncheck "Isolate Script" in the Client Script form.
This lets you interact with the DOM to show modals.

 

📍 Step 2: Client Script – onCellEdit

function onCellEdit(sysIDs, table, oldValues, newValue, callback) {
	try {
		if (newValue) {
			// Show modal message and prevent save
			cancelDialog(function () {
				callback(false); // Prevent inline save
			});
		}
	} catch (err) {
		console.error('Error in onCellEdit client script: ' + err.message);
		callback(false);
	}
}

 

 

📍 Step 3: Custom GlideModal Function

function cancelDialog(callback) {
	var dialog = new GlideModal();
	dialog.setTitle('Action Not Allowed');

	window.__dialogCallback = function () {
		dialog.destroy();
		callback();
		delete window.__dialogCallback;
	};

	dialog.renderWithContent(
		'<div style="padding:20px; font-size:14px;">' +
		'<p><strong>Lifecycle State</strong> and <strong>Lifecycle Stage Status</strong> must be updated together from the form. List editing is not allowed.</p>' +
		'<div style="text-align:right; margin-top:20px;">' +
		'<button class="btn btn-primary" onclick="window.__dialogCallback()">OK</button>' +
		'</div>' +
		'</div>'
	);
}

 

🚫 Why Not Just Use ACLs?

Glad you asked. Here’s why this approach is better in some cases:

❌ ACLs ✅ This Approach

Requires backend configuration	100% client-side
Blocks form + list access together	List-only control
Harder to debug for non-admins	Simple to manage in script
Can affect performance when misconfigured	Lightweight and fast

---

🔚 Final Thoughts

This method is a clean, ACL-free way to handle inline edit restrictions with more control and a better user experience.

Instead of blocking everything with ACLs, you guide the user to the correct behavior — form editing — while keeping your list views clean and functional.

If you found this helpful or used something similar, I’d love to hear your story! Drop a comment or share with your team. 🚀

[Mark Manders]

And your client side solution allows people to go around it in many different ways and since it runs client side, it will run every time. You are also introducing custom components for this, making it harder to maintain, especially if something needs to be done in three years.
Why not just limit list editing through the list control? That also doesn't require ACLs. With just one simple OOB setting you can prevent list editing. If it's not allowed, it's not allowed. You don't have to use system resources to tell your user that they should open the form to update it. That's pretty self explanatory.

Don't get me wrong. I always love to see how people are playing with the platform and achieving things, but some use cases can be handled in OOB ways that work more efficiently.