Skip to main content

Data Governance

This guide explains how to manage Analytics assets effectively. It covers naming conventions, data preparation best practices, and guidance for working with analytics assets such as apps, dashboards, lenses, recipes, and datasets.

Follow these standards to keep Advanced Analytics organized, consistent, and easy to maintain.

Core Principles​

  • Use clear and consistent naming.
  • Include only useful data.
  • Structure data carefully.
  • Handle null values across datasets.

Proper Naming​

Consistent naming is important across recipes, join prefixes, datasets, apps, and dashboards.

General Naming Rules​

  • Avoid errors – double‑check all names before saving.
  • Use only letters and spaces in display names; avoid symbols such as #, _, !, or ::.
  • Keep asset names clear, short, and meaningful.
  • Treat API names as carefully as labels, even if they are not visible to end users.
  • Avoid creating unnecessary assets – prefer updating or enriching existing defaults where possible.
  • Anything visible to other users should be easy to understand.

API Name and Label​

Each analytics asset has a user‑friendly Name and a system API Name:

  • The Name is used in the UI and can be changed.
  • The API Name is used by the system to identify the asset and should remain stable after creation.
note

If a dataset is used in a dashboard and its API Name is changed, the dashboard may break because it can no longer identify the dataset correctly.

API Name Rules​

The API name should generally match the display name, but:

  • Remove spaces.
  • Capitalize the first letter of each word.

Examples:

  • Name: Asset Vulnerabilities → API Name: AssetVulnerabilities
  • Name: AWS Daily Billing → API Name: AwsDailyBilling
tip

If the name contains multiple capital letters in a row, keep only the first letter capitalized and convert the rest to lowercase (as in the AWS example above).

Recipes: Join Prefixes​

When you create joins in a recipe, assign a prefix to the joined node so it is easy to identify fields that come from the joined object.

To create the prefix, use the object API name and remove:

  • The managed package prefix, such as CA10__ or CA10ND__.
  • The suffix __c.

Example:

  • Object API name: CA10ND__CaNetworkDevice__c
  • Prefix: NetworkDevice

After the join, fields from the joined object begin with that prefix, for example:

  • NetworkDevice.Name

Recipes: Node Names​

Recipe nodes should also be named clearly. Names like Join 0 or Filter 5 make recipes harder to maintain.

Input Nodes​

  • Use the same name as the object shown in CMDB. Example: AWS EC2 Instances.

Join Nodes​

  • Use the format: Join [Object being joined] to [Core Object]. Example: Join AWS Accounts to AWS EC2 Instances.

Append Nodes​

  • Use the format: Append [Object being appended] to [Core Object].

Transform Nodes​

  • Use the name Transform plus a short description of what happens in that node. Example: Transform – resource name formula, source bucket, and unnecessary column removal.
  • Give individual transform steps meaningful names so the recipe is easier to navigate.

Aggregate Nodes​

  • Use: Aggregate.

Output Nodes​

  • Use: Output to Dataset.

Datasets and Recipes: Standard Names​

Some datasets and recipes are created by default. As a rule, the recipe name should match the output dataset name.

Default Datasets​

  • OS Service Coverage

    • API Name: OsServiceCoverage
    • Purpose: join OS Service objects to cloud and non‑cloud resources.

  • Asset Vulnerabilities

    • API Name: AssetVulnerabilities
    • Purpose: dashboards related to vulnerability scanning.

  • Compute Assets

    • API Name: ComputeAssets
    • Purpose: aggregated AWS, Azure, GCP instances, and physical infrastructure; reused wherever instances/servers are joined to additional data.

  • Asset Tagging Compliance

    • API Name: AssetTaggingCompliance
    • Purpose: optional; used when customers request tag‑key compliance checks and fuzzy tags from Tag Analyzer for Tagging Coverage or Tagging Compliance dashboards.

Billing Datasets​

Billing datasets should follow this naming format: [Cloud] [Report Type, if applicable] [Daily/Monthly] Billing

Examples:

  • AWS CUR Daily Billing → API Name: AwsCurDailyBilling
  • AWS CUR Monthly Billing → API Name: AwsCurMonthlyBilling
  • AWS CUR 2.0 Daily Billing → API Name: AwsCur20DailyBilling
  • AWS CUR 2.0 Monthly Billing → API Name: AwsCur20MonthlyBilling
  • AWS DBR Daily Billing (legacy) → API Name: AwsDbrDailyBilling
  • AWS DBR Monthly Billing (legacy) → API Name: AwsDbrMonthlyBilling
  • Azure EA Daily Billing → API Name: AzureEaDailyBilling
  • Azure EA Monthly Billing → API Name: AzureEaMonthlyBilling
  • GCP BigQuery Daily Billing → API Name: GcpBigQueryDailyBilling
  • GCP BigQuery Monthly Billing → API Name: GcpBigQueryMonthlyBilling
  • Multi‑Cloud Daily Billing → API Name: MultiCloudDailyBilling
  • Multi‑Cloud Monthly Billing → API Name: MultiCloudMonthlyBilling

