Automating Group Access Replication via Flow Designer: Need Solution for Preventing Privileged Group

[VianyNidamanuri]

Hi Community,

I need advice and a recommended solution for handling security restrictions in an automated group replication flow.

Requirement:

We have an automation in Flow Designer for a System Access catalog item. When a user requests access by providing a "Model User" (model_after variable) with the replicate access checkbox enabled:

The flow looks up all active groups belonging to the model user (sys_user_grmember).

It loops through each record and adds the target user to those groups.

It updates the Catalog Task (sc_task) state to Pending with work notes detailing the replicated groups for manual review by the fulfillment team.

Issue / Risk Identified:

During our architecture review, a critical security issue was raised:

Over-Privileged Model Users: In many cases, a model user may already belong to high-privilege, administrative, or configuration groups (e.g., ServiceNow Development, Admin, or sensitive production roles) that the requester should never receive.

Immediate Assignment: Because the flow adds the group memberships first and then sets the task to Pending for review, unauthorized access is active in the system before anyone has verified it.

Question:

What is the recommended ServiceNow best practice or architecture pattern to solve this?

Specifically:

How should privileged/sensitive groups be excluded from automated replication?

How should the workflow be structured so unauthorized access is never granted prior to verification, while still saving fulfillers from manual assignment effort?

Any guidance on the standard solution for this scenario would be appreciated.

[OlaN]

Hi,

Ideally you would have the assignment happening after some form of approval, where the approver can deselect sensitive groups that should not be copied. Then again you will face the risk that the approver doesn't know which these sensitive groups are, and just approves without review. And then the approval will be useless.

In generic terms you will always face this issue when going for a replication-like-behaviour, you end up selecting a user that has too much rights, because you want to make sure the new person has everything they need.

Another way of solving it is to define specific roles that grant various access and use that for 80-90% of the request cases. (for example a role of a XX grants access to group AA, BB and CC, role YY grants access to group AA, DD, EE and so on).

And for all those special sensitive groups you should have a person responsible for approving requests to access those groups, and handle those requests separately.