# 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):

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

To export only FlowDrop configuration:

```bash
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):

```bash
drush cim
drush cr
```

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

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

## Recommended Workflow for Teams

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:

```bash
drush config:get flowdrop_workflow.flowdrop_workflow.my_workflow
```

To export it to a file:

```bash
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:

```yaml
# 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](https://www.drupal.org/docs/develop/drupal-apis/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](upgrading.md) for the correct order of operations.

## Next Steps

- **[Upgrading FlowDrop](upgrading.md)** — Update procedures and `drush updb`
- **[Production Deployment](../guide/production-deployment.md)** — Queue workers and operational guidance
