Skip to main content
Version: 1.6.0

Chart

Charts are visual representations of data, typically found in Business Intelligence (BI) platforms and dashboarding tools. In DataHub, charts represent individual visualizations such as bar charts, pie charts, line graphs, tables, and other data displays. Charts are typically ingested from platforms like Looker, Tableau, PowerBI, Superset, Mode, and other BI tools.

Identity​

Charts are identified by two pieces of information:

  • The platform that they belong to: This is the specific BI tool or dashboarding platform that hosts the chart. Examples include looker, tableau, powerbi, superset, mode, etc. This corresponds to the dashboardTool field in the chart's key aspect.
  • The chart identifier in the specific platform: Each platform has its own way of uniquely identifying charts within its system. For example, Looker uses identifiers like look/1234, while PowerBI might use tile identifiers like tile-abc-123.

An example of a chart identifier is urn:li:chart:(looker,look/1234).

For platforms with multiple instances (e.g., separate Looker deployments for different environments), the URN can include a platform instance identifier: urn:li:chart:(looker,look/1234,prod-instance).

Important Capabilities​

Chart Information and Metadata​

The core metadata about a chart is stored in the chartInfo aspect. This includes:

  • Title: The display name of the chart (searchable)
  • Description: A detailed description of what the chart shows
  • Chart Type: The type of visualization (BAR, PIE, SCATTER, TABLE, TEXT, LINE, AREA, HISTOGRAM, BOX_PLOT, WORD_CLOUD, COHORT)
  • Chart URL: A link to view the chart in its native platform
  • Access Level: The access level of the chart (PUBLIC or PRIVATE)
  • Last Modified: Audit stamps tracking when the chart was created, modified, or deleted
  • Last Refreshed: Timestamp of when the chart data was last refreshed

The following code snippet shows you how to create a chart with basic information.

Python SDK: Create a chart
# Inlined from /metadata-ingestion/examples/library/chart_create_simple.py
from datahub.metadata.urns import TagUrn
from datahub.sdk import Chart, DataHubClient

client = DataHubClient.from_env()

chart = Chart(
    name="example_chart",
    platform="looker",
    description="looker chart for production",
    tags=[TagUrn(name="production"), TagUrn(name="data_engineering")],
)

client.entities.upsert(chart)

For more complex chart creation with additional metadata:

Python SDK: Create a chart with full metadata
# Inlined from /metadata-ingestion/examples/library/chart_create_complex.py
from datahub.metadata.urns import TagUrn
from datahub.sdk import Chart, DataHubClient, Dataset

client = DataHubClient.from_env()

input_datasets = [
    Dataset(
        name="example_dataset",
        platform="snowflake",
        description="looker dataset for production",
        schema=[("id", "string"), ("name", "string")],
    ),
    Dataset(
        name="example_dataset_2",
        platform="snowflake",
        description="looker dataset for production",
        schema=[("id", "string"), ("name", "string")],
    ),
    Dataset(
        name="example_dataset_3",
        platform="snowflake",
        description="looker dataset for production",
        schema=[("id", "string"), ("name", "string")],
    ),
]

# create a chart with two input datasets
chart = Chart(
    name="example_chart",
    platform="looker",
    description="looker chart for production",
    tags=[TagUrn(name="production"), TagUrn(name="data_engineering")],
    input_datasets=[input_datasets[0], input_datasets[1]],
)

for dataset in input_datasets:
    client.entities.upsert(dataset)

# add a new dataset to the chart
chart.add_input_dataset(input_datasets[2])
client.entities.upsert(chart)

Chart Queries​

Charts often have underlying queries (SQL, LookML, etc.) that define how the data is retrieved and processed. The chartQuery aspect stores this information:

  • Raw Query: The actual query text used to generate the chart
  • Query Type: The type of query (LOOKML or SQL)

This information is particularly useful for understanding data lineage and for auditing purposes.

Data Lineage and Input Datasets​

