Skip to content

Configuration Management

FlowDrop workflows and their supporting configuration are standard Drupal config entities. This means you can manage them exactly like Views, content types, or any other Drupal configuration: export to YAML, commit to version control, and deploy with drush cim.

What Is Stored as Configuration

Entity type Machine name What it holds
Workflow flowdrop_workflow Node graph, edges, labels, status
Node Type flowdrop_node_type Plugin binding, parameter settings, port config
Node Category flowdrop_node_category Category label, icon, display order

All three must be exported and deployed together — a workflow references node types by ID, and node types reference node categories.

Note

Pipelines, jobs, sessions, and interrupts are content entities (database records). They are not configuration and are not exported with drush cex. They represent execution history, not workflow definitions.

Exporting Workflows

Export your full site configuration (recommended):

drush cex
git add config/
git commit -m "Add/update FlowDrop workflows"

To export only FlowDrop configuration:

drush cex --diff | grep flowdrop

Exported files follow the naming convention:

config/sync/flowdrop_workflow.flowdrop_workflow.my_workflow.yml
config/sync/flowdrop_node_type.flowdrop_node_type.text_input.yml
config/sync/flowdrop_node_category.flowdrop_node_category.data_processing.yml

Importing Workflows

On the target environment (staging, production):

drush cim
drush cr

If you are deploying only FlowDrop changes, you can use the --partial flag to import without affecting unrelated config:

drush cim --partial --source=path/to/flowdrop-configs/

A reliable pattern for team development with FlowDrop:

  1. Develop workflows on a local or dev environment using the visual editor.
  2. Export with drush cex and commit the YAML files to your repository.
  3. Review workflow changes in pull requests — the YAML diff shows exactly what changed in the node graph.
  4. Deploy to staging/production with drush cim && drush cr as part of your normal deployment pipeline.

Exporting a Specific Workflow

To export a single workflow definition by its machine name:

drush config:get flowdrop_workflow.flowdrop_workflow.my_workflow

To export it to a file:

drush config:get flowdrop_workflow.flowdrop_workflow.my_workflow --format=yaml > my_workflow.yml

Enabling and Disabling Workflows in Config

Workflows have a status field (boolean) in their config YAML. You can control whether a workflow responds to triggers or is available for execution by setting this in config:

# flowdrop_workflow.flowdrop_workflow.my_workflow.yml
status: true   # enabled — triggers fire, workflow is executable
# status: false  # disabled — triggers are suppressed

This is useful for deploying a workflow in a disabled state and enabling it separately after verification.

Using Recipes for Default Workflows

If you are building a Drupal distribution or a reusable feature module, you can ship default FlowDrop workflows using Drupal Recipes. Place the workflow YAML in your recipe's config/ directory and it will be imported when the recipe is applied.

Troubleshooting Config Import Failures

"Configuration already exists" errors

If a workflow was created manually in the target environment with the same machine name, drush cim will refuse to overwrite it. Options:

  • Delete the conflicting config entity via the UI, then re-run drush cim.
  • Use drush cim --preview to see what will change before importing.

Missing node type or category dependencies

If a workflow references a node type that does not exist on the target environment, import will fail. Ensure you export and import all three config types together (workflows + node types + node categories).

Schema validation errors

If FlowDrop has been updated and the config schema has changed, running drush updb before drush cim resolves most schema migration issues. See Upgrading FlowDrop for the correct order of operations.

Next Steps