Studio
The Studio allows you to combine functional expertise with the power of Celonis Process Mining to create scalable Apps. Celonis Studio is your one-stop development platform to build, test, and edit Execution Apps and Instruments in a single, low-code interface.
Benefits of Celonis Studio
Create or configure an Execution App in days.
Reuse components from your best deployments.
Combine analytical and execution capabilities.
Leverage template views for each business user.
 |
You can access Studio via the left-hand navigation menu.
Your business users can access your apps by clicking on the left-hand navigation menu and selecting "Apps".
Core components of an app
The Studio is structured by your Apps, also called Packages. Packages are collections of Views, Knowledge Models, Skills and Analyses.
Views in a Studio app
Views are the key user experience component for new Apps built on Celonis. They empower your business users with a unified interface to consume data, create insights and act on knowledge.
A View is a collection of components and tools to provide business users with focused access to our business context and engines. Learn how to configure and use Views.
Knowledge Models
Knowledge Models act like a centralized place to consistently and reliably define metrics through configuring Business Knowledge Entities. Business Knowledge Entities are concrete definitions of KPIs, Benchmarks, Variables, Filters, and many more. Standardizing the development and definition of these commonly used Business Knowledge Entities solves a crucial scalability problem, ensures consistency across the enterprise, and accelerates optimization efforts through the reuse of commonly used Business Knowledge Entities. Learn how to build and use Knowledge Models.
Skills
A Skill is the integral part of each automation as it defines its procedure by a sequence of events. It consists of Sensors and Actions. Learn how to make use of automation in your Execution App.
Analysis
An Analysis helps to identify execution gaps in your process. Within a Package, you can create Analyses as you might know from Process Analytics. Currently, there are slight differences between the analysis service offered in Process Analytics and the analysis service that is offered in the Package. Creating analyzes in the studio has the benefit of versioning and better integration with other services offered by Celonis. It is now possible to keep multiple analyzes with different data models next to each other.
To create an analysis in a package, you need to hover on the package name, click on the “+” sign, and select the “Analysis” option. You can then define the name of the analysis and the data model variable to assign the analysis to a data model. The Analysis Key is used to link other assets such as views to this Analysis.
 |
Folders
Folders can be used inside packages for organizational purposes. Inside a package, you can create as many folders as you want, and you can directly create new assets inside the folders or move existing assets inside folders with drag and drop. Furthermore, you can create folders inside folders, however, you cannot have more than nine levels of folder hierarchies. This is limited for usability purposes. Also, it is not possible to set permissions on folders, for this capability, see Studio Spaces or Studio Packages.
Working with packages
Creating a package
You can create a new Package within the Studio.
Select “New Package” on top of the left-hand navigation panel.
Name the Package.
When naming a Package, the Package Key will automatically populate. This key is a unique identifier of the package.
Select the Package Type (App, Library or Instrument).
Press Create.
 |
Please note that the package name can be changed later, however, the package key as a unique identifier cannot be changed after being defined.
Also, the package type cannot be changed after creating the package. You can find information on your package by clicking on the three-dot menu next to the operational app and then select settings.
 |