Charts consume data from one or more datasets (or sometimes from other charts). The chartInfo aspect's inputEdges field tracks these relationships, creating Consumes relationships in the metadata graph. This enables:

  • Impact Analysis: Understanding which charts are affected when a dataset changes
  • Data Lineage Visualization: Showing the flow of data from source datasets through to charts
  • Dependency Tracking: Identifying all upstream dependencies for a chart
Python SDK: Add lineage to a chart
# Inlined from /metadata-ingestion/examples/library/chart_add_lineage.py
from datahub.sdk import Chart, DataHubClient, Dataset

client = DataHubClient.from_env()

# Define the source datasets
upstream_dataset1 = Dataset(platform="bigquery", name="project.dataset.sales_table")
upstream_dataset2 = Dataset(platform="bigquery", name="project.dataset.customer_table")

# Create a chart with lineage to upstream datasets
chart = Chart(
    name="sales_by_customer_chart",
    platform="looker",
    display_name="Sales by Customer",
    description="Bar chart showing total sales aggregated by customer",
    input_datasets=[upstream_dataset1, upstream_dataset2],
)

client.entities.upsert(chart)

Field-Level Lineage​

The inputFields aspect provides fine-grained tracking of which specific dataset fields (columns) are referenced by the chart. Each input field creates a consumesField relationship to a schemaField entity, enabling:

  • Column-Level Impact Analysis: Understanding which charts use a specific column
  • Data Sensitivity Tracking: Identifying charts that display sensitive fields
  • Schema Change Impact: Predicting the effect of schema changes on visualizations

Editable Properties​

DataHub separates metadata that comes from ingestion sources (in chartInfo) from metadata that users edit in the DataHub UI (in editableChartProperties). This separation ensures that:

  • User edits are preserved across ingestion runs
  • Source system metadata remains authoritative for its fields
  • Users can enhance metadata without interfering with automated ingestion

The editableChartProperties aspect currently supports:

  • Description: A user-provided description that supplements or overrides the ingested description

Tags and Glossary Terms​

Charts can have Tags or Terms attached to them. Read this blog to understand the difference between tags and terms.

Adding Tags to a Chart​

Tags are added to charts using the globalTags aspect.

Python SDK: Add a tag to a chart
# Inlined from /metadata-ingestion/examples/library/chart_add_tag.py
from datahub.sdk import ChartUrn, DataHubClient, TagUrn

client = DataHubClient.from_env()

chart = client.entities.get(ChartUrn("looker", "sales_dashboard"))

chart.add_tag(TagUrn("Important"))

client.entities.update(chart)

print(f"Added tag {TagUrn('Important')} to chart {chart.urn}")

Adding Glossary Terms to a Chart​

Glossary terms are added using the glossaryTerms aspect.

Python SDK: Add a glossary term to a chart
# Inlined from /metadata-ingestion/examples/library/chart_add_term.py
from datahub.metadata.urns import GlossaryTermUrn
from datahub.sdk import ChartUrn, DataHubClient

client = DataHubClient.from_env()

chart = client.entities.get(ChartUrn("looker", "sales_dashboard"))

chart.add_term(GlossaryTermUrn("Revenue"))

client.entities.update(chart)

print(f"Added term {GlossaryTermUrn('Revenue')} to chart {chart.urn}")

Ownership​

Ownership is associated with a chart using the ownership aspect. Owners can be of different types such as DATAOWNER, TECHNICAL_OWNER, BUSINESS_OWNER, etc. Ownership can be inherited from source systems or added in DataHub.

Python SDK: Add an owner to a chart
# Inlined from /metadata-ingestion/examples/library/chart_add_owner.py
from datahub.sdk import ChartUrn, CorpUserUrn, DataHubClient

client = DataHubClient.from_env()

chart = client.entities.get(ChartUrn("looker", "sales_dashboard"))

chart.add_owner(CorpUserUrn("jdoe"))

client.entities.update(chart)

print(f"Added owner {CorpUserUrn('jdoe')} to chart {chart.urn}")

Usage Statistics​

