Hello Paul,
Welcome to the ServiceNow community!
I agree to your approach regarding the OOB elements and that's right it's always better to add some config on top of the existing rather than modifying OOB settings.
With regards to your points, I looked at the incident functions business rule which is a global one so it runs on every table and indeed it drives end users towards to the ess view. However, luckily it allows some flex to use your own "ess" views, as it contains a condition to leave alone your view setting if it starts with ess!
So apparently it supports the use an "ess_yourview" naming convention when you wish to setup your own views for self-service, shoudl you wish to leave the OOB ess view untouched.
I suggest to explore the "View Rules" functionality of the platform, where you can define or script conditions as to which view to render under given conditions.
Docs: Create a view rule
As to point (2) end users definitely should not have roles, should not have the ITIL role. User having such role has licence and cost implications (for accurate and up to date information please ask your ServiceNow representative).
Your points (3) and (4) may not be necessary considering the above.
As to point (5), creating business rules with different orders do not necessarily override each other, it defines in what order they run, it is their 'when to run' and 'condition' field which dictates if they get triggered or not.
Please let me know if the above helps.
A.
Hello Paul,
Welcome to the ServiceNow community!
I agree to your approach regarding the OOB elements and that's right it's always better to add some config on top of the existing rather than modifying OOB settings.
With regards to your points, I looked at the incident functions business rule which is a global one so it runs on every table and indeed it drives end users towards to the ess view. However, luckily it allows some flex to use your own "ess" views, as it contains a condition to leave alone your view setting if it starts with ess!
So apparently it supports the use an "ess_yourview" naming convention when you wish to setup your own views for self-service, shoudl you wish to leave the OOB ess view untouched.
I suggest to explore the "View Rules" functionality of the platform, where you can define or script conditions as to which view to render under given conditions.
Docs: Create a view rule
As to point (2) end users definitely should not have roles, should not have the ITIL role. User having such role has licence and cost implications (for accurate and up to date information please ask your ServiceNow representative).
Your points (3) and (4) may not be necessary considering the above.
As to point (5), creating business rules with different orders do not necessarily override each other, it defines in what order they run, it is their 'when to run' and 'condition' field which dictates if they get triggered or not.
Please let me know if the above helps.
A.
HI Paul,
I'm glad that it helped you with your ess view!
Yes, that's right and ACLs have key importance when it comes to security and controlling access to data in the system. There may be several reasons for these built-in rules already, in that case you mention, I think the thought process could be, that
end users, when they submit an incident, they should be able to indicate the impact of the incident on them, but allowing them to set the urgency same time would give them full control to determine both of the 2 factors which calculate the given incident priority.
So here the task.urgency ACL you mention may have such logic behind it.
With that said, however, given your use case you may want to open up the urgency - take a look at the OOB incident.impact ACL,
the one which has it's condition caller_id=javascript:gs.getUserID()^ORopened_by=javascript:gs.getUserID()^EQ.
This allows the impact field to be editable to end users (with no role), given the condition that they can only edit their tickets where they are the caller or they are the one who opened the ticket. This restriction has key importance when dealing with end-users who have no role.
An ACL on incident.urgency with condition caller_id=javascript:gs.getUserID()^ORopened_by=javascript:gs.getUserID()^EQ
could open up the urgency field for editing, masking the existing task.urgency (provided incident table here is extended from task table):
I do not recommend using Client scripts and UI policies for securing fields, as they are only rendering in a browser and do not block all the ways data can be accessed, and since users browsers running locally are out of control these scripts can even be bypassed.
Use of Client scrips should be minimized where possible for faster form loads, and UI policies are more there to deliver some business logic on the form (e.g. if I have a laptop I can pick a keyboard layout field, if I have a tablet I cannot) not to restrict or control access to a field.
Hope this helps,
Best regards,
A.
