Creating Knowledge Models
A Knowledge Model (KM) is a foundational Studio asset that defines the business logic and semantic layer for your Celonis applications. By mapping raw Data Model tables to meaningful business entities and KPIs, the KM ensures consistency and reusability across all package components.
In Studio, you can create a KM either during the initial package creation or by adding it to an existing package. You have the flexibility to build a Base model from scratch or Extend an existing model to customize content for specific use cases while maintaining a core logic dependency."
To understand how Studio assets are structured, see: Workflow and content structure.
Knowledge Model types
When creating a KM, there are two types available to you:
Base: Use this type when you are starting a new project with a specific Data Model. A Base KM automatically scans your Data Model to populate business entities, providing a clean slate to define your unique KPIs and records. It is the standard choice for bespoke, standalone solutions.
Extension: Use this type to create a "child" model that inherits all the logic from a "parent" package. By adding a dependency, you can reuse global KPIs while adding local-specific attributes or records. This is ideal for maintaining a "Core" corporate standard while allowing individual departments or regions to customize their views without duplicating work.
With both KM types, you can then create additional entities or edit existing entities.
You can create a KM when you're creating a Studio package with either the View or Analysis initial content option selected. This creates a draft package with a KM that includes a number of entities auto generated from the Data Model associated with that package.
To create a Studio package from your Studio space:
Click Create Package.
Configure your package using the following fields:
Package name: Internal reference for this package.
Description: Optional added information, allowing other team members to read more information about this package.
Initial content: Select View or Analysis.
Data Model: Select the Data Model to use for this package.
Package key: Edit or copy the package key if you need to give other applications access to this package.
Language: Select which language this package should use as its default language.
Click Create.
The package is created and a KM asset is available. This KM is named after the Data Model selected when creating it, so in this example is it based on a Purchase to Pay Data Model.
Click into the Knowledge Model to view, edit, and create entities.
You can create a KM within an existing package, with no limit to the number that can exist within that package:
Click New asset - Knowledge Model.
Configure your KM using the following fields:
Name: An internal reference for this KM.
Key: The unique key used by other assets to reference this KM.
Data Model variable (optional): The variable that references the data you want to use in this KM. This variable can be updated or edited once the KM is created by using the Data Model drop down:
Knowledge Model type: Select between base or extend an existing KM. See: Knowledge Model types.
Click Create.
The KM is created and added to the package.
In addition to using the New asset - Knowledge Model steps outlined in the section above, you can also extend an existing Knowledge Model in a package by clicking Settings - Extend.
 |
This opens the Create Knowledge Model view and automatically lists the package containing the KM you're extending as a dependency.
You can then click Add Dependencies to select other Studio packages within your Celonis Platform team (depending on the permissions you hold for those assets). Adding a package dependency allows you to extend its Views and Knowledge Models to reuse their content.
 |
You can show and hide Knowledge Model entities from the user interface using the View Options panel. This removes the reference to the entity from the user interface only, making it easier for you to view and manage the data and variables that you need.
Hidden entities are only removed from the Knowledge Model interface. As such, they are still available within the Knowledge Model and retain their usage within Studio assets that reference the Knowledge Model.
