From ORGADMIN to Control Plane: Organization Hub, Organization Users, and Premium Views in Practice

Running Snowflake in the Agent Era, Part 2 of 4. Part 1 made compute flexible inside one account. This part is about the one account that sees all the others.

When someone asks “what did we spend last month” or “who has ACCOUNTADMIN where”, the honest answer starts with “give me a while, I need to check each account”.

Part 1 of this series, “Stop Picking T-Shirt Sizes: What Running Adaptive Compute Taught Me”, ended on three questions that Adaptive Compute does not answer. Who can create warehouses across accounts? Where is cost visible for the whole estate? How do identities stay consistent?

Those questions are not abstract for me. Our estate is a multi-account setup spread across more than one cloud, and every account has its own SCIM or IdP integration. That is how users and roles reach each account from our identity provider (IdP), the system that manages our people’s identities. SCIM (System for Cross-domain Identity Management) is the standard Snowflake supports for provisioning them from it.

Snowflake now has one account whose entire job is the estate: the organization account. Several of its pieces became generally available during 2026. I want to be clear about where this post comes from. I have not run the organization account on our estate yet. Everything here comes from reading the documentation and release notes closely and watching demos, and it ends with what I would do. One status check first, because Part 1 promised it: as of 11 October 2026, the docs still mark the organization-wide QUERY_METERING_HISTORY view as “Coming soon”.

Three questions Part 1 left open

A quick recap without repeating Part 1. Every Adaptive Warehouse in an account runs on a shared pool of compute that is dedicated to that account. Per-query cost for Adaptive Warehouses lives in QUERY_METERING_HISTORY in ACCOUNT_USAGE. So per-query cost is collected account by account, and an estate with many accounts has many places to look.

Agents make this worse in a quiet way. A session with CoCo, Snowflake’s built-in AI agent, in one account, a pipeline agent in another, a service user in a third. Each one is easy to reason about alone. Together, across clouds, they are an estate nobody sees in one place.

The account above the accounts

The organization account (generally available since 27 January 2025) is a special type of account that organization administrators use for tasks that affect the entire organization. There is only one per organization, and it needs Enterprise Edition or higher.

From it, administrators can:

• View organization-level data collected from all accounts, including each account’s query history.
• Manage organization-level objects, such as organization users, for all accounts or a subset.
• Manage the lifecycle of accounts, including creating and deleting them.
• Enable replication for an account and enable Marketplace terms for the whole organization.

The part that stood out most in the docs was the split between two administrator roles. Before the organization account, organization tasks ran under ORGADMIN in an ORGADMIN-enabled regular account. That approach is being phased out for multi-account organizations. The replacement is GLOBALORGADMIN, which lives in the organization account. Snowflake says it will email customers at least three months before ORGADMIN is phased out. Until then, both roles exist, and by default ORGADMIN can be enabled in at most eight accounts.

That transition matters more than it sounds. If your runbooks, scripts, or IaC (infrastructure as code, where roles, grants, and other setup live in version-controlled files) say USE ROLE ORGADMIN, they point at the old model. Moving them is a small job with a deadline you do not control yet.

You create the organization account from an existing ORGADMIN-enabled account, using CREATE ORGANIZATION ACCOUNT. You cannot convert an existing ORGADMIN-enabled account into the organization account. And creating it is not free: it populates the ORGANIZATION_USAGE schema with premium views, which incur additional costs. More on that below.

Who can create warehouses across accounts

Here is the honest answer, and it surprised me a little: not the organization account.

CREATE WAREHOUSE is an account-level privilege, and it must be granted by ACCOUNTADMIN in that account. The lifecycle privilege the organization account hands out is MANAGE ACCOUNTS, which covers creating and deleting accounts, and it is granted by GLOBALORGADMIN. So the organization account decides which accounts exist. It does not decide who creates warehouses inside them.

What it does give you is two things that make warehouse control consistent across accounts.

The first is consistent roles. When an account administrator imports an organization user group, it becomes a role with the same name in that account. Same group, same role name, in every account that imports it.

The second is visibility. The WAREHOUSE_EVENTS_HISTORY premium view in the organization account records warehouse events across accounts, including creating, dropping, and altering a warehouse. Each row carries USER_NAME (who initiated the event) and ROLE_NAME (the role active at the time).

This is how we control warehouse creation, and how I would extend it with the organization account:

1. In each account, an IaC-managed platform role is the only role that holds CREATE WAREHOUSE.
2. The people allowed to use that platform role come from one imported organization user group, so the group’s role has the same name and the same members in every account. If the account administrator needs to grant that imported role to a local role, the group must be created with IS_GRANTABLE = TRUE.
3. WAREHOUSE_EVENTS_HISTORY audits after the fact, across every account, from one place.

A first audit query, following the docs’ advice to bound every scan on history views and list columns explicitly:

USE ROLE GLOBALORGADMIN;
SELECT account_name,
       warehouse_name,
       event_name,
       event_state,
       user_name,
       role_name,
       timestamp
