Skip to main content

Celonis Product Documentation

Deploying Studio packages in a Dev/QA/Production setup

When you can’t develop or build the Studio package within the productive package we recommend the following deployment process:

Before you begin

To deploy a Studio package in Dev/QA/Production setup you must have the following:

  • 1 DEV (development) package:

    • Necessary for the development, testing, and application maintenance purposes.

    • Analyst build and test here.

  • 1 PROD (production) package:


    To create this package for the first time, duplicate the DEV package and assign it the right Data Model and necessary permissions.

    • Contains only the release-ready versions of the application, which is the actual package used by end users.

    • End user permissions are set here.

    • No manual changes to the content are made here.

Depending on IT requirements, permissions, content structure requirements DEV and PROD package can be in different teams, different spaces, same space.

Deployment process:


The process has to be done by a user with edit permission on both packages (PROD and DEV).

Build in DEV → publish and test DEV → (iterate) → DEV package ‘copy to’ and overwrite PROD package * → review& publish PROD package.

  • Package key and asset keys of the PROD package remain the same.

  • The asset URLs remain the same.

  • Data Model assignment remains the same (the data model assigned to the PROD package is not overwritten).

  • Package dependencies of the PROD package are kept.

  • The package name gets overwritten. The name of the PROD package is updated to match the name of the DEV package.

  • When an asset gets overwritten, it keeps the same key, only the content is updated.

  • Package and asset history, including log history of skills, of the PROD package remains the same.

  • All assets are overwritten, not just the ones that were changed.

  • Any new assets added only in the PROD package will be removed.

  • In general, task status and task assignment within the PROD package remain the same.

  • When the change is on the skill, and it includes changing the filter definition used in the smart sensor then:

    • The skill is overwritten and the configuration is the same as on the DEV package

    • With the next execution of the skill (on Data Model reload, or Knowledge Model change, or package publishing) the sensor will look at all cases and check if the new cases match the conditions and then create tasks accordingly.

    • Existing tasks are not changed (status, assignee stays the same).

  • When the change is on the skill, and it does not include a filter change but only a task name change, a new action change then.

    • The skill is overwritten and the configuration is the same as on the DEV package.

    • No new signals are identified, and all existing cases with tasks do not get the updated task description and task name.

The permissions set on the PROD package and assets remain the same.

  • The comments written in the DEV package are not transferred to the PROD package.

  • Comments written in the PROD package are kept.

  • In general, comments appear within a package instantly, regardless if they were written in the published package or Studio, without having to publish the package.

  • After the creation, an augmented attribute only supports editing the possible values, nothing else.

  • When this is changed then:

    • The new possible value is added list of existing ones.

    • The existing ones are not affected.

Action flow connections are local to the package, they are not global. Users with edit on a package, can access and use all connections created for that package, but not for other packages

  • When the DEV package with at least a connection overwrites the PROD package:

    • If the connection does not exist yet in the PROD package, then it does not get copied over.

    • Connections are never transferred over between packages.

    • For the action flow to work, you need to create the connection in the PROD package and link the action flow accordingly

  • When the same action flow is connected to source A in the DEV package and the action flow in the PROD package is connected to source B:

    • After overwriting the PROD package, the action flow in the PROD package needs to be relinked to the connection to source B.

    • The connections that were already in the PROD package remain there.

  • Data pools can be copied from one team to another using the ‘Copy to’ functionality or from one cluster to another using the content-cli.

  • Data pools cannot be overwritten.

If the PROD package is overwritten (not deleted and renamed), the bookmarks will still be valid as long as the fields used for filtering (according to the bookmark definition) still exist in the new version.