Skip to main content
This guide is part of the At Scale guides because it is designed for organizations managing access across multiple departments, business units, or workspaces.
Advanced role-based access controls are available only for Enterprise tier accounts.
For organizations with multiple departments or business units, the recommended approach is to remove all workspace access from the Everyone team and then create dedicated teams with access scoped to only what each group needs. This guide walks through the process step by step. Throughout this guide and the RBAC documentation, Cost Reporting items refers to the items managed within workspaces, such as Cost Reports, Dashboards, Folders, Saved Filters, Resource Reports, Kubernetes Efficiency Reports, Financial Commitment Reports, Network Flow Reports, and Canvases.
This guide assumes you are familiar with RBAC concepts like organization-level roles, team-level roles, and workspace access. For an overview, see Role-Based Access Control.

​
Before and After

By default, the Everyone team gives all users access to everything. After setup, the Everyone team is locked down and each dedicated team only sees what they need.

​
Walkthrough

The following steps walk through a typical setup for a large organization. In this example, senior leaders are Organization Owners (who always have full access to everything), while a Finance team manages their own Cost Reports and an Engineering team can only view engineering cost data.
1

Create your workspaces and assign integrations

Before configuring teams, create a workspace for each group or department that needs its own set of Cost Reporting items. For example, create a Finance workspace and an Engineering workspace. See Workspaces for instructions on creating and managing workspaces.Then, assign provider integrations to each workspace. The integrations assigned to a workspace determine what underlying cost data is available there. For example, assign your AWS and Datadog integrations to the Engineering workspace so the engineering team can track infrastructure and observability costs, and assign your Snowflake integration to the Finance workspace so the finance team can monitor data warehouse spend.
By default, any user who can view a workspace can see all cost data from the integrations assigned to it, including Organization Viewers, who can interactively adjust filters and explore reports without saving. Plan your integration-to-workspace mapping carefully before granting teams access. If groups need to share a workspace but must not see each other’s spend, see Restrict Cost Data with Access Policies below.
2

Lock down the Everyone team

Navigate to Settings > Teams > Everyone and set workspace access to No Access for every workspace. This ensures no user sees anything by default. Access is granted only through designated teams.
After this step, non-Organization Owner users will lose visibility into all Cost Reporting items until you assign them to a team with workspace access. Organization Owners are unaffected and always retain full access.
3

Set user organization-level roles

Assign each user an appropriate organization-level role:
  • Organization Owner—For administrators and senior leaders who need full visibility and control. Organization Owners always have full access to all workspaces and Cost Reporting items, so they do not need to be placed on any additional team.
  • Integration Owner—For users who need to manage provider integrations, Virtual Tags, Custom Providers, and Business Metrics but do not need other admin privileges.
  • Organization Editor—For most day-to-day users who need to create and edit Cost Reporting items.
  • Organization Viewer—For users who should only have read-only access.
Navigate to Settings > People, hover over a user, click the ellipses (…), then click Edit to set their role. The People page displays each user’s Organization Role in a dedicated column, making it easy to see role assignments at a glance.
4

Create teams

Navigate to Settings > Teams and create a team for each group that needs scoped access. For example:
  • Finance—Finance team members scoped to the Finance workspace.
  • Engineering—Engineering team members scoped to the Engineering workspace.
You do not need to create a team for Organization Owners—they already have full access to everything. However, if your leadership group wants their own dedicated workspace (e.g., an Executive workspace for sensitive reports), you can create a team for them and scope it to that workspace.
5

Set team workspace access

For each team, go to the Access tab and set the workspace access level:
6

Add members and assign team roles

For each team, go to the Members tab, click Add Members, and assign each member a team-level role:
  • Team Owner—Can manage the team’s Cost Reporting items and control which teams have access to them.
  • Team Editor—Can create, edit, and delete items the team has access to.
  • Team Viewer—Can only view items the team has access to.