FROM SNOWFLAKE.ORGANIZATION_USAGE.WAREHOUSE_EVENTS_HISTORY
WHERE timestamp > DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY account_name, timestamp DESC;

Anything in that result with a role_name other than the platform role is a conversation worth having.

One pane for cost and health

The visibility comes from premium views (generally available since 24 June 2025). These are views in the ORGANIZATION_USAGE schema of the organization account that are not available in a regular account. They mirror ACCOUNT_USAGE views but cover every account. For example, TAG_REFERENCES in the organization account shows how tags are used across the whole organization, not just one account.

Two details in the docs deserve attention before anyone promises a dashboard:

• They cost money. Premium views incur additional costs based on how many records were processed to generate them. The rate is in the Organization Usage table of the Snowflake Service Consumption Table. By default they are only available to organizations with a capacity contract; on-demand organizations go through Snowflake Support.
• They take time to fill. It can take two weeks after the organization account is created before premium views hold the full 365 days of history.

2026 made them more useful. In February, Snowflake added METERING_HISTORY (hourly credit usage for each account) and QUERY_ATTRIBUTION_HISTORY (compute cost attributed to queries on warehouses across the organization) as premium views. In September, QUERY_HISTORY, LOGIN_HISTORY, ACCESS_HISTORY, and METERING_HISTORY dropped to a typical latency under 15 minutes, down from up to 3 hours.

On top of these views sits Organization Hub. Its Insights page (generally available since 3 August 2026, after a public preview from 1 June 2026) shows interactive tiles for the whole organization, so you do not have to sign in to each account. It has three sections: Billing and Cost (total cost, cost by service type, storage, contract utilization), Security (Trust Center violations, authentication methods, admins, dormant users), and Query health. Reading the tile list, the Query health tiles were the ones I wanted most: failed queries, warehouse concurrency load, and the most expensive grouped queries, grouped by parameterized hash, across every account.

Access is where the design is good. There is no separate Insights privilege. Every tile reads an ORGANIZATION_USAGE view, so a role sees the tiles its application roles allow, and the rest of the page still works. You can give a FinOps analyst ORGANIZATION_BILLING_VIEWER and a security lead ORGANIZATION_SECURITY_VIEWER without handing either of them GLOBALORGADMIN. Query-level tiles need ORGANIZATION_GOVERNANCE_VIEWER, and credits, storage, and warehouse load need ORGANIZATION_USAGE_VIEWER. Organization Hub also runs its queries on a warehouse, so the role needs USAGE on one.

Organization Hub’s other half is Command Center (generally available since 30 September 2026), and only GLOBALORGADMIN can open it. Its Organization Features tile shows whether premium views are enabled. You cannot switch them on or off there; that still goes through Snowflake Support. Its 3rd party access configuration tile classifies accounts as internal or external and maintains allowed email domains.

Two smaller items for the agent era. SNOWFLAKE_COCO_USAGE_HISTORY (generally available) is in ORGANIZATION_USAGE as well, so CoCo credits can be seen across accounts; Part 3 goes deeper on that. And CoCo ships an organization-management skill for analyzing accounts, organization users, and org-wide spend from a prompt.

The per-query gap is still open

This is the status check Part 1 promised. On 11 October 2026 the documentation for the organization version of QUERY_METERING_HISTORY says:

Coming soon: The QUERY_METERING_HISTORY view is not yet available in the ORGANIZATION_USAGE schema. Use QUERY_METERING_HISTORY view in ACCOUNT_USAGE for per-query credit usage on Adaptive Warehouses.

There is no date and no preview label. When it ships, the docs say it will return per-query credit usage for Adaptive Warehouses across accounts, with ORGANIZATION_NAME, ACCOUNT_LOCATOR, and ACCOUNT_NAME added to the account-level columns.

Until then, the advice from Part 1 stands: collect the ACCOUNT_USAGE view per account. I would not lean on the organization QUERY_ATTRIBUTION_HISTORY to fill the gap for Adaptive Warehouses, because the docs do not say it covers them.

One identity, many accounts

This is the part of the organization account that would change our day-to-day the most.

An organization user (generally available since 23 January 2026) is a global user entity created in the organization account and imported into regular accounts. Accounts do not import users one by one. They import organization user groups, and importing a group adds its users and creates a role with the group’s name.

The documented workflow:

1. GLOBALORGADMIN creates organization users and an organization user group, then adds the users.
2. GLOBALORGADMIN sets the group’s visibility: all accounts, or a list of accounts.
3. In each regular account, an administrator runs ALTER ACCOUNT ADD ORGANIZATION USER GROUP. By default that needs ACCOUNTADMIN, unless a role has the IMPORT ORGANIZATION USER GROUPS privilege.
4. That administrator checks for conflicts with existing users and roles, where is_imported is FALSE, and resolves them.

-- In the organization account
USE ROLE GLOBALORGADMIN;
CREATE ORGANIZATION USER GROUP platform_admins
  IS_GRANTABLE = TRUE;