Package Variables
Note
You can now include perspectives in Studio Packages for object-centric process mining. Perspectives are views on the object-centric data model including a subset of the object types and event types that is relevant to a process, or to another grouping that you want to analyze.
You include perspectives in a Package using Data Model variables. A package can't contain a mix of case-centric Data Models and object-centric perspectives. They all need to be the same type as the one you use in the first Data Model variable that you add to the Package - so either all perspectives, or all case-centric Data Models. To swap a package between case-centric and object-centric models, you'll need to take all the variables of the previous model type out before adding the new type.
What is a variable and why is it helpful?
A variable is used to store information on the package level and it can be referenced across the package, inside the different assets. By storing the data model, connections (and more to come) inside variables and referencing the variables inside assets, instead of for example hardcoding the DM id inside the KM or the Analysis, you can easily change the variable value once and all of the usages will get updated automatically.
Data Model Variables
You can create data model variables in the package settings, in the Variables section, or directly ad hoc where you need them: when creating a new Knowledge Model or a new Analysis.
Package Settings
Here, using the three-dot menu, you can change the assigned Data Model.
Create Knowledge Model
The two-step creation flow guides you through choosing the Data Model to assign to your variable to adding a variable name and a variable description. Add a description so others understand what type of data is expected for this specific data model variable.
You can use and call the variable in your package's assets, e.g. in a Knowledge Model or Analyses configuration.
The beauty of package variables is that the Data Model assigned to it can easily be changed without further adjustments in where it was initially called from, like a Knowledge Model. The variable’s key always remains the same and the only place where adjustments are required is the package variables settings. Here, you can also lookup which Knowledge Model is currently using a particular variable.
Knowledge Model
kind: BASE
metadata:
key: my-knowledge-model
displayName: My Knowledge Model
dataModelId: ${{my-datamodel}}Package Dependencies
Package dependencies are other packages that are required for this package to operate. By adding a package as a dependency, its Views and Knowledge Models can be reused using this extension mechanism.
Dependencies can be added in the package settings, in the Dependencies section, as well ad-hoc when extending an asset.
Package Settings
Here you see which version you are dependent on. If there is a new version of the dependency available, it will appear here, and you can update your dependency.
Click on the package name to preview the structure of your dependency.
Ad-hoc
Publishing and Versioning
Publishing to a team
Changes done within Studio are not visible to your Business Users until they are published to the team. This allows you to thoroughly test new features and configurations. The Studio saves all published versions, so you are able to change the current version to a previously published version.
When publishing to the team, the Views and Analyses will be shown to Business Users on their Apps. However, Business Users will not be able to see Knowledge Models or Skills that you have created in the Studio.
You can publish a package by clicking on the Publish button in the top right corner of the Studio. An overlay will appear summarizing which package assets have been modified since the last publication. You need to name the new package version you are about to publish ("New Version").
Versioning Packages
 |
As Celonis best practice, the versioning format should be MAJOR.MINOR.PATCH (e.g. 1.0.0). This format can be defined as follows:
Major: A complete update or shift in the current view. This can include changing different components, moving a handful of components around, or adding and removing visuals from the view. These changes would greatly affect Business Users if no communication was properly given in advance.
Minor: Tweaks in the apps that won’t necessarily require communication or messaging to Business Users. Examples include tweaking a KPI, making color changes, or changing chart types.
Patch: Very small changes that may go unnoticed to a Business User. Examples include an update to the calculation of a KPI, or changes in titles.
Bringing back past versions of your Package
In Studio, you can now load past published versions of your package into your current draft, to bring back old features/past states of your package.
The unpublished package, your current working version is called "Draft".
The current published package version, seen in Apps can be identified by the tag "Published".
Older published versions are tagged as "Archived".
 |
By 'Loading a past version' you load that version into your current working draft. If you have changes in your draft, those will be lost.
Loading a past version does not affect the 'published' package.
if you load an older version, you will not lose any of the versions in between.
'Unpublished changes in X assets' lets you know how far your current draft is from the published version, seen in Apps.
Permissions in Studio
Within the Studio you can limit who can access specific packages in their Apps. Next, you can choose which users can use, edit, delete or manage permission within the package. Finally, you can set the permissions on the Celonis Spaces level.
Permission settings can be set on the following levels
Entire Space
Users will have access to everything within this space. This includes all packages including its views, analysis, and skills. You can grant permissions to an entire package by clicking on the three-dot menu next to a space name and selecting permissions.
 |
In Studio Studio, you have the following permission opportunities: Use all packages, create packages, edit space, edit all packages, delete space, delete all packages, manage permissions.
 |
For more detailed information please refer to the respective documentation.
Entire Package
Users will have access to everything within this package. This includes all views, analyses, and skills. You can grant permissions to an entire package by clicking on the three-dot menu next to a package name and selecting permissions.
 |
You can then choose whether a user or user group can use, edit or delete a package. You can also select if users themselves can manage permissions.
 |
View, Analysis, or Skill specific
Users will only have access to the specified view, analysis, or skill. Keep in mind that you may have to grant users access to all assets related to an app, or they may not be able to see certain components within their app. For example, if one of your apps uses a skill within the package, you will have to grant the user access to both the app and skill to ensure proper functionality. You can grant permissions to an asset such as a view, analysis, or skills by clicking on the three-dot menu next to an asset name and selecting permissions.
 |
You can then choose whether a user or user group can use this asset.
 |
Remember that even if your Business Users have permissions to skill, they won't be able to see it in their left side navigation panel in Apps.
Tip
To learn more about Celonis Studio, see the following free online training tracks at Celonis Academy: