Especially in fusion teams, developers want to make a finished feature or an intermediate state of a service available to other team members for testing while they continue to work on the same service. This is easily possible in the Designer by using the test environment for developing (refer to Working with the Test Environment for details) and deploying to the test server only when necessary. You only need to deploy your service if you want to allow other team members to test new features or if you want to run regeression tests against your test server.

We recommend using container deployment as the default deloyment target starting with PAS 23.1. For further information see:

The Deployment Controls are available on the service details page (see chapter Managing the Service Details for further information). Click on the Service panel tab (service name) to open the details page:

Select your deployment target the first time you deploy.


  • Container deployment: Your user must be assigned the xuml_container_admin profile.
  • Integration (Bridge) deployment: You user must be assigned the integration_user profile and he must have an integration user account created by an integration administrator.

Refer to Administration Guide > Overview of Standard Profiles.

Enable edit mode of the deployment properties and choose between Integration Component or Container.

We recommend to enter a version number and increase the number with each deployment.

Expert Advice

By default, each newly created service gets number 0.1.0 assigned. We recommend to increase the version number before redeploying each time you have made relevant changes to the service. You can change the version number in section General of the Deployment Properties. Follow the concept of semantic versioning.

In case of deployment problems, comparing the version number and the number of the deployed version can help to find out which version of the service is running.

Save the deployment properties to continue.

Now use the deployment controls to deploy the service to your chosen target:

Use this option to deploy the service to the selected deployment target.

Use this option to open the management UI of the selected deployment target:

Use this option to open the test UI for the service-related API.
Use this option to open the deployed service in a new browser tab.

Executing the Deployed Service

The deployed service is accessible via option Open Application in the deployment controls section. The start page of the deployed service looks exactly the same as that of the test service:

The handling of the deployed service is also the same:

  • Users can create new instances and execute the process.
  • Users can access the instance overview.

The difference is: The deployed version does not change, even if the developer changes the service in the test environment.

Example: Test Service vs. Deployed Service

A developer created a simple test application, containing only a user task with an assigned test form.

The test form contains two input fields and a button.

The developer deploys this version.

After the deployment of this version, he starts to extend the test form.

Test Service

The developer opens the test service.

The developer starts the process to create a new instance.

The adapted form opens.

Deployed Service

The tester opens the deployed service.

The tester starts the process to create a new instance.

The deployed version of the form opens.

  • No labels