Incorporating Conscia into Your Development Process
Conscia enables development teams to fully integrate the DX Engine Configuration into their software development lifecycle, providing version control, governance, and secure access management for mission-critical orchestration flows. Each environment’s configuration is represented as plain JSON and can be managed either as a single file or as a structured folder containing individual element definitions (e.g., connections, components, webhooks).
Conscia provides a dxengine-config CLI tool to help teams easily import and export DX Engine configurations between environments, automate configuration updates as part of CI/CD pipelines, and maintain a transparent history of all orchestration changes using their choice of version control. Whether you use the Conscia tool or script one of your own, you have the ability to ensure that your development process is auditable, configurations are portable, enabling collaboration, rollbacks, and compliance without relying solely on the web interface.
Option 1: Edit through the UI
Best for smaller teams or early-stage projects where simplicity and speed are key.
In this approach, all team members work within a shared environment and use the Conscia UI to configure orchestration flows, components, and connections. Each developer can make updates independently, though simultaneous edits to the same entity will result in the most recent change being saved. To maintain version history and enable rollbacks, teams can periodically export the full DX Engine configuration as a single JSON file or as a structured folder using the CLI utility described below. This option offers the fastest setup with minimal operational overhead.
Option 2: Edit Via Folder Structure
Recommended for larger teams and enterprise workflows where collaboration, governance, and version control are essential.
In this model, developers manage DX Engine configurations directly as JSON files organized by entity type (e.g., components, connections, webhooks). Using the dxengine-config CLI tool, teams can export, modify, and re-import these configurations as part of their standard Git-based workflow. This enables fine-grained version tracking, clear ownership of changes, and integration with CI/CD pipelines for automated deployment. Each modification can be reviewed, approved, and logged, providing a transparent and auditable orchestration development process.
Using environments to enforce a separation of concern
Teams may choose to work in a variety of different ways. One way of working together is to have teams work in different environments so that each team is in full control over the set of flows and components that are related to the experience that they are responsible for delivering. For instance, you may choose to have one team/environment for checkout flows and another for product discovery experience.
Option 1: Separate Environments for Individual Orchestration Teams
Ideal for organizations with multiple teams managing distinct digital experiences or domains.
In this setup, each orchestration team operates within its own dedicated DX Engine environment, maintaining full ownership of the flows and components relevant to their area (e.g., checkout, product discovery, loyalty). The frontend application calls the environment-specific endpoints directly, ensuring a clean separation of concerns and preventing teams from inadvertently impacting each other’s work.
This approach promotes autonomy, faster iteration, and easier debugging, as each environment is isolated yet can still reference shared components through a common “shared environment” when needed.
Example Workflow:
Option 2: Separate Environments - Merge environments into a single master environment
Recommended when multiple teams contribute to a unified production environment or shared application experience.
In this model, each team continues to develop and test within its own DX Engine environment, but their configurations are periodically merged into a single master environment. This master environment acts as the central orchestration layer that the frontend application connects to, consolidating all approved flows and components from across teams.
This approach provides the best of both worlds — allowing teams to work independently while ensuring a consistent, centralized production experience. It also simplifies governance, as a designated system administrator can manage deployments, approvals, and environment synchronization.
Example Workflow:
DX Engine Configuration CLI tool
All Orchestration Flows are defined by a DX Engine Configuration which is stored as plain JSON. One environment maps to one DX Engine Configuration. The DX Engine Configuration can be stored on disk as:
| Format | Description |
|---|---|
| DX Engine Config File | One file with one JSON object |
| DX Engine Config Folder | Multiple files split across folder where each folder represents a type of DX Engine Element (e.g. connection, component, webhook, etc.) This is the recommended format and lends itself to versioning. |
The DX Engine Configuration Tool is a CLI tool, dxengine-config, that allows you to import and export DX Engine Configurations. As such, it is useful for:
- Configuration Management
- Versioning
- CI/CD
- Backup and Restore
- Migration
- Sharing & Collaboration
Structure of a DX Engine Config Folder
channels/
mychannel.json
myOtherChannel.json
components/
componentCodeOne.json
componentCodeTwo.json
secrets/
secretToken.json
otherSecret.json
Each filename is the code of the element. For example: components/componentCodeOne.json describes the Component with the Component Code componentCodeOne.
Import a DX Engine Config File
dxengine-config importFromFile --server prod --token xxx.yyy.zzz --log mylog.json <<customerCode>> <<environmentCode>> <<filename>>
When this is run, a backup is created in a folder called _backups alongside the a DX Engine Config File.
Import a DX Engine Config Folder
dxengine-config importFromFolder --server staging --token xxx.yyy.zzz --log mylog.json <<customerCode>> <<environmentCode>> <<folder>>
When this is run, a backup is created in a folder called _backups inside the specified a DX Engine Config Folder.
Export to a DX Engine Config File
dxengine-config exportToFile --server prod --token xxx.yyy.zzz <<customerCode>> <<environmentCode>> <<filename>>
Export to a DX Engine Config Folder
dxengine-config exportToFolder --server staging --token xxx.yyy.zzz <<customerCode>> <<environmentCode>> <<folder>>
Log File structure
The log file is a JSON file that contains the following fields:
| Field | Description |
|---|---|
| ts | Timestamp in ISO date format |
| message | Message describing the action |
| elementType | Type of DX Engine Element (e.g. connection, component, webhook, etc.) |
| code | Code of the DX Engine Element |
| message | Message describing the action |
| isError | Boolean indicating if this log line is an error |
Example:
{ "ts": "2023-09-18T14:27:00Z", "message": "Importing DX Engine Config..." }
{ "ts": "2023-09-18T14:30:00Z", "isError": true, "elementType": "component", "code": "get-product", "message": "Error. Connection Code 'acme' does not exist." }
Having the log file be a JSON file makes it easier to parse and process with tools like jq.
Working with DX Engine Config Files
If you prefer to work with DX Engine Config Files directly (instead of using the Web UI), the process would be as follows:
- Export to a DX Engine Config Folder
- Add the DX Engine Config Folder to your version control system
- Whenever a files are chanhged, import the DX Engine Config Folder into the DX Engine
To get access to this CLI tool, please reach out to your Customer Success Manager.