You can create multiple versions of a project before creating a build. You can create a build for any committed project version. Once created, a build cannot be editedβyouβll need to create a new project version and generate a new build to incorporate changes.
Key concepts
-
Project Version vs. Build
- Project Version is the editable snapshot of a projectβs state at a specific point in time. It contains all the resources (like processes, integrations, templates, etc.) and configurations grouped within the project.
- A Build is the deployable package of a project version. It is the compiled and immutable state that contains all the project resources transformed into executable components for the runtime environment.
-
Single Version Rule
- A build can only represent a single version of a project. If you have multiple versions of a project, each one can have a unique build. This ensures that you can clearly manage which version of the project is running in a specific environment without conflicts.
-
Consistency and Deployment
- Builds ensure that when you deploy a project to a different environment (like moving from Dev to UAT), the exact configuration, processes, templates, integrations, and all associated resources remain consistent.
- Builds are immutableβonce created, a build cannot be altered. Any updates require creating a new version of the project and generating a new build.
Creating a build
To create a build from a committed project version:1
Navigate to Version Details
Access the version details panel for the committed version you want to build. You can only create builds from committed versions, not from draft (WIP) versions.
2
Open Create Build Dialog
Click the Create Build⦠button in the version details panel. This opens the build creation modal.

Create Build
3
Configure Build Settings
In the Create build modal, configure the following settings:
- Name: The build name (defaults to the project name). This helps identify the build in the builds list.
- Build Tag Version: Set the semantic version for this build:
- Major: Major version number (for example,
1) - Minor: Minor version number (for example,
0) - Patch: Patch version number (for example,
0)
- Major: Major version number (for example,
1.0.0) and helps track different builds of the same project version.4
Save the Build
Click Save to create the build. The build is now available in the Builds section and can be deployed to runtime environments.

Build immutability
Once a build is created, it becomes immutableβyou cannot modify its contents. This ensures:- Consistency: The same build behaves identically across all environments
- Traceability: You can always identify exactly which project version is running
- Stability: Prevents accidental changes that could affect production systems
- Make your changes in the project (creating a new draft version)
- Commit the changes to create a new project version
- Create a new build from the updated committed version
Key features
-
Checksum and Integrity
- Each build includes a checksum or identifier to verify its integrity. This ensures that the deployed build matches the expected configuration and no changes have been made post-build.
-
Runtime Dependency
- The runtime environment relies on builds to determine the active project configuration. This means the runtime does not directly interact with the editable project versions but uses builds to maintain stability and reliability.
-
Version Control
- Builds are version-controlled, and each build corresponds to a specific project version. This means you can trace exactly which project configuration is active in a particular environment at any time.
Benefits
- Consistency Across Environments: Builds ensure that the same version of an project runs in different environments, avoiding discrepancies between development and production.
- Reduced Errors: Immutable builds reduce the risk of runtime errors caused by unexpected changes.
- Simplified Rollbacks: If an issue is detected with a current build, previous builds can be deployed seamlessly, providing an efficient rollback strategy.
- Streamlined Deployment: Builds allow for a straightforward deployment process, reducing the complexity of transferring configurations and resources between environments.
Managing builds
The Builds section provides a centralized interface for viewing and managing all builds for your project. Access this section by navigating to your project, switching to Runtime mode, and selecting Builds from the navigation menu.
Builds list
The builds list displays all builds created for the project, showing:- Build name and version: Displays the build name and tag version (for example,
Update_process_variables 1.0.0) - Build actions: Each build entry provides quick access to:
- Play/Run: Test the build with options to:
- Test build
- Test endpoint
- Test workflow
- Test operation
- Export: Export the build for transfer to other environments or workspaces
- More options: Additional actions via the context menu:

- View contents
- Workflow test instances
- Audit log
- Apply indexes
- Play/Run: Test the build with options to:
Searching builds
Use the Search by build tag field to quickly find specific builds by their version tag or name. This is particularly useful when managing multiple builds for the same project.Exporting builds
You can export builds directly from the Builds section. This is useful when you want to transfer a specific build (rather than a version) between environments or workspaces.1
Navigate to Builds Section
- Open FlowX.AI Designer and go to the Projects section
- Select your project and navigate to Runtime and then to the Builds section
2
Select Build to Export
- Locate the build you want to export in the builds list
- Click the Export icon (box with upward arrow) for the desired build
3
Complete Export
The build export follows the same process as version export, including the binary files option. The exported build can be imported into other environments or workspaces.
For detailed information about importing exported builds, see the Export/Import documentation.
Technical details
-
Manifest and Metadata
- Each build contains a manifest that lists all the resources included, their version IDs, and their resource definitions.
- Metadata helps identify which project version the build is derived from, providing traceability.
-
Separation of Design and Runtime
- Builds serve as a bridge between the design (config) view and the runtime view. The config view is where changes are made and managed, while the runtime view uses builds to execute stable, tested versions of projects.
-
Storage
- Builds are stored in a dedicated storage system to ensure they are separate from the editable project versions. This storage supports easy retrieval and deployment of builds.
Example use case
Imagine you have a project for customer onboarding with multiple processes, templates, and integrations. After completing development and final testing, you:- Submit changes to create Version 1.0 of the project.
- Create a build for Version 1.0.
- Deploy this build to the UAT environment for final stakeholder review.
- If any adjustments are needed, you go back to the project, make changes, and submit them as Version 1.1.
- Create a new build for Version 1.1, ensuring that the changes are encapsulated separately from the previous version.

