What is the risk in creating an ACL based on a group or adjusting application menu roles?

[Awae]

Hello. I'm working on granting a new group read-only access to an application without making use of any roles.

My approach was: 

1. To expand access to the application menu for Demand Management to the role snc_internal (so anyone can look it up)

2. To write a new read acl to check if a certain user is in the group (based on the group sys_id) 

3. To restrict the appearance of the 'New' button, which is the only UI action available from the list view, to the roles originally assigned to the application (Demand Management) I'm working on. 

Right now any internal users can click into Demands, but not view or create anything on the application I'm adjusting since I haven't written any new ACLs to allow unrestricted read/write/create/delete access. Users added to the new group I created have read access and it seems all the requirements have been met without affecting users who already have access to the Demand Management application. 

My question is: What is the risk involved in this approach? I've tested it thoroughly and can't seem to find any issues with it. I'd like to hear any concerns since I'm not the most experienced and wouldn't want to unwittingly put us at risk of a security breach. If there's no issue then I'll keep my current configuration as is.

Edit, additional question:  A requirement which is leading me to use the group approach is to confirm there's no impact to licensing(if possible), which doesn't appear to be avoidable as is(?). Have you seen any cases where an OOB or custom roles was used to expand access to an application without affecting user licensing? If so I'd love to hear about it so we can avoid the issues mentioned in the first reply. 

Thanks in advance! 

[Allen Andreas · Accepted solution]

Hello,

I suppose that approach is fine, although you didn't really explain why you're not using roles. The role approach allows scalability.

Your approach is limited and would need further maintenance if this requirements grows beyond the one group.

So technically, it's fine, but if you were wanting to scale or prep for scale, then you'd go the role route which is far easier to implement and do anyway.

Either way, it's nice to ask, but if you work at Accenture, which is one of, if not the, largest SN partner, feel free to speak with your peers about this and use an approach that is in line with your CoE, etc.

Not what you personally want to do.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Awae]

Thanks for the guidance on this, I'll edit this into the original post but a requirement is to confirm there's no impact to licensing(if possible), which doesn't appear to be avoidable as is(?). Have you seen any cases where an OOB or custom roles was used to expand access to an application without affecting user licensing? I'm currently writing up the same question to our ServiceNow Representative to see what our options are with roles, while checking here to see if there are any issues with the group approach here. I'll mention the issue with scalability. 

Also it is limited to the one group.

[Allen Andreas]

Hi,

Yes, this type of information is very important to your original post and should be framed as such instead of it appearing as if you may not have taken those things into consideration. So it's nice to see you have.

Expanding the app with or without a role, can still be audited by SN and could be a billable action.

You're best to discuss this with the SN Account Exec, etc.

In the context here of "read only", then SN is more lenient in this regard and it should be fine. Creating a custom role, in and of itself, is not billable. What they do with that role is, but again, even if you opened up other things and did it via group...that's still a loophole in any case. It's just slightly more difficult for SN to track.

Either way, it doesn't necessarily flow well for scalability as mentioned and normal best practices.

Please mark reply as Helpful, if applicable. Thanks!