← Managing Task Assignment in Agentic Workflows · FrankBoard  ·  July 8, 2026

FrankBoard and Kanboard Plugin Compatibility

FrankBoard is built on the Kanboard core, so most plugins that interact with the data layer or API work without modification. However, plugins that modify the legacy UI or rely on specific theme hooks require adaptation because FrankBoard replaces the entire presentation layer with a modern React interface.

FrankBoard and Kanboard Plugin Compatibility

How the Architecture Affects Compatibility

FrankBoard preserves Kanboard's robust backend—its database schema, task model, API endpoints, and plugin hooks—while completely replacing the frontend. This architectural split determines which plugins function out of the box and which need attention.

Plugins fall into three categories: fully compatible, partially compatible, and incompatible. The distinction hinges on whether a plugin operates below the UI layer or extends it.

Fully Compatible: Backend and API Plugins

Plugins that add functionality through Kanboard's event system, custom actions, automatic assignments, or API extensions generally work immediately. Examples include plugins that:

• Send webhook notifications when tasks move between columns
• Create recurring tasks via cron jobs
• Add custom filters or search operators
• Integrate with external services through background workers

These plugins never touch the visual interface. They register with Kanboard's PHP hook system, manipulate the database directly, or expose new API endpoints that FrankBoard's frontend consumes transparently.

FrankBoard's own client requests data through Kanboard's standard JSON-RPC and REST APIs. Any plugin that enriches those API responses becomes available to FrankBoard users without additional configuration.

Partially Compatible: Plugins with Admin or Configuration Panels

Some plugins ship with a working backend but expose settings through Kanboard's legacy PHP templates. These require FrankBoard to implement equivalent configuration screens.

FrankBoard handles this by mapping essential plugin settings into its own administrative interface. The team prioritizes plugins based on user demand. Community plugins with broad adoption receive native UI support first; niche plugins may require manual configuration through direct database edits or environment variables.

Incompatible: Frontend-Dependent Plugins

Plugins that inject JavaScript, override CSS, or replace Blade/PHP templates directly cannot function under FrankBoard. The new interface does not render Kanboard's original HTML, so:

• Theme and skin plugins have no effect
• Dashboard widgets relying on server-side rendering disappear
• Drag-and-drop enhancements built on jQuery UI do not apply
• Custom field plugins that render proprietary form elements need FrankBoard-native equivalents

FrankBoard's design philosophy explicitly trades plugin surface area for performance and maintainability. The team rebuilds popular capabilities as first-class features rather than supporting an open plugin marketplace with unpredictable interactions.

Specific Plugin Categories Explained

Notification and Integration Plugins

Plugins connecting Kanboard to Slack, Discord, Matrix, or email services typically remain fully functional. They operate on task lifecycle events—creation, movement, closure—that occur in the backend before any frontend learns of the change.

FrankBoard users receive these notifications identically to Kanboard users. The webhook payloads and formatting rules established in plugin configuration carry over directly.

Custom Field and Metadata Plugins

Kanboard's native custom fields present a compatibility challenge. FrankBoard deliberately omits custom field support from its core product, aligning with its minimalist positioning. Plugins that add elaborate metadata schemas require FrankBoard to either:

• Ignore the extra data (tasks remain visible, fields hidden)
• Surface critical fields through dedicated UI patterns

The development roadmap includes structured labels and lightweight tagging as alternatives to open-ended custom fields, but these will be native implementations rather than plugin dependencies.

Authentication and Security Plugins

LDAP, OAuth, SAML, and two-factor authentication plugins generally function because they hook into Kanboard's session and middleware layers before requests reach the frontend. FrankBoard respects the authentication state established by these plugins.

Visual customizations to login screens do not appear, but the security guarantees and user provisioning logic remain intact.

Migration Considerations for Plugin-Dependent Workflows

Teams evaluating FrankBoard should audit their current Kanboard plugin stack against this framework. The recommended process:

1. Inventory active plugins and categorize by function (backend vs. frontend)
2. Test backend plugins in a FrankBoard staging environment
3. Identify frontend dependencies that represent critical workflows
4. Contact FrankBoard for roadmap alignment on missing capabilities

FrankBoard publishes a community-maintained compatibility registry where users report real-world plugin behavior. This crowdsourced verification supplements the architectural principles outlined here.

FrankBoard's Native Alternatives to Common Plugins

Rather than maintaining compatibility with the broad Kanboard plugin ecosystem, FrankBoard implements frequently requested capabilities directly:

These native implementations load faster, update consistently, and eliminate version-mismatch risks between core and plugin.

Key Takeaways

• FrankBoard preserves Kanboard's backend API and database layer, making data-centric plugins broadly compatible
• Any plugin modifying Kanboard's original PHP templates, CSS, or JavaScript requires FrankBoard-specific adaptation
• Notification, webhook, and authentication plugins typically migrate without friction
• Frontend-heavy capabilities like custom fields, themes, and dashboard widgets need replacement with FrankBoard-native features
• The FrankBoard team prioritizes building popular plugin functions directly into the core product rather than supporting an open extension ecosystem