Charts can track usage metrics through the chartUsageStatistics aspect (experimental). This timeseries aspect captures:

  • Views Count: Total number of times the chart has been viewed
  • Unique User Count: Number of distinct users who viewed the chart
  • Per-User Counts: Detailed usage breakdown by individual users

Usage statistics help identify:

  • Popular charts that might need performance optimization
  • Unused charts that could be deprecated
  • User engagement patterns

Organizational Context​

Domains​

Charts can be organized into Domains (business areas or data products) using the domains aspect. This helps with:

  • Organizing charts by business function
  • Access control and governance
  • Discovery by domain experts

Containers​

Charts typically belong to a Dashboard (their parent container). The container aspect tracks this relationship, creating a hierarchical structure:

Dashboard (Container)
├── Chart 1
├── Chart 2
└── Chart 3

This hierarchy is important for:

  • Navigating related visualizations
  • Understanding chart context
  • Propagating metadata (like ownership) from dashboard to charts

Embedding and External URLs​

The embed aspect stores URLs that allow embedding the chart in external applications or viewing it in its native platform. This supports:

  • Embedding charts in wikis or documentation
  • Deep linking to the chart in the BI tool
  • Integration with external portals

Chart Subtypes​

Charts from different platforms may have platform-specific subtypes defined in the subTypes aspect. Examples include:

  • Looker: Look (a saved Looker visualization)
  • PowerBI: PowerBI Tile (a tile on a PowerBI report page)
  • Mode: Chart, Report (different Mode visualization types)

Subtypes help users understand the platform-specific nature of the chart.

Integration with External Systems​

Ingestion from BI Platforms​

Charts are typically ingested automatically from BI platforms using DataHub's ingestion connectors:

  • Looker: Ingests Looks (saved visualizations) and dashboard elements
  • Tableau: Ingests sheets (worksheets) from workbooks
  • PowerBI: Ingests tiles from reports
  • Superset: Ingests charts from dashboards
  • Mode: Ingests charts and visualizations
  • Metabase: Ingests questions and visualizations

Each connector maps platform-specific chart metadata to DataHub's standardized chart model.

Querying Chart Information​

You can retrieve chart information using DataHub's REST API:

Fetch chart entity snapshot
curl 'http://localhost:8080/entities/urn%3Ali%3Achart%3A(looker,look%2F1234)'

The response includes all aspects of the chart, including:

  • Chart information (title, description, type)
  • Input datasets (lineage)
  • Ownership, tags, and terms
  • Usage statistics
  • And all other configured aspects

Relationships API​

You can query chart relationships to understand its connections to other entities:

Find datasets consumed by a chart
curl 'http://localhost:8080/relationships?direction=OUTGOING&urn=urn%3Ali%3Achart%3A(looker,look%2F1234)&types=Consumes'

This returns all datasets (and potentially other charts) that this chart consumes data from.

Find charts that consume a specific dataset
curl 'http://localhost:8080/relationships?direction=INCOMING&urn=urn%3Ali%3Adataset%3A(urn%3Ali%3AdataPlatform%3Abigquery,project.dataset.table,PROD)&types=Consumes'

This returns all charts that depend on the specified dataset.

GraphQL API​

Charts are fully supported in DataHub's GraphQL API, which provides:

  • Queries: Search, browse, and retrieve charts
  • Mutations: Create, update, and delete charts
  • Faceted Search: Filter charts by tool, type, access level, and query type
  • Lineage Queries: Traverse upstream and downstream relationships
  • Batch Loading: Efficiently load multiple charts

The GraphQL Chart type includes all standard metadata fields plus chart-specific properties like query definitions and usage statistics.

Notable Exceptions​

Platform-Specific Variations​

Different BI platforms have different concepts that map to charts:

  • Tableau Sheets vs Dashboards: In Tableau, a "sheet" (worksheet) maps to a DataHub chart, while a "dashboard" maps to a DataHub dashboard entity. A Tableau dashboard can contain multiple sheets.

  • PowerBI Tiles: PowerBI has the concept of "tiles" (pinned visualizations) which are modeled as charts in DataHub. A tile can reference multiple underlying reports or datasets.

  • Looker Looks vs Dashboard Elements: Looker has standalone "Looks" (saved visualizations) and dashboard elements. Both are modeled as charts in DataHub.