ALTER ORGANIZATION USER GROUP platform_admins
  ADD ORGANIZATION USERS asmith, sjohnson;
ALTER ORGANIZATION USER GROUP platform_admins
  SET VISIBILITY = ACCOUNTS prod_eu;
-- In the regular account prod_eu, as ACCOUNTADMIN
ALTER ACCOUNT ADD ORGANIZATION USER GROUP platform_admins;

Existing users do not have to be recreated. SYSTEM$LINK_ORGANIZATION_USER links an existing local user to an organization user, and SYSTEM$LINK_ORGANIZATION_USER_GROUP links an existing role to a group. For an estate that already provisions users with SCIM or an IdP in every account, that link path is the realistic one.

Organization users have a type. Since 26 August 2026 (generally available) an organization user is either PERSON (the default) or SERVICE, and importing a SERVICE organization user creates a SERVICE user in the account. Since 5 October 2026 you can change the type with ALTER ORGANIZATION USER, and the change reaches every account that imported the user. For pipelines and agents that run in several accounts, one SERVICE organization user per workload is a cleaner story than one hand-made service user per account.

Now the limits, because they shape the design:

• Authentication is still per account. The docs say it directly: “You can’t set up authentication at the organization level.” For us, that means the SCIM or IdP setup and the authentication policies in each account do not go away.
• Some properties are owned centrally. Name and email set on the organization user cannot be changed in a regular account after import.
• Dropping is global. Dropping an organization user drops it from every account that imported it.
• Location matters. In hybrid organizations, with accounts in both regulated and non-regulated regions, organization-level objects can move metadata between regions. Snowflake recommends creating the organization account in the regulated region and keeping sensitive or regulated data out of organization-level objects. Organization users are not available in the People’s Republic of China, and ORGANIZATION_USAGE views are not available in US SnowGov regions on AWS GovCloud and Azure Government.

What still lives in each account

Reading all of this together, the organization account is a control plane for visibility and identity, not for everything. These stay in each account:

• Authentication, configured after import.
• CREATE WAREHOUSE and other grants, given by ACCOUNTADMIN in that account.
• The import of each organization user group.
• Per-query cost for Adaptive Warehouses, until the organization view ships.

The order I would roll it out

This is a plan, not a war story. Based on the docs and demos, this is the order I would take on an estate like ours:

1. Create the organization account and move to GLOBALORGADMIN. Update anything that still says ORGADMIN. In a hybrid organization, create it in the regulated region.
2. Start the clock on premium views. Confirm they are enabled in Command Center’s Organization Features tile, then expect up to two weeks before history is complete. Agree on the premium view cost with finance before, not after.
3. Grant viewers, not admins. Give FinOps, security, and platform leads the ORGANIZATION_USAGE application roles they need, plus USAGE on a warehouse for Organization Hub.
4. Turn on the warehouse audit. Schedule the WAREHOUSE_EVENTS_HISTORY query above and review anything created outside the platform role.
5. Use organization users for new people and services first. Start with SERVICE organization users for pipelines and agents that span accounts.
6. Then link existing users. Work account by account with SYSTEM$LINK_ORGANIZATION_USER, alongside the existing SCIM or IdP setup, since authentication stays per account.

Options I considered

Keep managing each account on its own. This is what we do today: SCIM or an IdP integration per account, plus IaC for roles and grants. It costs nothing extra and it works. It lost because every estate question still means visiting each account, and nothing shows a warehouse created outside the platform role until someone goes looking.

Stay on ORGADMIN in a regular account. Less change up front. It lost because ORGADMIN is being phased out for multi-account organizations, and premium views do not exist in an ORGADMIN-enabled account.

Stitch ACCOUNT_USAGE together myself. No premium view bill, and I already need it for per-query Adaptive cost. It lost as the main path because I would own a collection pipeline for every view, while premium views and Organization Hub give that across accounts. I keep it only for the per-query gap.

Impact

I have not run this, so this is what the approach makes possible for an estate like ours, not a result.

For the platform team, estate questions get answered from one account, and an imported group gives the platform role the same name and members everywhere. For security, warehouse events, admins, and dormant users become visible across accounts, through viewer roles instead of GLOBALORGADMIN. For finance, cost for the whole estate sits in Insights, with the premium view cost agreed up front. For leadership, it turns the ORGADMIN phase-out from a surprise into a planned move.

The risk that goes away is drift: role names, hand-made service users, and grants that quietly differ between accounts. What does not go away is per account authentication. If I were starting over, I would create the organization account early just to start the premium view clock, and settle the cost conversation before anyone builds a dashboard.

What’s next in this series

The organization account gives an estate one place to look and one identity per person or service. It does not stop anyone spending. The Insights page even hints at what comes next: a tile marked “Coming soon” that includes organization budgets, in private preview as of October 2026.

Turning visibility into controls is Part 3.

From ORGADMIN to Control Plane: Organization Hub, Organization Users, and Premium Views in Practice was originally published in Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.