Standard Integration

Preview: Pro hooks into Filament Standard today, but editor UX and publish flows are still evolving. 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 Standard via DBFlowFilamentPanel::register().
2. DBFlowFilamentProServiceProvider boots and binds Pro assets + resolver integration.
3. Opening a workflow draft in WorkflowResource loads the Pro canvas when the resolver is active.

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 during alpha; 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 during alpha

Some dedicated builder routes and one-click production publish flows may be deferred or incomplete. Today, expect to:

1. Edit a draft in WorkflowResource (Pro canvas or Standard editor)
2. Validate compiled JSON
3. Publish through Standard draft/publish actions already documented in Code-defined Workflows

Do not assume a separate Pro-only publish pipeline is production-ready.

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
• Preview Limitations → — what is not ready yet