Chart-to-Chart Lineage​

While most charts consume data from datasets, some platforms support charts that derive from other charts. DataHub supports this through chart-to-chart Consumes relationships, enabling multi-level visualization lineage.

Deprecated Fields​

The chartInfo.inputs field is deprecated in favor of chartInfo.inputEdges. The inputEdges field provides richer relationship metadata including timestamps and actors for when relationships were created or modified.

Charts frequently interact with these other DataHub entities:

  • Dashboard: Charts are typically contained within dashboards
  • Dataset: Charts consume data from datasets
  • SchemaField: Charts reference specific fields/columns through field-level lineage
  • DataPlatform: Charts are associated with a specific BI platform
  • Domain: Charts can be organized into business domains
  • GlossaryTerm: Charts can be annotated with business terms
  • Tag: Charts can be tagged for classification and discovery
  • CorpUser / CorpGroup: Charts have owners and are used by users

Technical Reference Guide​

The sections above provide an overview of how to use this entity. The following sections provide detailed technical information about how metadata is stored and represented in DataHub.

Aspects are the individual pieces of metadata that can be attached to an entity. Each aspect contains specific information (like ownership, tags, or properties) and is stored as a separate record, allowing for flexible and incremental metadata updates.

Relationships show how this entity connects to other entities in the metadata graph. These connections are derived from the fields within each aspect and form the foundation of DataHub's knowledge graph.

Reading the Field Tables​

Each aspect's field table includes an Annotations column that provides additional metadata about how fields are used:

  • ⚠️ Deprecated: This field is deprecated and may be removed in a future version. Check the description for the recommended alternative
  • Searchable: This field is indexed and can be searched in DataHub's search interface
  • Searchable (fieldname): When the field name in parentheses is shown, it indicates the field is indexed under a different name in the search index. For example, dashboardTool is indexed as tool
  • → RelationshipName: This field creates a relationship to another entity. The arrow indicates this field contains a reference (URN) to another entity, and the name indicates the type of relationship (e.g., → Contains, → OwnedBy)

Fields with complex types (like Edge, AuditStamp) link to their definitions in the Common Types section below.

Aspects​

chartKey​

Key for a Chart

FieldTypeRequiredDescriptionAnnotations
dashboardToolstring✓The name of the dashboard tool such as looker, redash etc.Searchable (tool)
chartIdstring✓Unique id for the chart. This id should be globally unique for a dashboarding tool even when ther...

chartInfo​

Information about a chart

FieldTypeRequiredDescriptionAnnotations
customPropertiesmap✓Custom property bag.Searchable
externalUrlstringURL where the reference existSearchable
titlestring✓Title of the chartSearchable
descriptionstring✓Detailed description about the chartSearchable
lastModifiedChangeAuditStamps✓Captures information about who created/last modified/deleted this chart and whenSearchable
chartUrlstringURL for the chart. This could be used as an external link on DataHub to allow users access/view t...Searchable
inputsunion[]Data sources for the chart Deprecated! Use inputEdges instead.⚠️ Deprecated, → Consumes
inputEdgesEdge[]Data sources for the chart→ Consumes
typeChartTypeType of the chartSearchable
accessAccessLevelAccess level for the chartSearchable
lastRefreshedlongThe time when this chart last refreshed

chartQuery​

Information for chart query which is used for getting data of the chart

FieldTypeRequiredDescriptionAnnotations
rawQuerystring✓Raw query to build a chart from input datasets
typeChartQueryType✓Chart query typeSearchable (queryType)

editableChartProperties​

Stores editable changes made to properties. This separates changes made from ingestion pipelines and edits in the UI to avoid accidental overwrites of user-provided data by ingestion pipelines

FieldTypeRequiredDescriptionAnnotations
createdAuditStamp✓An AuditStamp corresponding to the creation of this resource/association/sub-resource. A value of...
lastModifiedAuditStamp✓An AuditStamp corresponding to the last modification of this resource/association/sub-resource. I...
deletedAuditStampAn AuditStamp corresponding to the deletion of this resource/association/sub-resource. Logically,...
descriptionstringEdited documentation of the chartSearchable (editedDescription)

