Owner Provisioning

A user who doesn't already exist in Snapdragon Guardian cannot be added directly as an owner of a Permission Group (PATCH /qrms/permissionGroups/{id}/owners). This will be fixed in a future release.

Workaround:

1. First add the user as a member of the Permission Group — this provisions them in Snapdragon Guardian:

   PATCH /qrms/permissionGroups/{id}/members

   {
     "action": "add",
     "userIds": ["newuser@qualcomm.com"]
   }

2. Then add them as an owner:

   PATCH /qrms/permissionGroups/{id}/owners

   {
     "action": "add",
     "userIds": ["newuser@qualcomm.com"]
   }

3. If they don't need to remain a member, they can be removed from membership afterward without affecting their ownership:

   {
     "action": "remove",
     "userIds": ["newuser@qualcomm.com"]
   }

See Device / Permission Groups for full details on the members and owners endpoints.

Superuser and User Group Membership Sync Delay

Superuser role and Permission Group membership synced from a directory group (Entra ID / company group) are not real-time — they depend on a periodic sync interval on the User Management (UM) service, plus a user context cache on Snapdragon Guardian.

Concretely:

• After attaching a directory group to a Permission Group (PATCH /qrms/permissionGroups/{id}/groups), directory sync starts, which can take a few minutes before members are reflected.
• Adding or removing a user from the underlying company directory group itself (e.g. in Entra ID) is not immediate either way — UM only learns about that change on its next periodic sync/refresh. A newly-added user won't get access, and a removed user won't lose it, until that sync runs.
• Once UM's sync reflects a removal, Snapdragon Guardian still caches each user's permission group IDs and system role for Cache:TtlSeconds (default 60 seconds, configurable in appsettings.json). A removed user retains their old access for up to this TTL on top of the UM sync delay — there is currently no early-invalidation or purge endpoint.

Practical impact: both granting and revoking access via directory group membership changes are subject to UM's sync interval, and revocation has the Cache:TtlSeconds delay stacked on top. For deployments requiring fast revocation, keep Cache:TtlSeconds low (≤ 30s).

Configuring the sync interval: the periodic sync interval is configured on the UM service, separately for group membership and for superuser role sync:

UM_SYNC_USERGROUPGROUPS_TIMERINMINUTES controls how often UM refreshes company directory group membership for Permission Groups (see Add or Remove Company Directory Groups in Device / Permission Groups). UM_SYNCSYSTEMROLES_TIMERINMINUTES controls how often UM refreshes SUPERUSER_QGROUP membership to grant/revoke the Superuser role. Lower these for deployments that need faster revocation, keeping in mind more frequent syncs increase load on the directory provider.