# User Groups > Name a team once, point permissions and policies at it, and let the membership do the rest. - Author: Giulio Pezzulli (Principal Software Engineer) - Published: 2026-10-15 - Category: Product - Canonical: https://dfns.co/article/user-groups/ - All DFNS articles: https://dfns.co/llms-full.txt --- Every institution on DFNS wants to know who holds which permissions and who sits in which approval group. Until now, both lists named individual users. That’s precise, but it’s also how access control decays. On most platforms, approval policies name specific people. When someone joins or leaves the treasury team, an admin must manually update every policy that mentions them. Do that for a year and you end up with dozens of hand-maintained user lists that no one fully trusts. User Groups fix that. A User Group is an organization-scoped collection of users that can be referenced as a single entity anywhere DFNS expects an individual to hold permissions or approve a policy. People can now move in and out of the organization without anything needing rewriting. ## What a User Group does Two simple things. 1. It holds permissions. Assign a permission to a group exactly as you would to a user, and every member inherits it. A user’s effective permissions are the union of their own and those of every group they belong to, so a new member of the trading team can act the moment they join, and loses that ability the moment they leave, everywhere at once. 2. It approves. A policy can name a group as an approver instead of enumerating people. Approval quorums are then drawn from the group’s current membership, so the people who vote are the people on the team today, not the people who were on it when the policy was written. Membership is explicit. Someone with the right permissions adds and removes members, each change signed as a user action, each recorded. An auditor can trace every membership change to the signed action that caused it, and tell a directly held permission from an inherited one. ## Groups are a way to grant power, so they are governed like one Adding someone to a group gives them the permissions assigned to that group. If the group has administrative rights, adding a member grants those rights too. That is why adding and removing members, and renaming groups, follow the same rules as assigning permissions directly: these actions cannot be granted through managed permissions to non-administrators, and as the Policy Engine’s coverage of user actions extends to group operations, they will fall under the same approval requirements as permission changes. The goal is one standard for granting power, however it is granted. The same rules close the main ways group permissions could otherwise be misused: * **Recreating a group.** Deleted group names remain reserved, so a group cannot be recreated with different permissions. * **Renaming a group.** Renaming is a signed, auditable action and follows the same requirements as other permission changes. * **Adding yourself as an administrator.** This requires the appropriate permission and leaves an audit record. * **Removing the last administrator.** A safeguard prevents the last administrator from being removed, either directly or by deleting their group. * **Nesting groups.** Groups cannot be added to other groups. * **Adding end users.** End users cannot be added to groups. * **Using an existing token after gaining permissions.** Personal access tokens keep the permissions they had when created. Joining an administrator group does not expand them. * **Using an administrator token after losing access.** Each request checks the user’s current permissions, so the token stops working for administrator actions once that access is removed. ## Scope at launch User Groups are organization-scoped, with members drawn from Organization Users and Tenant Users. Groups hold identity permissions, the ones that govern platform access and administration. Resource-level rights, such as releasing a vault lock or using a delegated key, remain directly assigned for now, and group support for them is additive. A policy can name up to 10 groups as approvers. Every group and membership change emits an event, so your systems and your SIEM see it the moment it happens. Groups are soft-deleted, so history is never destroyed. ## Availability User Groups are rolling out gradually. Creating groups, managing membership, and assigning permissions to groups are available now for organizations enabled for the feature, and naming a group as an approver in the Policy Engine follows this week. To enable User Groups for your organization, contact your account manager or [sales@dfns.co](mailto:sales@dfns.co). ## What’s next For most institutions, the authoritative list of who is on which team does not live in DFNS. It lives in the identity provider. Synchronizing group membership from your IdP, so that a group in DFNS follows the matching group in your directory at every login, is the next step for User Groups, and it deserves its own post. It’s coming soon. ## Get started * Learn more about onchain core banking: [dfns.co](https://dfns.co/) * Explore the platform and documentation: [docs.dfns.co](https://docs.dfns.co/) * Talk to our team about User Groups: [sales@dfns.co](mailto:sales@dfns.co)