Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

Quick Message issue in ServiceNow

Burhan2
Tera Contributor

Hi Team,

 

We have one issue with user where they wanted access for Quick messages in Servicenow. As per docs we provided "email_client_quick_message_author" role to user. The issue is when user is trying to create new quick message the body field is read-only and not able to edit.

 

We checked there are no ui policy or ACL ootb for this. Previously also we have given one user access and body field was editable to them. Is there something new came in new versions? Can anyone please assist if they have idea about it.

1 ACCEPTED SOLUTION

@Burhan2 

you can use access analyzer and debug and see which ACL is blocking for non-admin

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
✨ Certified Technical Architect  ||  ✨ 10x ServiceNow MVP  ||  ✨ ServiceNow Community Leader

View solution in original post

5 REPLIES 5

Shahjay
Kilo Guru

Hi @Burhan2 ,

Since admin can edit the Body and this user can’t, it’s almost certainly an access issue, not a UI Policy.

`email_client_quick_message_author` is the right role for creating Quick Messages, but it doesn’t always give write on every field by itself. Run Access Analyzer as that user against the Quick Message form (table is `sys_email_canned_message`) and specifically check write on the Body field. That will show which ACL is blocking them.


Also check Dictionary Overrides on the Body field. An override with Read only checked will lock the field even when ACL debug looks green. That’s a different layer from normal ACLs and easy to miss.

Quick check that they’re on a normal classic form and not a Workspace view of the same record — some HTML/rich-text fields render as a read-only viewer there depending on the UI config.


A UI Policy won’t fix this. UI Policy is client-side form behaviour; if write is denied by ACL (or dictionary override), the field stays locked no matter what the policy says.


That’s the same path Ankur pointed at — Access Analyzer will tell you exactly what’s denying write for the non-admin.

If this response helped, please mark it as correct and close the thread ✅ — it helps future readers find the solution faster.

Thanks