Extended table not accessible

Community Alums
Not applicable

Hello,

 

I have created a custom table on one of the Custom application, here I have extended the task table and here the problem is when I give ITIL role to user extended table is accessible to user if not user is not able to see the child table and approver_user role is not allowing user to approve the request.

Please let me know

1. Is ITIL role required to access the extended table from task?

2. approver_user role is not enough to approve the reuquest?

1 ACCEPTED SOLUTION

Service_RNow
Mega Sage

@Community Alums 

1. Is the ITIL role required to access the extended table from task?

Answer:
Not strictly required, but by default, yes — because of inherited ACLs from the Task table.

Details:

  • When you extend the task table, your custom table inherits ACLs (Access Control Rules) from task.

  • Most of the default ACLs on the task table (especially for read/write access) check for the ITIL role (incident_read, task_read, etc.).

  • Unless you explicitly create custom ACLs for your extended table that grant access based on different roles (like a custom role or approver_user), users will need ITIL or similar access to see the records.

👉 Solution: You can create table-specific ACLs for your extended table to grant access without requiring ITIL.

Example:

  • Go to System Security > Access Control (ACL).

  • Create new ACLs for your custom table (e.g., x_custom_task_table) with conditions that check for your custom role (not ITIL).


2. Is approver_user role not enough to approve the request?

Answer:
Correct — approver_user alone is not always enough to approve a request unless specific ACLs allow it.

Details:

  • The approver_user role is intended to give users the ability to see and act on approval records, but it does not inherently grant access to the task or request record itself.

  • If the approval record is related to your custom task-extended table, and the user doesn’t have access to that table (because of missing ITIL or another proper role), they won’t be able to open or approve via the UI.

👉 Solution: Ensure:

  1. The user has access to approval records (usually via sysapproval_approver table).

  2. The user has read access to the extended task table (via ACLs — not necessarily ITIL, but a custom ACL based on approver_user role can help).

  3. There’s no UI policy, business rule, or client script hiding the approval buttons.


Recommended Steps:

  1. Create custom ACLs for your extended table (x_your_custom_table) for read, write, and approve, targeting your desired roles (like approver_user).

  2. Check role inheritance — maybe create a custom role like x_custom_approver that includes approver_user and use that in ACLs.

  3. Ensure the user can access the Approval record (sysapproval_approver) tied to the task.

  4. Test impersonating a user with the minimal roles you expect to work, and check browser console for ACL errors (if any).
    Hope the answer has helped you, please mark the answer correct/helpful. Thank you.

View solution in original post

3 REPLIES 3

Service_RNow
Mega Sage

@Community Alums 

1. Is the ITIL role required to access the extended table from task?

Answer:
Not strictly required, but by default, yes — because of inherited ACLs from the Task table.

Details:

  • When you extend the task table, your custom table inherits ACLs (Access Control Rules) from task.

  • Most of the default ACLs on the task table (especially for read/write access) check for the ITIL role (incident_read, task_read, etc.).

  • Unless you explicitly create custom ACLs for your extended table that grant access based on different roles (like a custom role or approver_user), users will need ITIL or similar access to see the records.

👉 Solution: You can create table-specific ACLs for your extended table to grant access without requiring ITIL.

Example:

  • Go to System Security > Access Control (ACL).

  • Create new ACLs for your custom table (e.g., x_custom_task_table) with conditions that check for your custom role (not ITIL).


2. Is approver_user role not enough to approve the request?

Answer:
Correct — approver_user alone is not always enough to approve a request unless specific ACLs allow it.

Details:

  • The approver_user role is intended to give users the ability to see and act on approval records, but it does not inherently grant access to the task or request record itself.

  • If the approval record is related to your custom task-extended table, and the user doesn’t have access to that table (because of missing ITIL or another proper role), they won’t be able to open or approve via the UI.

👉 Solution: Ensure:

  1. The user has access to approval records (usually via sysapproval_approver table).

  2. The user has read access to the extended task table (via ACLs — not necessarily ITIL, but a custom ACL based on approver_user role can help).

  3. There’s no UI policy, business rule, or client script hiding the approval buttons.


Recommended Steps:

  1. Create custom ACLs for your extended table (x_your_custom_table) for read, write, and approve, targeting your desired roles (like approver_user).

  2. Check role inheritance — maybe create a custom role like x_custom_approver that includes approver_user and use that in ACLs.

  3. Ensure the user can access the Approval record (sysapproval_approver) tied to the task.

  4. Test impersonating a user with the minimal roles you expect to work, and check browser console for ACL errors (if any).
    Hope the answer has helped you, please mark the answer correct/helpful. Thank you.

Dr Atul G- LNG
Tera Patron
Tera Patron

Hi @Community Alums 

1. Is ITIL role required to access the extended table from task?

Atul: You created a custom table, which means it’s not provided by ServiceNow out-of-the-box (OOTB), so the OOTB role won’t work here. When you create a custom table, the system generates a custom role as well. Unless you assign that role, a user won’t be able to access the table.

 

2. approver_user role is not enough to approve the reuquest?

Atul: Are you referring in above context?

 

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************

Ankur Bawiskar
Tera Patron
Tera Patron

@Community Alums 

since your table is a custom one extending task within your scoped app, you should ensure that table gets that new custom scope role

Your users should have that role and it should be sufficient enough

But remember there might be some fields which are on task which are having field level READ, WRITE

that you need to check and create field level  READ and WRITE on your table with your role

approver_user-> yes this is enough, but remember there is license cost for this which you can check with your company's ServiceNow account representative

If my response helped please mark it correct and close the thread so that it benefits future readers.

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