ACLs on a Ticket Form non-itil user

[rconstantino]

Good morning,

I have run into yet another ACL issue on a ticket form for non-itil user.

What ACLs are needed for a non-itil user to have the ability to add an attachment and/or aan additional comment on this form?  (see attached)

I have created a write/read on customtable.comments.

What am I missing?

Thank you in advance,

Rachel

[Abhishek Pal · Accepted solution]

Hi @rconstantino ,

You are very close. A write ACL only on:

customtable.comments

is not enough.

For a journal field such as Additional comments, the user must first pass the WRITE ACL on the record/table and then the WRITE ACL on the comments field.

Recommended configuration:

1. Create a dedicated role for these non-ITIL users, for example:

x_your_scope.ticket_user

Do not grant the itil role just to allow comments or attachments.

2. Allow the user to read the ticket

Create/verify:

Table:
customtable

Operation:
read

Requires role:
x_your_scope.ticket_user

Add a condition/script so users can access only the appropriate tickets, for example:

Opened by is Me
OR
Requested for is Me

Use whatever ownership relationship is correct for your application.

3. Allow record-level write

Create:

Table:
customtable

Operation:
write

Requires role:
x_your_scope.ticket_user

Use the same record-level condition.

This is important because ServiceNow evaluates the table ACL before the field ACL.

If the user fails customtable.write, then passing:

customtable.comments.write

will still not allow them to update Additional comments.

4. Allow only Additional comments

Create:

Table/Field:
customtable.comments

Operation:
write

Requires role:
x_your_scope.ticket_user

Again, use the appropriate record condition if required.

If you do NOT want these users editing the other fields on the ticket, protect the remaining fields with your existing field ACLs.

A good least-privilege pattern is:

customtable
WRITE
-> ticket_user can pass for permitted records

customtable.comments
WRITE
-> ticket_user can pass

customtable.*
WRITE
-> keep restricted to your fulfiller/admin role

Because the explicit comments ACL is more specific than customtable.*, the user can update comments while other fields remain protected.

5. Attachment access

Attachments have an additional security check.

To upload an attachment, the user must have:

- Read access to the target ticket
- Write access to the target ticket
- Permission to create Attachment [sys_attachment] records

So first fix the customtable read/write ACLs and retest the paperclip.

Do not immediately create a broad sys_attachment ACL.

Impersonate the affected non-ITIL user and enable:

System Security
-> Debug Security Rules

Then upload an attachment.

If Debug Security shows that sys_attachment.create is the remaining failure, create an ACL for your dedicated integration/application role and restrict it to your ticket table.

Do NOT create an unrestricted sys_attachment.create ACL for all authenticated users, because sys_attachment is shared by the entire instance.

For example, if a custom ACL is genuinely required, restrict it conceptually to:

Role:
x_your_scope.ticket_user

AND

Target attachment table:
customtable

AND

User has write access to the referenced customtable record

6. If customtable extends Task

This is also important.

If your custom table extends Task [task], inherited Task ACLs can participate in ACL evaluation.

However, ServiceNow evaluates the specific table before its parent table.

Therefore, create the required ACLs on your actual custom table rather than modifying the OOB Task ACLs.

Do not add your non-ITIL role to existing OOB task ACLs just to solve this requirement, because that could unintentionally grant access to Incident, Change, Problem and other Task-derived records.

7. Recommended debugging test

Impersonate the non-ITIL user and check these individually:

Can open ticket?
-> customtable.read

Can submit comment?
-> customtable.write
-> customtable.comments.write

Can upload attachment?
-> customtable.read
-> customtable.write
-> sys_attachment.create

Also use:

System Security
-> Debug Security Rules

This will show the exact ACL that is denying the operation.

So the most likely thing you are currently missing is:

customtable.write

You created:

customtable.comments.write

but a field-level ACL cannot grant write access when the user has already failed the table-level write ACL.

Recommended final model:

Non-ITIL user
-> custom application role
-> Read permitted ticket
-> Write permitted ticket at table level
-> Write Additional comments only at field level
-> Create attachments only for permitted ticket records

This gives the user the ability to use the Send box and attachment icon without granting full ITIL fulfiller access.

Official references:

ACL rule types:
https://www.servicenow.com/docs/r/platform-security/access-control/acl-rule-types.html

Attachment API security requirements:
https://www.servicenow.com/docs/r/api-reference/rest-apis/c_AttachmentAPI.html

Journal fields:
https://www.servicenow.com/docs/r/platform-administration/table-administration-and-data-management/r...

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal

[Its_Azar]

Hi there @rconstantino 

For this, comments ACL alone will nont be enough. For a non-ITIL user, also check the table read/write ACLs and the Attachment (sys_attachment) create/write ACLs.

For the comment box, make sure the user has write access to the actual field (comments) and the parent ticket record. For the paperclip, check the attachment ACLs as well.

I’d first use Debug Security Rules while reproducing the issue it’ll show exactly which ACL is failing.

[Ankur Bawiskar]

@rconstantino 

Simple rule -> if user satisfies Table.None WRITE ACL then user can add attachment

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

[rconstantino]

Thank you for all this info - extremely helpful.

I created 'customtable.write' and this resolved the issue.