ownership​

Ownership information of an entity.

FieldTypeRequiredDescriptionAnnotations
ownersOwner[]✓List of owners of the entity.
ownerTypesmapOwnership type to Owners map, populated via mutation hook.Searchable
lastModifiedAuditStamp✓Audit stamp containing who last modified the record and when. A value of 0 in the time field indi...

status​

The lifecycle status metadata of an entity, e.g. dataset, metric, feature, etc. This aspect is used to represent soft deletes conventionally.

FieldTypeRequiredDescriptionAnnotations
removedboolean✓Whether the entity has been removed (soft-deleted). Kept for backward compatibility. When lifecyc...Searchable
lifecycleStagestringThe lifecycle stage of the entity, referencing a lifecycleStageType entity. When null, the entity...Searchable
lifecycleLastUpdatedAuditStampAttribution for the lifecycle stage transition — who moved the entity into its current stage and ...

globalTags​

Tag aspect used for applying tags to an entity

FieldTypeRequiredDescriptionAnnotations
tagsTagAssociation[]✓Tags associated with a given entitySearchable, → TaggedWith

browsePaths​

Shared aspect containing Browse Paths to be indexed for an entity.

FieldTypeRequiredDescriptionAnnotations
pathsstring[]✓A list of valid browse paths for the entity. Browse paths are expected to be forward slash-separ...Searchable

glossaryTerms​

Related business terms information

FieldTypeRequiredDescriptionAnnotations
termsGlossaryTermAssociation[]✓The related business terms
auditStampAuditStamp✓Audit stamp containing who reported the related business term

institutionalMemory​

Institutional memory of an entity. This is a way to link to relevant documentation and provide description of the documentation. Institutional or tribal knowledge is very important for users to leverage the entity.

FieldTypeRequiredDescriptionAnnotations
elementsInstitutionalMemoryMetadata[]✓List of records that represent institutional memory of an entity. Each record consists of a link,...

dataPlatformInstance​

The specific instance of the data platform that this entity belongs to

FieldTypeRequiredDescriptionAnnotations
platformstring✓Data PlatformSearchable
instancestringInstance of the data platform (e.g. db instance)Searchable (platformInstance)

browsePathsV2​

Shared aspect containing a Browse Path to be indexed for an entity.

FieldTypeRequiredDescriptionAnnotations
pathBrowsePathEntry[]✓A valid browse path for the entity. This field is provided by DataHub by default. This aspect is ...Searchable

inputFields​

Information about the fields a chart or dashboard references

FieldTypeRequiredDescriptionAnnotations
fieldsInputField[]✓List of fields being referenced

embed​

Information regarding rendering an embed for an asset.

FieldTypeRequiredDescriptionAnnotations
renderUrlstringAn embed URL to be rendered inside of an iframe.

domains​

Links from an Asset to its Domains

FieldTypeRequiredDescriptionAnnotations
domainsstring[]✓The Domains attached to an AssetSearchable, → AssociatedWith

applications​

Links from an Asset to its Applications

FieldTypeRequiredDescriptionAnnotations
applicationsstring[]✓The Applications attached to an AssetSearchable, → AssociatedWith

container​

Link from an asset to its parent container

FieldTypeRequiredDescriptionAnnotations
containerstring✓The parent container of an assetSearchable, → IsPartOf

deprecation​

Deprecation status of an entity

FieldTypeRequiredDescriptionAnnotations
deprecatedboolean✓Whether the entity is deprecated.Searchable
decommissionTimelongThe time user plan to decommission this entity.
notestring✓Additional information about the entity deprecation plan, such as the wiki, doc, RB.
actorstring✓The user URN which will be credited for modifying this deprecation content.
replacementstring

subTypes​

Sub Types. Use this aspect to specialize a generic Entity e.g. Making a Dataset also be a View or also be a LookerExplore

