This guide covers how to customize Dawiso Knowledge Applications: add an attribute, change a template, modify layout, add a workflow, add a relation, configure search, and configure permissions. All customizations use either a patch package (to modify an existing application) or a bridge package (to connect two applications). They require package development expertise or assistance from the Dawiso support team.

Applications and package keys

ApplicationPackage KeyTypical Object Types
Business Glossarybusiness_glossaryBusiness Domain, Business Term, Business Indicator, Business Rule, Diagram
Code Listcode_listCode List (parent), Code List Item (child)
Data Dictionarydata_dictionaryAttribute Domain
Data Modeldata_modelModel Folder, Data Model, Data Entity, Data Attribute, Processing Unit
Data Product Catalogdata_product_catalogProduct Domain, Data Product, Data Contract
Logical Modellogical_modelModel, Logical Diagram, Entity, Attribute
DocumentationdocumentationDocument Set, Document
Report Catalogreport_catalogFolder, Report
DiagramsdiagramsDiagrams Folder, Diagram
KPIkpiDomain, KPI

Add a custom attribute

Use this procedure to add attribute fields (such as “Data Sensitivity”, “Review Date”, or “Target Value”) to any object type in any application. This is the most common customization.

  1. Create a patch package targeting the application’s base package:

    {
  "type": "patch",
  "key": "my_patch_add_sensitivity",
  "name": "Add Data Sensitivity to Business Term",
  "basePackageKey": "business_glossary",
  "runAfter": "business_glossary",
  "dependsOn": ["business_glossary"]
}

  2. Define the new attribute type with an asset-level add action. Choose features that match the field type:

    FeatureRenders as
    is_htmlRich text editor
    is_datetime / is_dateDate picker
    is_number + sort_by_numberNumeric input
    is_yes_noCheckbox toggle
    is_url_linkClickable hyperlink
    acceptableCodetableValuesDropdown from a Code List
    "attributeTypes": [
  {
    "action": "add",
    "key": "cust_data_sensitivity",
    "name": "Data Sensitivity",
    "features": [
      { "key": "is_html", "value": true }
    ]
  }
]
    Warning

    Feature values have strict type safety: use boolean true/false, never the string "true". Strings cause silent failure.

  3. Assign the attribute to the target object type using a property-level add action:

    "objectTypes": [
  {
    "action": "update",
    "key": "business_term",
    "attributeTypes": [
      { "action": "add", "key": "cust_data_sensitivity" }
    ]
  }
]

  4. Update the template to display the attribute (see Modify the template layout below).

  5. Optionally add search features to make the attribute findable (see Configure search below).

Tip

