Skip to main content

Scoping & Sharing

Scoping defines which CMDB records users can see and which records appear in operational workflows. In Cloudaware, operational scopes are commonly implemented through saved CMDB list views that filter data by cloud account boundaries and consistent metadata, such as tags Owner, Application, and Environment.

Keep scoping separate from permissions:

  • Profiles/permission sets control what a user can do.
  • Scoping & sharing controls what data a user can see, such as production versus non-production assets, team-owned resources, or records from specific accounts, subscriptions, or projects.

Scoping Dimensions​

Use a small number of stable dimensions that are consistently available across CMDB records:

  • Environment: production, non-production, development, test, or staging.
  • Account, subscription, or project: provider-level boundaries used to separate cloud resources.
  • Region: geographic or provider region.
  • Ownership and application mapping: metadata such as Owner and Application.
  • Business unit or Cost center: optional dimensions used for financial, operational, or governance processes.

Create a small set of reusable scopes through saved CMDB list views. Dashboards, policies, routing rules, and automation can reuse these scopes to keep operational logic consistent.

Recommended baseline scopes include:

  • Production: account, subscription, or project boundaries plus Environment = prod.
  • Non-production: resources where Environment != prod.
  • Internet-facing: resources identified by an exposure signal or classified through enrichment rules.
  • Untagged or missing owner: resources missing required metadata such as Owner or Application.

Implement Scopes In Cloudaware​

  1. Start from a relevant default CMDB list view (for example, “Running instances”).
  2. Clone the view.
  3. Add filters for account/subscription, region, and required tags.
  4. Save the view with a clear name that identifies the scope, such as AWS - Production.
  5. Make the view public only when it is intended to be reused as a shared operational scope.
  6. Keep one-off or investigative views private.

As an operational guardrail, restrict who can create public views. Public view creation should be limited to administrators, platform owners, or a dedicated list-view editor role.

Tagging Prerequisites​

Tag-based scoping depends on consistent metadata. If tags are missing, inconsistent, or provider-specific, scoping may become unreliable.

Recommendations:

  • Start with a minimum required tag set: Owner, Application, Environment.
  • Use Tag Analyzer and Enrichment Rules to identify tag drift, normalize keys and values, and keep filters stable across cloud providers.

Sharing​

Cloudaware scoping and Salesforce record-level sharing solve related but different problems.

Use Salesforce sharing controls, such as organization-wide defaults, roles, role hierarchy, and sharing rules, when you need to enforce least-privilege visibility for the underlying records.

Use saved CMDB scopes for day-to-day operational workflows, such as defining which assets are included in dashboards, policies, reports, routing rules, and automation.

Where both mechanisms are used, keep them aligned. A saved CMDB scope should not expose records to users who should not have access to the underlying data.