Package Patterns — Proven Structures

Standard Dawiso packages use recurring structural patterns. Applying these patterns saves development time and reduces configuration errors.

Pattern 1: Folder / Container

When to use: An objectType that groups child objects. Workspaces containing dashboards, schemas containing tables, catalogs containing domains.

A folder objectType has minimal attributes — typically name and description. Its template uses an api-table component in the center area to list child objects filtered by the parent’s ID.

{
  "key": "workspace",
  "name": "Workspace",
  "iconKey": "core_folder",
  "colorKey": "core_gray",
  "attributeTypes": [{ "key": "core#name" }, { "key": "core#description" }],
  "templates": {
    "main": {
      "centerArea": [
        { "componentId": "workspace#attribute#description", "type": "attributes", "values": ["core#description"] },
        { "componentId": "workspace#api_table#children", "type": "api-table", "filter": { "parentObjectId": { "value": "@objectId" } } }
      ]
    },
    "objectDetail": {
      "area": [
        { "type": "tabs", "values": [{ "label": "Overview", "values": [{ "type": "attributes", "values": ["core#description"] }] }] }
      ]
    }
  }
}

The @objectId placeholder resolves to the current object’s database ID at render time. The api-table component queries for objects whose parentObjectId matches this value.

Dependency checklist:

• core package installed
• core_folder icon key exists (or substitute another valid icon)
• Child objectTypes define a parentObjectId relationship

Pattern 2: Business Object

When to use: Conceptual entities with ownership and governance. Business terms, data products, KPIs, policies, data quality rules.

A business object has rich descriptions, ownership panels, classification tags, and workflow states. This is the most common pattern in data governance packages.

{
  "key": "business_term",
  "name": "Business Term",
  "iconKey": "core_tag",
  "colorKey": "core_blue",
  "attributeTypes": [
    { "key": "core#name" },
    {
      "key": "core#description",
      "features": [
        { "key": "is_search_type_text", "value": true },
        { "key": "is_search_default_result_text", "value": true }
      ]
    },
    {
      "key": "core#abbreviation",
      "features": [
        { "key": "is_search_type_term", "value": true }
      ]
    },
    {
      "key": "core#classification",
      "features": [
        { "key": "is_search_type_term", "value": true }
      ]
    }
  ],
  "userRelationTypes": [
    { "key": "core_business_owner" },
    { "key": "core_steward" }
  ],
  "workflow": {
    "key": "term_workflow",
    "states": [
      { "key": "draft", "name": "Draft", "initial": true },
      { "key": "in_review", "name": "In Review" },
      { "key": "approved", "name": "Approved" },
      { "key": "deprecated", "name": "Deprecated" }
    ],
    "transitions": [
      { "from": "draft", "to": "in_review" },
      { "from": "in_review", "to": "approved" },
      { "from": "in_review", "to": "draft" },
      { "from": "approved", "to": "deprecated" }
    ]
  },
  "searchIndex": {
    "key": "term_index",
    "objectTypeKeys": ["business_term"]
  },
  "searchQuery": {
    "key": "term_search",
    "searchIndexKey": "term_index"
  },
  "templates": {
    "main": {
      "centerArea": [
        {
          "componentId": "business_term#attr#description",
          "type": "attributes",
          "values": ["core#description"]
        },
        {
          "componentId": "business_term#attr#details",
          "type": "attributes",
          "values": ["core#abbreviation"]
        }
      ],
      "rightArea": [
        {
          "componentId": "core#ownership_generic",
          "type": "component"
        },
        {
          "componentId": "core#classification_generic",
          "type": "component"
        }
      ]
    }
  }
}

The userRelationTypes declaration is required for the ownership panel. Without it, core#ownership_generic renders an empty panel with no error. The workflow enables state-based access control through attribute conditions.

Dependency checklist:

• core package installed
• userRelationTypes includes core_business_owner and core_steward
• Workflow states and transitions defined
• is_search_type_* features on all searchable attributes
• searchIndex and searchQuery declared

Pattern 3: Connector Entity

When to use: Technical metadata objects scanned from external systems. Snowflake schemas, Power BI reports, SQL Server databases, dbt models.

Connector entities have auto-populated attributes from data integration scans. They reference a data source definition and typically include lineage metadata.

{
  "key": "snowflake_schema",
  "name": "Snowflake Schema",
  "iconKey": "core_database",
  "colorKey": "core_purple",
  "attributeTypes": [
    { "key": "core#name" },
    { "key": "core#description" },
    { "key": "core#external_id" },
    { "key": "core#date_modified" },
    { "key": "core#row_count", "features": [{ "key": "is_number", "value": true }] }
  ],
  "dataIntegration": {
    "dataSourceDefinitionKey": "snowflake_source_def",
    "mappings": [
      { "sourceField": "SCHEMA_NAME", "attributeKey": "core#name" },
      { "sourceField": "DESCRIPTION", "attributeKey": "core#description" },
      { "sourceField": "SCHEMA_ID", "attributeKey": "core#external_id" }
    ]
  }
}

