- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi all,
I would like to allow inline editing for only one specific field in a list displayed on a Dashboard, while keeping all other fields read-only.
The list already supports inline editing by default. My requirement is:
Only one field (for example, u_comment) should be editable inline
All other fields should not be editable inline
The application itself must still have full CRUD access (create, read, update, delete)
I am considering controlling this using ACLs (table-level and field-level write ACLs).
However, since the same table is also accessed by an application that performs create/update/delete operations, I need to ensure:
Application access remains fully functional
Inline editing from the Dashboard is restricted to only one field
Has anyone implemented a similar requirement?
Is ACL the recommended approach, or is there a better practice for this scenario?
Any guidance would be appreciated.
Thanks!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thank you for your reply.
I was not aware of the list_edit ACL.
After considering possible solutions, I have decided to proceed with the following approach, even though it may be somewhat forceful:
For the one field that should be editable, set a list_edit ACL with the role that users possess.
For the fields that should not be editable, set a list_edit ACL with the admin role (which the users do not have).
Although this will increase the number of ACLs, I will control it using this method.
Thank you very much for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
I think your options are disable list editing (on/off) from the list control for the underlying table. Or use list_edit ACLs which affect the underlying table as well but offer column level control. If the users have the access via reports they'll have the table access so list_edit acls seem like the best bet.
Column acls would just prevent/allow the edits all around, which might be what you want anyway so it is an option of course.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thank you for your reply.
I was not aware of the list_edit ACL.
After considering possible solutions, I have decided to proceed with the following approach, even though it may be somewhat forceful:
For the one field that should be editable, set a list_edit ACL with the role that users possess.
For the fields that should not be editable, set a list_edit ACL with the admin role (which the users do not have).
Although this will increase the number of ACLs, I will control it using this method.
Thank you very much for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I don't think you can control that.
Even I have seen list_edit ACL on that field won't work on Dashboard/Workspaces.
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
Ankur
✨ Certified Technical Architect || ✨ 10x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
You might be thinking of onCellEdit client scripts. They don't seem to run on now experience pages
ACLs:

