Overview
The Departments feature allows customers to group vendors into manageable subsets and control user access to them. This department-based visibility model enables more precise vendor access governance, aligning with how organizations operate across distributed teams and business units.
With Departments, you can:
- Associate vendors to departments to control visibility.
- Associate users to departments.
- Restrict vendor visibility for users based on their departmental associations.
- Display and filter the vendor list by department.
Accessing Departments
Navigate to: Assessment Setup > Departments
On this page, you’ll find a searchable, sortable list of all existing departments. Departments Table includes:
| Column | Description |
| Name | Name of the department |
| Vendor Count | Number of vendors associated with the department |
| User Count | Number of users associated with the department |
Additional functionality:
- Search by department name
- Total Department Count displayed at top
- Add / Edit buttons to manage departments
- Delete with confirmation modal
Deleting a Department removes vendor visibility restrictions granting users access to vendors previously limited to this department.
Creating or Editing a Department
When adding or editing a department, you’ll be guided through a three-step wizard: Assign Vendors, Assign Users, and Review & Confirm. This flow ensures you can configure visibility controls clearly and efficiently.
Step 1: Assign Vendors
Name the department:
This is a required field and can be up to 120 characters. If you’re editing an existing department, the name will already be filled in and can be updated.
Assign vendors:
Select vendors you want to associate with this department. You’ll see a list of all vendors. You can filter the list by connection type, tags, or life cycle status, or search by vendor name or domain.
As you select vendors using checkboxes, they appear in a dedicated panel on the right. This panel lets you review your selections, remove individual vendors, or clear all with a single click.
Use the “Next” button at the bottom right or the “Go to Next Step” link at the top right to proceed to the next step.
Step 2: Assign Users
Select the users who will have visibility into the vendors selected in Step 1. All existing portal users are shown in the table and can be filtered by status or role, or searched by name or email. Users can be assigned to multiple departments, and departments can be created with only vendors (users are optional).
Selected users appear in a right-side panel similar to the one in Step 1. Here, you can remove individuals or clear the entire selection. Assigning users is optional, and departments can be created with only vendors if needed.
Continue to the final step by using the “Next” button or the top-right navigation link.
Step 3: Review and Confirm
This final step summarizes your department setup. You’ll see a list of the vendors and users you’ve selected, along with a summary panel showing the department name and total counts for vendors and users.
Clicking Save Department completes the department setup.
Departments: Vendor Access Governance
Departments provide several key benefits to organizations, including:
- Limiting vendor access based on team or function.
- Mitigating the risk of overexposure.
- Enhancing administrative efficiency.
- Facilitating scalable, distributed Vendor Risk Management (VRM) operations.
How Departments Work with Other Access Controls
Departments serve as the primary visibility control in VRM. A user must be associated with a department that includes the vendor in order to see and interact with that vendor—regardless of their assignments or role.
Other access features like Internal Contacts, Assignments, and Roles define what users can do only after visibility has been granted by a department.
Clarifying Each Component
- User Roles & Permissions: Defines what a user can do on a vendor if they have access to it.
- Departments: Defines which vendors a user can see — it's about visibility.
- Internal Contacts: Defines specific assignment-based access to a vendor — typically scoped access tied to a task or functional participation.
- Assignments: Triggers inclusion into Internal Contacts and notifies the user; it's the action that initiates engagement.
| Feature | Controls | Overrides? | Notes |
| Departments | Visibility | Not overridable | Primary gatekeeper for vendor access |
| Internal Contacts | Engagement | Only works if department grants access | Used after access is granted |
| Assignments | Engagement | Doesn't grant access unless visibility exists | Adds user to contacts, no access unless visible |
| Roles | Permissions | Cannot override visibility | Actions depend on permissions, not access |
Example Scenarios
Understanding how Departments, Assignments, and Roles interact is key to managing access. Below are four common scenarios that demonstrate how visibility and permissions work together.
Scenario A
An user with the Internal Business User role is assigned a task for Vendor A, but the user is not part of the department that Vendor A belongs to.
- Result: The user cannot see Vendor A in the platform and cannot perform any actions, even though they’ve been assigned.
- Why: Assignments alone don’t grant visibility—department alignment is required first.
Scenario B
The user with the Internal Business User role is part of the same department as Vendor A and has been assigned a task for that vendor.
- Result: The user can see Vendor A, is listed in Internal Contacts, and can perform actions (based on their role), except for certain restricted actions like Assessment Setup.
- Why: The user meets both requirements—visibility through department and engagement through assignment.
Scenario C
The user with the Internal Business User role is not in any department but is assigned a task for Vendor A, which does belong to a department.
- Result: The user can see Vendor A and take permitted actions.
- Why: In this case, having no department doesn’t block access if the vendor has one. The assignment adds them to Internal Contacts and grants visibility.
Scenario D
The user with the Internal Business User role is in a department, but Vendor A does not belong to any department. The user is assigned a task for Vendor A.
- Result: The user cannot see Vendor A and cannot take any action.
- Why: Because Vendor A has no department, the user’s own departmental access rules prevent visibility. Assignments and Internal Contacts do not override this.
- August 13, 2025: Published.
Feedback
0 comments
Please sign in to leave a comment.