Standard Integration

DBFlow Pro: Pro hooks into Filament Standard through the workflow_definition_editor_resolver hook. Validate compiled definitions in CI.

DBFlow Pro does not replace Filament Standard. It enhances the definition editor that Standard's WorkflowResource already provides.

Division of labor

Pro changes how definitions are authored. It does not change how assignees approve tasks, how RejectStrategy routes rejections, or how WorkflowHooks map host status.

Editor resolver hook

Standard exposes a definition editor through:

• WorkflowDefinitionEditorResolver (contract)
• WorkflowDefinitionEditorResolverManager (selection)

Configure the active resolver in config/dbflow-filament.php — commonly workflow_definition_editor_resolver.

When Pro is installed, register:

• ProCanvasWorkflowDefinitionEditorResolver

This resolver can replace or enhance the Standard linear editor with a ProCanvasField-backed canvas.

Typical bootstrap flow:

1. Host registers DBFlowFilamentProServiceProvider (auto-discovery or manual bootstrap/providers.php entry).
2. Host sets workflow_resource_class in published config/dbflow-filament.php to Pro or a host subclass.
3. Host calls DBFlowFilamentPanel::register($panel) inside PanelProvider::panel() — see Installation.
4. Pro binds canvas assets and registers ProCanvasWorkflowDefinitionEditorResolver during its boot() method.
5. Opening a workflow draft in WorkflowResource loads the Pro canvas when the resolver is active and Workflow::hasDraft() is true.

Verify step 2 after every composer require dbflowlabs/filament-pro — missing DBFlowFilamentProServiceProvider is the most common reason hosts still see the Standard linear editor.

The editor (Standard or Pro) is only rendered when Workflow::hasDraft() is true. Code-synced workflows need a draft seeded after sync — see Filament UI.

Exact config keys ship with your installed dbflowlabs/filament / dbflowlabs/filament-pro version — read the published config files rather than copying stale examples.

Compilation pipeline

Canvas graph JSON
    │
    ▼
WorkflowGraphJsonParser
    │
    ▼
ProGraphBlueprintCompiler
    │
    ▼
Core definition array (nodes + transitions, schema_version: 1.0)
    │
    ▼
WorkflowDefinitionValidator::validateOrFail()
    │
    ▼
dbflow_workflow_versions (via Standard publish actions)

Parser and compiler classes live in DbflowLabs\FilamentPro. They are covered by package tests; your host app should still run validation and integration tests on compiled output.

Runtime boundary

After publish, behavior is identical to code-defined workflows:

use DbflowLabs\Core\DBFlow;

DBFlow::start('refund_dispute_approval', $dispute, $user);
DBFlow::approve($task, $actor, 'Approved.');

Pro does not intercept approve/reject calls. Operators continue to use My Tasks and instance pages from Standard UI — see Filament UI.

Publishing compiled definitions

Pro 1.0 saves canvas state to Standard draft definition_json via ProCanvasDraftSaveAdapter. The production publish path is:

1. Edit a draft in WorkflowResource (Pro canvas or Standard editor)
2. Save the draft (Pro dehydrates graph JSON automatically)
3. Validate compiled output (php artisan dbflow:validate --strict or WorkflowDefinitionValidator)
4. Publish through Standard draft/publish actions documented in Code-defined Workflows

A dedicated standalone builder route remains deferred — editing flows through WorkflowResource is the supported path today.

Demo reference

dbflow-demo integrates Pro for local canvas testing:

Use the sandbox to verify assets and graph loading before enabling Pro on a shared staging panel.

What's next

• ProCanvasField → — field and asset details
• Code-defined Workflows → — target JSON schema
• Filament UI → — Standard pages and config
• Pro Known Limitations → — scope boundaries