Best practices for managing (adding user to group) entra ID users with flows?

[Tone1]

Hello,

We are looking to use the Entra ID Spoke to allow users to have their group memberships managed via requests and workflows in ServiceNow.

The primary use case for this is managing membership in Microsoft Teams groups.

We are having an internal discussion about whether the Entra ID Spoke is a practical way to handle this. Some team members are concerned that multiple API hits could negatively impact usability and create latency for the end-user during the request process.

Does anyone here have experience with this?

As a potential solution for latency problems with synchronous API calls, we've considered storing the entire Entra ID structure—with all users and groups—in our CMDB. We would then read the current state from the CMDB for any checks and only push the final changes to Entra ID via the API.

Would this be necessary, or is the latency from using the API directly generally negligible?

Thanks in advance.

[Tone1]

No one any idea about this?

[Ravi Gaurav]

Hi @Tone1 

Best Practices for Managing Entra ID Group Membership via ServiceNow Flows

Using the Entra ID Spoke to manage group membership (especially for Teams groups) is a common and supported approach. The key is balancing real-time accuracy with performance and usability.

1. API Latency Considerations

• Each Flow action (e.g., Add user to group, Check membership, Get group) is a synchronous API call to Microsoft Graph through the Entra ID Spoke.

• Typical latency is a few hundred ms per call; for a single request (add/remove user), this is generally negligible for end users.

• Issues arise if you design a Flow that loops through many groups/users in one transaction (hundreds or thousands of API hits).

Best practice:

• Keep synchronous user-facing flows short (≤ 2–3 Entra API calls).

• For bulk operations, run asynchronous scheduled jobs or subflows in the background.

2. Should You Mirror Entra ID in the CMDB?

• Storing all users and groups in CMDB is usually not recommended:

  • The data volume is very high (tens of thousands of groups/users).

  • It requires frequent sync jobs (every few minutes) to stay current, which defeats the purpose of offloading API latency.

  • Adds overhead and potential data drift (your CMDB state may not match Entra ID at the moment of change).

Better approach:

• Store only reference mappings in ServiceNow when needed (e.g., a catalog of business-critical groups or user→manager relationships).

• For actual membership checks and updates, call Entra ID directly via the Spoke to guarantee accuracy.

3. Design Patterns for Flows

• User Self-Service Request → Flow Designer

  1. User submits catalog item (e.g., Request access to Team XYZ).

  2. Flow calls Get Group (1 API hit).

  3. Flow calls Add Member to Group (1 API hit).

  4. (Optional) Log result in CMDB or task notes.

• Bulk/Approval-Driven Operations

  • For large approvals (e.g., 50+ users), collect all requests first, then trigger a scheduled job or asynchronous subflow to push changes in batches.

• Error Handling

  • Always build retries (Microsoft Graph APIs occasionally throttle with HTTP 429).

  • Entra ID Spoke supports error outputs → route to “Re-try later” logic or escalation tasks.

4. Security & Governance

• Use a dedicated integration account in Entra ID with the least-privilege roles required (e.g., Groups Administrator).

• Audit group membership changes in ServiceNow (store who requested, approver, time).

• Consider pairing with ServiceNow IAM workflows if broader lifecycle management is needed.

Conclusion

• Direct Entra ID Spoke calls are generally fine for interactive requests (latency is negligible for 1–3 API hits).

• Don’t replicate the full Entra structure into CMDB—too heavy, and risks stale data.

• Use CMDB/reference tables only for key business groups if you need catalog visibility.

• For bulk changes, offload to async jobs to avoid hitting throttling limits.

[evelyn69mohr]

Using the Entra ID Spoke for managing group memberships in ServiceNow is a practical approach. Latency from direct API calls is generally negligible for typical request processes, so storing the entire Entra ID structure in your CMDB is unnecessary and could introduce data synchronization challenges. The spoke is designed to handle these requests efficiently without significant performance issues.