Working with publishes

Learn how to publish projects from one environment to another.

You can share the integration projects with others within your organization by using the publish feature. This feature is designed to streamline collaboration, facilitate deployment, and help ensure that integration solutions can be easily accessed and used by relevant stakeholders.

Key aspects of the publish feature.

  • You can publish your integration projects, making them available to other users who need to view, use, or further develop the solutions. This feature is useful for team collaboration and multi-departmental projects.
  • Published projects can be deployed across different environments, such as development, testing, and production. It simplifies the process of moving projects through various stages of the lifecycle.

The publish project feature helps ensure that your integrations can be effectively shared, maintained, and used across the organization.

Note:
  • You need administrator access to publish projects.
  • You cannot publish projects while logged in through an external SSO application.
  • All sensitive data such as, passwords, API keys, and tokens is not included in the published project from these configurations.
  • The entire project configuration is published, and you cannot select individual configurations. For example, if your project contains multiple integrations and accounts, all configurations are exported as a single package, regardless of the integrations you select. For instance, selecting three integrations out of five still exports the configurations for all five.

  • As reference data varies across different environments, you need to reconfigure the reference data on the respective environment. If you are publishing a project that has a flow service with reference data, the reference data is not published along with the flow service. Create the reference data in the destination environment.

Publish Wizard

You can publish a project using the Publish Project option available in the overflow menu on a project card.

On clicking the Publish Project option, you can configure the project before publishing.

The Publish wizard contains the following pages.

  • Select assets

  • Confirm dependencies

  • Publish settings

The Select assets page lists all error-free assets that are available in the project. The assets are categorized based on their type such as workflows, flow services, messaging subscribers, or REST APIs. You can select either all or specific assets that must be published. The assets are listed based on the following guidelines:

  • Assets that contain errors are not listed as they cannot be published to another environment.

  • Assets are listed based on the user’s access privileges. For example, User A selects workflow A as an asset and publishes a project. User B selects workflow B as an asset and publishes the same project. Next time that they republish the project, only workflow A is preselected for user A, and only workflow B for user B on the Select assets page.

The Confirm dependencies page lists all dependent assets for the assets that were selected in the Select assets page.

Dependent asset is the asset that is being used by your asset (main) that is selected for publishing. For example, if workflow A (main) calls workflow B during its execution, this means that the workflow A depends on workflow B. Hence, workflow B is considered as dependent. So, even if you do not select assets in the Select assets page, all dependent assets are considered by default for publishing along with the main asset. Thus, the Confirm dependencies page provides a complete view of all assets you intend to publish in one place.

You can provide details about the publish action such as name, description, and the environment on which you want to publish from the Publish settings page.

Note:

  • Only the environments that you register with your tenant are listed in the Publish settings page.

  • The destination environment must be on the same or higher version as compared to the source environment. If the destination environment is on a lower version than the source environment, an error appears.

  • To publish projects across regions, both the source and destination regions must be on the same version.