FieldTypeRequiredDescriptionAnnotations
typeNamesstring[]✓The names of the specific types.Searchable

structuredProperties​

Properties about an entity governed by StructuredPropertyDefinition

FieldTypeRequiredDescriptionAnnotations
propertiesStructuredPropertyValueAssignment[]✓Custom property bag.

incidentsSummary​

Summary related incidents on an entity.

FieldTypeRequiredDescriptionAnnotations
resolvedIncidentsstring[]✓Resolved incidents for an asset Deprecated! Use the richer resolvedIncidentsDetails instead.⚠️ Deprecated
activeIncidentsstring[]✓Active incidents for an asset Deprecated! Use the richer activeIncidentsDetails instead.⚠️ Deprecated
resolvedIncidentDetailsIncidentSummaryDetails[]✓Summary details about the set of resolved incidentsSearchable, → ResolvedIncidents
activeIncidentDetailsIncidentSummaryDetails[]✓Summary details about the set of active incidentsSearchable, → ActiveIncidents

forms​

Forms that are assigned to this entity to be filled out

FieldTypeRequiredDescriptionAnnotations
incompleteFormsFormAssociation[]✓All incomplete forms assigned to the entity.Searchable
completedFormsFormAssociation[]✓All complete forms assigned to the entity.Searchable
verificationsFormVerificationAssociation[]✓Verifications that have been applied to the entity via completed forms.Searchable

testResults​

Information about a Test Result

FieldTypeRequiredDescriptionAnnotations
failingTestResult[]✓Results that are failingSearchable, → IsFailing
passingTestResult[]✓Results that are passingSearchable, → IsPassing

documentation​

Aspect used for storing all applicable documentations on assets. This aspect supports multiple documentations from different sources. There is an implicit assumption that there is only one documentation per source. For example, if there are two documentations from the same source, the latest one will overwrite the previous one. If there are two documentations from different sources, both will be stored. Future evolution considerations: The first entity that uses this aspect is Schema Field. We will expand this aspect to other entities eventually. The values of the documentation are not currently searchable. This will be changed once this aspect develops opinion on which documentation entry is the authoritative one. Ensuring that there is only one documentation per source is a business rule that is not enforced by the aspect yet. This will currently be enforced by the application that uses this aspect. We will eventually enforce this rule in the aspect using AspectMutators.

FieldTypeRequiredDescriptionAnnotations
documentationsDocumentationAssociation[]✓Documentations associated with this asset. We could be receiving docs from different sources

chartUsageStatistics (Timeseries)​

Experimental (Subject to breaking change) -- Stats corresponding to chart's usage.

If this aspect represents the latest snapshot of the statistics about a Chart, the eventGranularity field should be null. If this aspect represents a bucketed window of usage statistics (e.g. over a day), then the eventGranularity field should be set accordingly.

FieldTypeRequiredDescriptionAnnotations
timestampMillislong✓The event timestamp field as epoch at UTC in milli seconds.
eventGranularityTimeWindowSizeGranularity of the event if applicable
partitionSpecPartitionSpecThe optional partition specification.
messageIdstringThe optional messageId, if provided serves as a custom user-defined unique identifier for an aspe...
viewsCountintThe total number of times chart has been viewed
uniqueUserCountintUnique user count
userCountsChartUserUsageCounts[]Users within this bucket, with frequency counts

Common Types​

These types are used across multiple aspects in this entity.

AuditStamp​

Data captured on a resource/association/sub-resource level giving insight into when that resource/association/sub-resource moved into a particular lifecycle stage, and who acted to move it into that specific lifecycle stage.

Fields:

  • time (long): When did the resource/association/sub-resource move into the specific lifecyc...
  • actor (string): The entity (e.g. a member URN) which will be credited for moving the resource...
  • impersonator (string?): The entity (e.g. a service URN) which performs the change on behalf of the Ac...
  • message (string?): Additional context around how DataHub was informed of the particular change. ...

ChangeAuditStamps​

