When it comes to orchestrating and testing recovery workflows across multiple sites or infrastructure types, granular control is crucial - not only for efficiency but also for security and accountability. This is where Scopes and Roles in Veeam Recovery Orchestrator (VRO) shine.

In this post, we will explore:

• What roles and scopes are in VRO
• How to set up and use scopes effectively
• Two real-world use cases for scopes
• A breakdown of VRO roles and permissions

Scopes in Veeam Recovery Orchestrator:

Scopes in VRO are logical boundaries that define what resources a specific user or group can see and manage. This includes orchestrated plans, recovery locations, workloads, and more. By configuring Scopes, Scope Users (and Groups), and Scope Inventory, you can segment access by site, team, or technology stack.

By default, there are two scopes:

Default Scope - this is created as part of the installation. By design, all items discovered are added to this scope. This includes items enumerated from any connect Veeam Backup and Replication server, supported hypervisor, and storage platform.

You can remove items from the Default Scope but it is advised that additional scopes be created to provide more granular permissions.

All Scopes - this is technically not a separate scope, but rather a privileged view that allows users, typically administrators, to see and manage resources across all other scopes that exist on the system.
 

You can select which scope(s) that you can view by selecting the “Scopes” button / link in the upper left-hand corner of the VRO UI:
 

Roles in Veeam Recovery Orchestrator:

VRO provides role-based access control (RBAC) to define what actions users can take. There are three defined roles in VRO:
 

The following table describes the access available to users with different roles in the Orchestrator UI.
 

Roles work within the context of a scope. As a result, a user can be an Operator in “Scope A” and a Plan Author in “Scope B”, enabling precise access control.

Let’s now discuss two use cases for VRO Scopes and Roles:

Use Case 1: Regional Access – One Headquarters, Two Remote Offices

Scenario:

A company has its headquarters in Toronto, with remote offices in Halifax and Edmonton. The IT team in Toronto manages the overall recovery strategy, but each remote office has a local admin responsible for their site’s workloads.

Objective:

• Toronto admins should see and manage all resources.
• Halifax and Edmonton admins should only see and manage their own site's workloads.

How Scopes Help:

1. Create three scopes:
   1. Select “Administration” (top right corner of the UI)
   2. Select “Scopes” (Under Permissions in the left-hand menu)
   3. Add the applicable scope(s)
      1. Toronto Scope for Toronto admins
      2. Halifax Scope for Halifax admins
      3. Edmonton Scope for Edmonton admins

2. Assign Scope Users / Groups to Roles
   1. Select “Administration” (top right corner of the UI)
   2. Select “Scope Users” (Under Permissions in the left-hand menu)
   3. Select “Add Account”
      1. Select the account type (User / Group)
      2. Select the account
      3. Add the account

1. 1. 4. Assign the role and scope
         1. Select the role
         2. Select the Scope

3. Assign Scope Inventory:
   1. Select “Administration” (top right corner of the UI)
   2. Select “Scope Inventory” (Under Permissions in the left-hand menu)
   3. Select the applicable Veeam, storage, or hypervisor tag and assign the applicable scope(s) based on location

Now that the scopes, scope users, and scope inventory has been configured, when a user logs into VRO, they will be only allowed to view and manage the object within their defined scope. Here is an example of a user from the “Halifax Scope” and what they will see in the VRO UI:
 

Note how only the items in the “Halifax” scope are shown.

Use Case 2: Access by Technology Stack – VMWare vs Hyper-V Teams

Scenario:

All admins are in the same data center, but responsibility is divided by hypervisor platform:

•           VMware Admins handle vSphere-based workloads.

•           Hyper-V Admins handle Hyper-V-based workloads.

Objective:

Each team should only have the ability to initiate recovery and testing for their specific platform.

How Scopes Help:

1. Create two scopes:
   1. VMware Scope
   2. Hyper-V Scope
       
2. Tag or organize resources by platform in the Veeam console (e.g., using vCenter tags or SCVMM groups).
    
3. Assign Scope Inventory to include only those workloads relevant to each hypervisor.
    
4. Map Scope Groups:
   1. VMware_Admins_AD_Group → VMware Scope
   2. HyperV_Admins_AD_Group → Hyper-V Scope

Whether you need to limit visibility based on geography, organizational unit, or technology responsibility, Scopes and Roles in Veeam Recovery Orchestrator give you a flexible and secure way to delegate recovery management.

By leveraging scopes:

• You reduce risk by preventing unauthorized changes.
• You empower local or specialized teams to manage their own environments.
• You maintain clear boundaries without sacrificing centralized oversight.

As for next steps, I would propose:

• Audit your environment and identify natural groupings for scopes.
• Use AD groups to simplify user management.
• Implement roles based on least-privilege access principles.
• Document and test your scopes to ensure visibility and permissions are behaving as expected.

If you're already using VRO and haven't explored scopes yet—now is the time.