Folders are structure, scope is authority
Strata Cloud Manager keeps what you manage and who may manage it as two separate models. Most folder trees that go wrong confused the two.
Anyone arriving from Panorama brings three nouns with them: device groups, templates and access domains. Strata Cloud Manager has three of its own, and the mapping is close enough to be useful and loose enough to cause trouble.
| Panorama | Strata Cloud Manager |
|---|---|
| Device group | Folder: the container a firewall or Prisma Access deployment lives in, and the unit policy is applied to |
| Template and template stack | Snippet: a reusable bundle of configuration attached to one or more folders |
| Device group hierarchy and stack order | Folder tree: inheritance pushed down from parent to child |
| Access domain | Admin scope: a role bound to a set of folders, firewalls and snippets |
The first three rows carry over almost unchanged. The last one is where the model actually differs, and it is the row worth slowing down for.
Structure and authority
Folders are structure. They are the tree of what is managed: where a firewall lives, what configuration it inherits, and what a push from above will reach. Putting a firewall in a folder grants nobody anything.
Scope is authority. It decides who may read and who may write a given set of folders, firewalls and snippets, and it does so by binding a role to that set. A scope does not organize anything; it draws a boundary on an organization that already exists.
The two are maintained separately and meet only at folder names. Access domains in Panorama tended to end up as a second copy of the device-group list, kept in step by hand. Here the list is referenced, not copied, which is the whole point: the tree can be redrawn without rewriting who is allowed to do what.
| Folders | Admin scope | |
|---|---|---|
| Purpose | Group assets so configuration is applied once and inherited | Bound what an administrator can see and change |
| Analogy | The filing cabinet: where things live | The keys: who may open which drawer |
| Function | The design-time hierarchy and the inheritance path | A role times a folder set, checked on every action |
| Impacts | Push reach, policy organization, what a child receives from its parent | Least privilege, separation of duties, the blast radius of a mistake |
Inheritance goes down the tree
A push at a parent folder includes every child folder and every asset beneath it. Configuration placed high is applied everywhere below; configuration placed in a leaf stays in the leaf. That is the only direction anything flows, so the levels of the tree are inheritance boundaries first and organizational labels second. A level that carries no configuration of its own and delegates no authority is a level the tree does not need.
Scope is a role times a folder set
A scope is not a folder. It is a platform role — Security Administrator, Network Administrator, View Only Administrator and the rest — applied to a chosen set of folders, firewalls and snippets. Two people with the same role can hold different scopes. Two teams with different roles can share a folder: a security team holds policy rights over a data-center folder while a network team holds device-settings rights over the same folder, and neither sees the other's work as its own.
The set need not be a subtree. It can cross branches of the tree, and the useful ones often do.
Three ways it goes wrong
The over-fragmented tree. A folder for every application server instead of one for the data-center servers. Each extra level is another place inheritance has to be reasoned about and another entry every scope has to enumerate. The tree becomes brittle before it becomes useful.
Scope used instead of structure. Two business units, or production and development, kept in one flat folder and separated only by who may edit what. Scope cannot give what folders give. There is no separate inheritance and no separate push, so every difference between the two has to be carried in snippets and variables, and the posture becomes hard to read.
A tree misaligned to how authority is actually delegated. A hierarchy by device model in a company that delegates by region. The folder boundaries never line up with a team's responsibility, so scopes either grant too much or become an overlapping set of exceptions that nobody can audit.
Four rules
- Start the top level from how the business is actually run: region, business unit, or environment. Nothing more elaborate than that.
- Add a folder only for a distinct configuration set or a new delegation boundary. A folder that is neither is clutter.
- Define scopes by job function. Map each function to a platform role, then give that role the smallest folder set the function needs.
- Expect the tree to move. Folders can be relocated in the hierarchy, and a reorganization or an acquisition is the moment to check that the tree and the scopes still describe who does what.
The familiar patterns — a central security team with regional delegation, a provider running several customers, separate environments, an acquisition kept autonomous for a while — are all the same move: draw the tree for inheritance, then lay scopes over it. Multi-tenant Strata Cloud Manager works that through one level up, where the same separation reappears as tenants and sub-parents rather than folders and scopes.