Hi Sambit,
I think Stefan has you on the right track. If the ask is to limit access to the Change application from the default access controls that grant access to the application to users with the itil role, this will solve that. If you want a little more granular control, from an application menu there is also a related list for the modules within that application record that will also contain a field to control access by role. Just be aware some of the modules in the application have different role access, by default, but that information is all available from the application and module records.
Gentlemen,
Thank you very much for your valuable inputs.But I am not able to get through
the options as mentioned.The requirement is User will be able to see only the change module
and should able to create the required change.
I have attached the screenshot for the ACL that I have created.
Please provide your feed back on the same.
Thanks,
Sambit
Hello Sambit,
This is not a solution to your question per se but a bit of ACL information which you perhaps you can use to solve your issue.
ACL's or Security rules protect your information in ServiceNow like this;
1. The first level of ACL protection is the table level; (Note the Type and Operation fields in the first screenshot below)
Here we're securing a specific operation on a table level (create, on Incident in this case, even though the type says record...)
It could be any of the C.R.U.D actions (Create, Read, Update, Delete) or any of the other available operations you can use to protect information in ServiceNow using ACL's.
The second level of protection is the record itself;
Here we've changed -- None -- on the Name field to an asterisk * which means the ACL is now operating on a record level (as opposed to the table level from before)
Now, we can narrow it down further by specifying a field that this ACL should affect by adding a field;
So this is the scope of the ACL (what it covers).
Next we have the conditions of when the ACL is in effect.
There are three conditions for each ACL that all must return "true" for the action/operation to allow access.
(the default action is to deny access in ServiceNow)
- A role assignment
- A condition builder
- A script (if you tick Advanced) which also must return "true".
However, the ACL's are not evaluated hierarchically with respect to each other.
Which means that you could create a copy of an already existing ACL with just a slightly different result in any of the three conditions I mentioned above, and if it returns true then the ACL will allow the operation.
Basically, each ACL is evaluated based on the scope or "conditions" you define and if any ACL returns true under those conditions the action/operation is allowed.