The dataIntegration block maps fields from the external source to Dawiso attribute types. Scanned data populates these attributes automatically during integration runs.

Dependency checklist:

• core + core_code_lists packages installed
• hierarchyDefinition asset with levels matching objectType hierarchy
• hierarchyDefinitions[] array on application referencing the hierarchy
• objectTypeRelations with core#isParentOf for each parent-child pair
• dataSourceDefinition with queries for each scannable objectType
• provider asset with connectionTemplate for the setup wizard UI
• dataIntegrations[] on application referencing the data source
• graphMetamodel if lineage or ER diagrams are needed

Pattern 4: Dashboard

When to use: Analytics pages with charts and metrics. No objectTypes involved — dashboards display aggregated data through API-backed components.

{
  "pages": [
    {
      "key": "quality_dashboard",
      "name": "Data Quality Dashboard",
      "iconKey": "core_chart",
      "route": "/dashboards/quality",
      "components": [
        { "componentId": "quality_dashboard#score_chart", "type": "chart", "apiEndpoint": "/api/quality/scores", "chartType": "bar" },
        { "componentId": "quality_dashboard#trend_line", "type": "chart", "apiEndpoint": "/api/quality/trends", "chartType": "line" },
        { "componentId": "quality_dashboard#issues_table", "type": "api-table", "apiEndpoint": "/api/quality/issues" }
      ]
    }
  ]
}

Dashboard packages define pages, not objectTypes. Each component references an API endpoint that returns chart or table data.

Dependency checklist:

• core package installed
• API endpoints exist and return data in the expected format
• Icon keys reference valid core icons

Pattern 5: Relationship Bridge

When to use: Connecting objectTypes from two different packages. A bridge package declares only objectTypeRelations and depends on both source and target packages.

Bridge packages are small — typically under 100 lines. They exist solely to declare relationships between object types owned by different packages.

{
  "packageKey": "term_to_table_bridge",
  "name": "Business Term to Table Bridge",
  "autoInstall": true,
  "dependencies": [
    { "packageKey": "core" },
    { "packageKey": "glossary" },
    { "packageKey": "snowflake_connector" }
  ],
  "objectTypeRelations": [
    {
      "key": "term_documents_table",
      "name": "Documents",
      "sourceObjectTypeKey": "glossary#business_term",
      "targetObjectTypeKey": "snowflake_connector#snowflake_table",
      "reverseName": "Documented by",
      "cardinality": "many_to_many"
    }
  ]
}

The autoInstall flag triggers automatic installation when both dependency packages are present. The package declares exactly three dependencies: core, the source package, and the target package.

Dependency checklist:

• core package, source package, and target package installed
• Both referenced objectType keys exist in their respective packages

Pattern 6: Code List

When to use: Dropdown values for codetable-backed attributes. Countries, categories, severity levels, priority labels, status options.

Code list packages define simple objectTypes with a name attribute and pre-populated entries.

{
  "packageKey": "priority_levels",
  "name": "Priority Levels",
  "dependencies": [{ "packageKey": "core" }],
  "objectTypes": [
    { "key": "priority_level", "name": "Priority Level", "iconKey": "core_tag", "attributeTypes": [{ "key": "core#name" }] }
  ],
  "objects": [
    { "objectTypeKey": "priority_level", "values": [
      { "key": "critical", "label": "Critical", "value": "critical", "sortOrder": 1 },
      { "key": "high", "label": "High", "value": "high", "sortOrder": 2 },
      { "key": "medium", "label": "Medium", "value": "medium", "sortOrder": 3 },
      { "key": "low", "label": "Low", "value": "low", "sortOrder": 4 }
    ]}
  ]
}

Other packages reference this code list through the acceptableCodetableValues feature on an attribute type:

{
  "key": "priority",
  "features": [
    { "key": "acceptableCodetableValues", "value": "priority_levels#priority_level" }
  ]
}

Dependency checklist:

• core package installed
• Object entries include both label (display text) and value (internal identifier)
• Referencing packages use the full {packageKey}#{objectTypeKey} syntax in acceptableCodetableValues

Pattern Selection Guide

Scenario	Pattern	Key indicator
Groups child objects	Folder / Container	Parent-child hierarchy with api-table listing
Governed business concept	Business Object	Ownership, workflow, classification
External system metadata	Connector Entity	Data source mapping, auto-populated attributes
Charts and metrics page	Dashboard	No objectTypes, API-backed components
Linking across packages	Relationship Bridge	Only objectTypeRelations, three dependencies
Dropdown values	Code List	Simple objectType with pre-populated entries

Combining Patterns

Most packages combine patterns. A data catalog package might include Folder/Container objectTypes for catalogs, Business Object objectTypes for terms, Code List objectTypes for classifications, and Relationship Bridge references to external connectors. Group related objectTypes with their templates and attributes for maintainability.

Gotchas