All‑Resources Dataset​

  • All Assets
    • API Name: AllAssets
    • Purpose: contains information about all CMDB objects and tags.

Compliance Engine 2.0 Datasets​

  • Policy Output – API Name: PolicyOutput
  • Frameworks – API Name: Frameworks
  • Policy Output Snapshot – API Name: PolicyOutputSnapshot

These are typically based on internal views such as PolicyOutputWithPolicyRun, FrameworksWithMappedCePolicies, and HistoricalPolicyOutputWithPolicyRun.

Custom Datasets and Recipes​

A common pattern is to create a dataset for a specific CMDB object, enriched with additional data.

  • If EC2 Instances is the core object, name both the dataset and recipe AWS EC2 Instances.
  • If a dataset has two or more core objects, use and or with in the name:
    • Examples:
      • AWS EC2 Instances and Azure Virtual Machines
      • Cloud Accounts with Forecast

The name should clearly communicate what the dataset is about and which objects are central.

Dashboards​

  • For default dashboards, refer to the Report & Dashboard Gallery.
  • For other dashboards, use meaningful names that are clear to the customer and follow the naming rules above.

Apps​

Cloudaware typically provisions three default apps per customer:

  • CMDB for CMDB insights
  • Cost Management for cloud cost insights
  • Security for security insights

Ensure these apps are shared correctly with users in your Analytics space. Avoid creating additional custom apps unless required by your use case. If you do, follow the same naming and API Name rules.

Snapshots​

For historical snapshot datasets, use the following naming format [Initial Recipe Name] Snapshot.

Example:

  • Asset Vulnerabilities Snapshot

Use Only Useful Data​

Datasets should include only fields that are needed.

  • When adding a node in a recipe, do not select every field by default; include only fields required for the use case.
  • The following fields usually add no value to analytics outputs and should generally be excluded:
    • Deleted
    • CreatedById
    • LastModifiedDate
    • LastModifiedById
    • LastViewedDate
    • LastReferencedDate
    • SystemModstamp
    • LastActivityDate
    • Cloudaware UUID fields
    • Any field that starts with Deprecated: (for example, Deprecated: Last Attach Date)

Field Names and Labels​

  • Field names and labels should be clear and easy to understand.
  • Use Edit Attributes transformations in recipes to update a field’s API name or label.
  • You can also rename fields in a lens by using the dataset fields panel in the upper‑left corner.

Drop Unused Columns​

  • Use Drop Columns transformations to remove columns that should not appear in the output dataset.

Keep Recipes Simple​

  • Fewer nodes per recipe is better.
  • Create reusable recipes for common use cases (for example, a shared compute resources dataset) and use them as building blocks in other recipes.
  • Make sure every transformation and filter has a clear label; for example:
    • Filter out deleted resources.

Format Dates Clearly​

  • Use human‑readable date formats in datasets and dashboards.
  • The recipe editor allows you to apply user‑friendly date formats via Edit Attributes transformations.

Structure Analytics Content Well​

  • Store dashboards in appropriate apps (for example, billing dashboards in billing‑related apps); the same applies to lenses.
  • Remove unused queries from dashboards.
  • Even when working in a Private App, follow naming and hygiene standards.
  • When backing up dashboards, store them in the Private App using:
    • Backup from [date] of [dashboard name] Example: Backup from 2024‑09‑12 of AWS CUR.
  • Back up important recipes by downloading their JSON definitions.

Handle Null Values in Datasets​

To make nulls visible and selectable in analytics:

  • Use the org‑level setting:
    • In Cloudaware, go to Setup → Analytics → Settings → Include null values in CRM Analytics Queries.
  • When this setting is enabled, null values appear as -, which allows them to be selected and displayed in lenses and widgets.

Data Cleanup​

Cloudaware TAMs may perform periodic data cleanup in coordination with customers to:

  • Remove obsolete datasets, recipes, and dashboards.
  • Align naming and structure with current best practices.
  • Improve performance and reduce noise in Analytics Studio.