Data captured on a resource/association/sub-resource level giving insight into when that resource/association/sub-resource moved into various lifecycle stages, and who acted to move it into those lifecycle stages. The recommended best practice is to include this record in your record schema, and annotate its fields as @readOnly in your resource. See https://github.com/linkedin/rest.li/wiki/Validation-in-Rest.li#restli-validation-annotations

Fields:

  • created (AuditStamp): An AuditStamp corresponding to the creation of this resource/association/sub-...
  • lastModified (AuditStamp): An AuditStamp corresponding to the last modification of this resource/associa...
  • deleted (AuditStamp?): An AuditStamp corresponding to the deletion of this resource/association/sub-...

Edge​

A common structure to represent all edges to entities when used inside aspects as collections This ensures that all edges have common structure around audit-stamps and will support PATCH, time-travel automatically.

Fields:

  • sourceUrn (string?): Urn of the source of this relationship edge. If not specified, assumed to be ...
  • destinationUrn (string): Urn of the destination of this relationship edge.
  • created (AuditStamp?): Audit stamp containing who created this relationship edge and when
  • lastModified (AuditStamp?): Audit stamp containing who last modified this relationship edge and when
  • properties (map?): A generic properties bag that allows us to store specific information on this...

FormAssociation​

Properties of an applied form.

Fields:

  • urn (string): Urn of the applied form
  • incompletePrompts (FormPromptAssociation[]): A list of prompts that are not yet complete for this form.
  • completedPrompts (FormPromptAssociation[]): A list of prompts that have been completed for this form.

IncidentSummaryDetails​

Summary statistics about incidents on an entity.

Fields:

  • urn (string): The urn of the incident
  • type (string): The type of an incident
  • createdAt (long): The time at which the incident was raised in milliseconds since epoch.
  • resolvedAt (long?): The time at which the incident was marked as resolved in milliseconds since e...
  • priority (int?): The priority of the incident

TestResult​

Information about a Test Result

Fields:

  • test (string): The urn of the test
  • type (TestResultType): The type of the result
  • testDefinitionMd5 (string?): The md5 of the test definition that was used to compute this result. See Test...
  • lastComputed (AuditStamp?): The audit stamp of when the result was computed, including the actor who comp...

Relationships​

Self​

These are the relationships to itself, stored in this entity's aspects

  • Consumes (via chartInfo.inputEdges)

Outgoing​

These are the relationships stored in this entity's aspects

  • Consumes

    • Dataset via chartInfo.inputs
    • Dataset via chartInfo.inputEdges

  • OwnedBy

    • Corpuser via ownership.owners.owner
    • CorpGroup via ownership.owners.owner

  • ownershipType

    • OwnershipType via ownership.owners.typeUrn

  • TaggedWith

    • Tag via globalTags.tags
    • Tag via inputFields.fields.schemaField.globalTags.tags

  • TermedWith

    • GlossaryTerm via glossaryTerms.terms.urn
    • GlossaryTerm via inputFields.fields.schemaField.glossaryTerms.terms.urn

  • consumesField

    • SchemaField via inputFields.fields.schemaFieldUrn

  • SchemaFieldTaggedWith

    • Tag via inputFields.fields.schemaField.globalTags

  • SchemaFieldWithGlossaryTerm

    • GlossaryTerm via inputFields.fields.schemaField.glossaryTerms

  • AssociatedWith

    • Domain via domains.domains
    • Application via applications.applications

  • IsPartOf

    • Container via container.container

  • ResolvedIncidents

    • Incident via incidentsSummary.resolvedIncidentDetails

  • ActiveIncidents

    • Incident via incidentsSummary.activeIncidentDetails

  • IsFailing

    • Test via testResults.failing

  • IsPassing

    • Test via testResults.passing

Global Metadata Model​

Global Graph

💡 Contributing to this documentation

This page is auto-generated from the underlying source code. To make changes, please edit the relevant source files in the metadata-models directory.

Tip: For quick typo fixes or documentation updates, you can click the ✏️ Edit icon directly in the GitHub UI to open a Pull Request. For larger changes and PR naming conventions, please refer to our Contributing Guide.