For example, a Finance analyst with an Organization Editor role and a Team Editor role on the Finance team will be able to create and edit Cost Reports in the Finance workspace, but will not see anything in the Engineering workspace.A more complex case: your CFO has an Organization Owner role and is also a member of the Finance team. Because Organization Owners always have full access to everything, the CFO can see and edit items in all workspaces, not just the Finance workspace. Their Finance team membership doesn’t restrict them. If you want to limit any user’s visibility to specific workspaces, assign them an Organization Editor role instead and rely on team membership to control their access.
7

Share specific items across teams (optional)

If a specific Cost Reporting item needs to be shared outside of its workspace, use Manage Access on the item itself. For example, say an executive Dashboard lives in the Finance workspace and you want the Engineering team to see it, without granting them access to the entire Finance workspace. Click the ellipses (…) on the dashboard, select Manage Access, and set the Engineering team to Can Access.
For organizations using SSO, you can map SSO groups to Vantage teams to automate team assignment when users log in. You can also manage teams programmatically via the Vantage API or the Vantage Terraform provider.

​
Restrict Cost Data with Access Policies

The setup above works well when each group can have its own workspace. But large organizations often hit a different problem: several teams need to work in the same workspace, share the same dashboards, and look at the same reports, yet each team must only see its own spend. This is common in financial services, in businesses with compliance-sensitive business units, and anywhere multiple product lines are billed through one cloud account. Splitting them into separate workspaces would mean duplicating your entire reporting setup for every group. Access Policies solve this by filtering the data itself rather than controlling which reports a team can reach. A policy is a set of filter rules that you assign to teams; members of those teams then see only matching data, in every report they open.
Access Policies are generally available to Vantage Enterprise customers with contracted Build Hours. If you are not currently eligible, contact the Vantage sales team at sales@vantage.sh.

​
Why This Matters at Scale

Before Access Policies, enforcing a data boundary meant controlling it through report definitions. That forced an awkward trade-off: every restricted user had to be an Organization Viewer, because an Organization Editor could open a report and delete its filters. In practice, that meant a central admin team built and maintained every report for everyone. Access Policies enforce the boundary on the data rather than on how a report was built, so it can’t be edited away. Restricted users can be Organization Editors, build their own reports, and explore freely, and they still only ever see their own scope. For an organization with dozens of teams, this is the difference between a central reporting bottleneck and self-service.

​
Walkthrough

In this example, an investment firm runs several research pods out of a single Research workspace. Each pod must be unable to see any other pod’s cloud spend, but they all share the same dashboards and report templates.
1

Create a team for each group

Following the steps above, create a team per pod—Pod Alpha, Pod Beta, and so on—and give each team Can Edit access to the Research workspace.At this point every pod can see every other pod’s costs. The next step fixes that.
2

Decide what identifies each group's data

Pick the attribute that reliably separates the groups. In most cases this is the account, because each pod’s workloads run in their own linked cloud accounts. Tags work too, if your tagging is consistent.
Build your policies from Provider, Billing Account, Account, or Region using the is comparison whenever you can. These four attributes behave identically across Cost Reports, Active Resources, and Recommendations. Other attributes vary by area: Service does not scope Active Resources, Metadata scopes only Active Resources, and a tag key without a value does not scope Recommendations. See What You Can Filter On.
3

Create one policy per group

Navigate to Settings > Teams > Policies and click Create Policy. For Pod Alpha:
  • Access Policy Name—Pod Alpha accounts
  • Teams—Pod Alpha
  • Access Policy Filters—Account is the list of Pod Alpha’s accounts
Repeat for each pod. Assign each policy to exactly one team so the boundaries stay easy to reason about.
4

Preview before you save

Click Preview on the policy form. Vantage applies that one policy’s draft rules to your own session so you can browse Cost Reports, Active Resources, Recommendations, and dashboards with the proposed boundary.Do this every time. As an Organization Owner you are exempt from Access Policies, so opening a report normally will show you everything and tell you nothing about whether the policy works.Click the X on the amber banner to exit, then click Save Changes.After assigning the policies, open each team’s Access tab and click Preview in the Policies section. This second preview combines every policy assigned to that team. It does not include policies from a person’s other teams, which is why the test-user check in the next step is still important.
5