Check existing attributes before creating duplicates. Business Glossary ships with Description, Definition, Calculation, and Synonym. The core package provides 50+ reusable attribute types (core#description, core#url, core#date_created, and others) — reuse these before creating custom ones. For the full catalog, see Attribute Types & Features.

If the attribute type must exist before it can be referenced, use runAfter in your patch to control installation order.

Modify the template layout

Use this procedure to change how attributes, panels, and components appear on an object’s page. Every object type has two templates: main (full page view) and objectDetail (side panel preview). For the full template reference, see ObjectType Templates.

Layout zones

ZoneWidthContainsRules
centerArea~70%Text attributes, child tables, relations, diagramsComponents go directly as array items. Never wrap in a panel — panels in centerArea hide children.
rightArea~30%Collapsible metadata panels (Ownership, Properties, Classifications)Components must be wrapped in a panel with a title.

Steps

  1. Create a patch package (or extend one you already have) targeting the application.

  2. Add a component to the centerArea — for example, displaying a custom attribute:

    "objectTypes": [
  {
    "action": "update",
    "key": "business_term",
    "templates": {
      "main": {
        "centerArea": [
          {
            "action": "add",
            "addToEnd": true,
            "componentId": "cust#attr#data_sensitivity",
            "type": "attributes",
            "values": ["cust_data_sensitivity"]
          }
        ]
      }
    }
  }
]

  3. Or add a new panel to the rightArea — for example, a “Compliance” panel on a Data Entity page:

    "rightArea": [
  {
    "action": "add",
    "addToEnd": true,
    "componentId": "cust#panel#compliance",
    "type": "panel",
    "title": "Compliance",
    "components": [
      {
        "componentId": "cust#attr#data_sensitivity",
        "type": "attributes",
        "values": ["cust_data_sensitivity"]
      }
    ]
  }
]

  4. Update the objectDetail template as well so the side panel preview stays consistent.

Available component types

TypeWherePurpose
attributescenterArea, rightArea (in panel)Display attribute values
panelrightArea onlyCollapsible grouping container with title
componentBothReference a shared component (such as core#ownership_generic)
relationscenterAreaRelation lists showing linked objects
api-tablecenterAreaDynamic table with filtering
section-titlecenterAreaHeader with optional anchor: true for navigation
codetable-labelrightArea (in panel)Display Code List values as badges

Add or modify a workflow

Use this procedure to add workflow states (such as Draft, In Review, Approved, Deprecated) and define the allowed transitions between them. You can also change an existing workflow by patching individual states or transitions. For the full workflow reference, see Workflows & Automation.

Steps

  1. Define workflow states in your package with a key, display name, color, and position value. States are ordered by position, not by their array position in JSON.

    "workflowStates": [
  { "key": "draft", "name": "Draft", "color": "#6B7280", "position": 1 },
  { "key": "in_review", "name": "In Review", "color": "#F59E0B", "position": 2 },
  { "key": "approved", "name": "Approved", "color": "#10B981", "position": 3 },
  { "key": "deprecated", "name": "Deprecated", "color": "#EF4444", "position": 4 }
]

  2. Define workflow transition triggers specifying allowed state changes. Only explicitly defined transitions are permitted:

    "workflowTransitionTriggers": [
  { "fromStateKey": "draft", "toStateKey": "in_review" },
  { "fromStateKey": "in_review", "toStateKey": "approved" },
  { "fromStateKey": "in_review", "toStateKey": "draft" },
  { "fromStateKey": "approved", "toStateKey": "deprecated" }
]

  3. To modify an existing workflow, use a patch package with update actions on specific workflow states or transition triggers, or add actions for new states and transitions.

Additional options

  • Mandatory attributes: Mark attributes with Is_Mandatory to require them before a transition is allowed (for example, Definition must be filled before moving to In Review).
  • Multi-approver thresholds: Use changeThresholdTypeKey on a transition to require multiple users to approve.
  • Automation triggers: Fire actions on state changes — send notifications, set attribute values (for example, using {currentUtcDate} for a review date).
Warning

For Data Product Catalog, the Data Market search form filters by workflowState. If you add new states, update the searchForm facet configuration to include them — otherwise products in the new state return zero results in the Data Market.

Add a custom relation to another application

Use this procedure to add relation links between applications — for example, connecting Business Terms to Data Dictionary attribute domains, or KPIs to Data Products. For common relation patterns, see Package Patterns.

  1. Create a bridge package — a third intermediary package that depends on both applications. This avoids circular package dependencies:

    PKG_BusinessGlossary  <--  PKG_Bridge  -->  PKG_DataDictionary
    {
  "type": "package",
  "key": "cust_bridge_glossary_dictionary",
  "name": "Bridge: Business Glossary - Data Dictionary",
  "dependsOn": ["business_glossary", "data_dictionary"]
}

  2. Define a relation type in the bridge package with forward and reverse names:

    "relationTypes": [
  {
    "key": "cust_has_domain",
    "name": "Has Domain",
    "reverseName": "Is Domain For",
    "fromObjectTypeKey": "business_term",
    "toObjectTypeKey": "attribute_domain"
  }
]

  3. Assign the relation to both object types using property-level add actions.

  4. Update templates on both sides to include a relations component referencing the new relation type key so users can see and manage the links:

    {
  "componentId": "cust#rel#has_domain",
  "type": "relations",
  "values": ["cust_has_domain"]
}
Tip

Check existing relations before creating new ones. Many applications ship with built-in relations:

  • Business Glossary: Related, Mentions
  • Data Model: Implemented As, Has Domain, Foreign Keys
  • Data Product Catalog: Contains, Has Input/Output Contract
  • Logical Model: Specialization, Association, Implements
  • Report Catalog: Implements, Business Objects
  • KPI: Is KPI In, Related, Is Described By

Use this procedure to make attributes discoverable through Dawiso’s Elasticsearch-powered search. For the full search configuration reference, see Search Configuration.

  1. Add search features to the attribute type definition. An attribute without any is_search_type_* feature is invisible to Elasticsearch — it does not appear in search results or facet filters.

    FeatureElasticsearch BehaviorBest For
    is_search_type_textFull-text analysis with stemmingDescription, Definition, Calculation, Notes
    is_search_type_termExact-match keyword, supports facetsClassifications, labels, status fields
    is_search_type_boolBoolean facetYes/no flags
    is_token_textKeyword tokenizationTags
    is_search_default_result_textIncluded in search result snippetsAny field you want visible in results

    Common combinations:

    • is_search_type_text + is_search_default_result_text — full-text searchable and shown in result snippets
    • is_search_type_term + is_search_default_result_text — exact-match filterable and shown in results
    • is_search_type_text + is_search_type_term — full-text searchable and available as a facet filter

  2. Ensure a search index exists that maps the object types and their attributes to Elasticsearch fields:

    "searchIndexes": [
  {
    "key": "cust_glossary_index",
    "objectTypeKey": "business_term",
    "attributes": [
      { "key": "core#name" },
      { "key": "core#description" },
      { "key": "cust_data_sensitivity" }
    ]
  }
]

  3. Ensure a search query references the index to define how searches execute.

  4. Ensure a search form exists to define the user-facing filter panels and result columns.

  5. Run a targeted reindex after adding or changing search features. Prefer a targeted index refresh per index key — avoid running a global RefreshIndex as it rebuilds all indexes and can take hours on large deployments.

Configure permissions per workflow state

Use this procedure to control who can edit or view objects based on the combination of workflow state and user relation.

Steps

  1. Define conditions in your package configuration. Each condition specifies:

    PropertyPurpose
    userRelationTypeKeyWho — such as core_business_owner, core_steward
    workflowStateKeyWhen — such as draft, in_review, approved
    editableCan modify the object (true / false)
    visibleCan see the object (true / false)

  2. Combine conditions to build your access matrix. For example, to let only the Owner edit during Draft and only the Steward edit during Review:

    "conditions": [
  {
    "userRelationTypeKey": "core_business_owner",
    "workflowStateKey": "draft",
    "editable": true,
    "visible": true
  },
  {
    "userRelationTypeKey": "core_steward",
    "workflowStateKey": "in_review",
    "editable": true,
    "visible": true
  }
]

    All other users see the object as read-only in these states.

Evaluation rules

  • Multiple conditions combine with OR logic — any matching condition grants access.
  • A condition with only a userRelationTypeKey (no state) applies across all workflow states.
  • A condition with only a workflowStateKey (no relation) applies to all users in that state.
  • No conditions at all means the default access applies (visible and editable by all).
Warning

A condition referencing an invalid userRelationTypeKey or workflowStateKey silently evaluates to false — it denies permission without any error message. Verify that both keys reference valid, existing entities.

Best practices

  • One change per patch. Name patches descriptively (such as cust_glossary_patch_add_sensitivity). This makes debugging straightforward and rollback granular. For advanced patch techniques, see Patch Packages — Advanced Guide.
  • Update both main and objectDetail templates for consistency between full-page and side-panel views.
  • Reuse core attributes. The core package ships 50+ attribute types. Check core#description, core#url, core#date_created, and others before creating custom ones.
  • Declare implicit dependencies. Adding core#ownership_generic to a template requires declaring core_business_owner and core_steward in the object type’s userRelationTypes[] array — otherwise the Ownership panel renders empty with no error.
  • Reindex after schema changes. A full Elasticsearch reindex is required for search features to take effect.
  • These customizations apply identically across all Knowledge Applications. Only the specific basePackageKey, object type keys, and existing attributes differ.