A group is a named collection of users in your organisation. You manage groups under Settings › Groups, where you can create a group, give it a description, and add or remove people. Groups are how you organise your workforce inside Venvera so you can hand work to a team instead of chasing individuals.
Creating a group
Creating and editing groups requires the User Management permission (the same permission that governs Settings › Users). Anyone in the organisation can see the list of groups; only users with that permission see the create, edit, and delete controls.
Go to Settings › Groups. Existing groups are listed with a member count next to each name.
Give the group a Name (required) and an optional Description. Use the name you would use for the department itself, such as "Risk" or "IT Operations".
The group appears in the list immediately. Group names must be unique within your organisation - if you reuse a name, Venvera tells you a group with that name already exists.
To rename a group or change its description later, use the pencil icon on its row. Deleting a group (the trash icon) removes the group and its membership; it does not delete the underlying user accounts, and any tasks or change requests that referenced the group simply lose that attribution.
Adding and removing members
Click a group's row to expand it and reveal its members. From the expanded panel you can add a user and remove existing ones.
Click the group name to open it. Current members are shown with their name and email.
Pick a person from the Add member dropdown (only users who are not already in the group appear), choose a Role, and click Add. You can only add users who already belong to your organisation.
Click the remove icon next to a member to take them out of the group. This does not affect their account or any other group they belong to.
Member and lead roles
| Role | What it means |
|---|---|
| Member | A regular member of the department. The default role for anyone you add. |
| Lead | A designation you can use to mark who runs the department, for example the department head or team lead. Members with this role show a Lead badge in the group. |
What groups (departments) are used for
Assigning tasks to a whole department
When you create or edit a task, the assignee picker lets you choose either an individual user or a group. Assign a task to a group and it becomes the whole department's work: every member of that group sees it in their Tasks list, and administrators can filter the task list by group to see everything on a given department's plate. A task is assigned to a user or a group, never both at once - picking a group clears any individual assignee.
This is the practical reason to model departments as groups. Instead of guessing which analyst should own a piece of remediation, you route it to "Payments" and let the team pick it up.
Attributing a change request to a department
In Change Management, a change request records who is behind it. The Requested by, Change owner, and Approving fields can each be set to a Department - which is one of your groups - so the record shows, for instance, that the Payments department requested a change and the Risk department is approving it. (These same fields can alternatively point to a branch of the organisation; a Department is one of the two kinds of party a change request can name.)
Mirroring your Microsoft Entra ID groups
If your organisation has connected the Azure / Microsoft Entra integration under Integrations and consented the Group.Read.All permission, the Groups page shows your Entra ID / Microsoft 365 groups read-only alongside your Venvera groups. You can expand each one to see its membership.
This is a reference view, not an automatic import: it lets you see how your directory is structured so you can recreate the same departments as Venvera groups and keep membership aligned by hand. Venvera does not push or pull membership automatically. If the integration is not connected, or the permission has not been granted, the page tells you what is missing and links you to Integrations.
Scenario: standing up departments at a bank
Priya, Head of Operational Resilience at a mid-size European bank, is setting up Venvera for her second-line teams. She opens Settings › Groups and creates four groups: Risk, Payments, IT Operations, and Compliance. For each she writes a one-line description and adds the relevant staff, marking each department head as a Lead so it is obvious who runs each team.
A week later a card-scheme deadline lands. Priya creates a task, "Complete quarterly PCI network scan", and assigns it to the Payments group rather than to a single engineer. Everyone on the Payments team now sees it in their Tasks list, and Priya can filter tasks by Payments to watch the department's workload without micromanaging who picks it up.
Shortly after, the Payments team proposes migrating the card-authorisation service to a new provider. In Change Management the change request is raised with Requested by set to the Payments department and Approving set to Risk. The record now reads cleanly at audit time: a named department asked for the change, and a named department signed it off - no ambiguity about which team owned the decision.