Verify the boundary with a test user

Sign in as a non-Owner member of one pod, or ask someone on that team to check. Confirm that:
  • Cost Reports show only that pod’s accounts, even after they change filters and groupings.
  • The account picker in the filter builder lists only their own accounts.
  • Recommendations are scoped to their accounts, not the whole organization.
  • A CSV export contains the same data they see on screen.
6

Automate membership with SSO

Map each pod’s SSO group to its Vantage team using SSO group mapping. Team membership is refreshed every time a user signs in, so Access Policies follow people automatically as they join and leave groups. You assign each policy to its team once and never manage it per user.
Access Policies apply across your whole account rather than per workspace, so a policy follows a person into every workspace they visit. If your organization uses a workspace per customer or per environment, make sure the accounts a policy names exist in every workspace its teams can reach. A policy listing only production accounts will make that team’s reports come back empty in a development workspace.
Forecasts and anomalies stay available for anyone with an Access Policy applied, and both are limited to the data the policy allows. After a policy’s rules or a team’s membership changes, the Forecasts and Anomalies tabs can be empty until Vantage next generates them.

​
Frequently Asked Questions

Yes. Any user with view access to a workspace can see all cost data from the integrations assigned to that workspace. Organization Viewers can also interactively adjust filters, date ranges, and groupings on Cost Reports to explore the data. These changes are temporary and are not saved. If you have sensitive cost data that should be restricted, assign those integrations only to workspaces that the appropriate teams can access, or restrict the data itself with Access Policies.
Access Policies are combined so that a person sees data matching any of their teams’ policies. Each team is another pass that adds to what they can see, so adding a team always widens access rather than narrowing it.To tighten what someone sees, either remove them from a team or narrow the policy on the team they’re already on. If a user genuinely needs a combination that no single team represents, create a dedicated policy describing exactly what they should see and put them on one team with that policy.
Vantage applies one policy across Cost Reports, Active Resources, and Recommendations, but those areas don’t all describe data the same way. Recommendations honor Provider, Billing Account, Account, Region, Service, and tag key-value pairs. The rules Recommendations can’t interpret are a tag key without a value and Untagged, so a policy built only from those won’t narrow this page.Add a rule using one of the supported attributes, then use Preview to confirm each area is scoped. For a reliable boundary, build policies from Provider, Billing Account, Account, or Region. See What You Can Filter On.
Each provider integration (e.g., an AWS account or Datadog connection) is assigned to one or more workspaces. This determines which cost data appears in each workspace. RBAC controls who can access each workspace, so the combination of integration assignment and team workspace access controls who can see what cost data. For example, if your AWS production integration is only assigned to the Finance workspace, only teams with access to the Finance workspace can see that data.
All items remain in their workspaces, nothing is deleted. However, non-Organization Owner users will immediately lose visibility into any item they could previously see through the Everyone team. Make sure you have your teams and workspace access configured before (or immediately after) locking down the Everyone team.
Yes. A user can belong to as many teams as needed. If a user is on multiple teams that have access to the same item, they receive the highest permission level from any of those teams. See Role Precedence for details.
Place them on two different teams: one with Can Edit access to the first workspace and another with Can View access to the second. Their permissions are evaluated per workspace, so they can edit in one and only view in the other.
Yes. Navigate to Settings > Teams > Everyone, go to the Access tab, and set the workspace access back to Can Edit or Can View. All users will immediately regain access through the Everyone team.
No. Organization Owners always have full access to all workspaces and Cost Reporting items, regardless of team configuration. The lockdown only affects users with Organization Editor, Integration Owner, or Organization Viewer roles.
Yes. API service tokens created at the team level inherit that team’s permissions. A token created for the Finance team will only have access to items the Finance team can see.Important: Service tokens used for organization-level actions—such as managing provider integrations or creating teams—must be assigned to the Everyone team. This applies to tokens used by the Kubernetes agent and the Terraform provider. Tokens assigned to other teams will not have the necessary permissions and may encounter authorization errors.
No. You have several options for managing team membership at scale: