Plugins

A plugin is an installable package that adds a feature to Bizinly — screens, public pages, menu items, its own settings, its own data — without changing Bizinly's own code. A project is the app plus the list of plugins it has chosen; a plain Bizinly installation with nothing installed runs exactly the same app, just with nothing extra linked in.

What a plugin can add

Extension point	What it means
Back-office screens	Pages inside the app's own navigation, under the plugin's own area, shown only to people with the right permission.
Public pages	Pages served on the installation's own domain (a storefront, a legal page), outside sign-in, under the plugin's own base path.
Menu items	Its own entry in the sidebar, shown only while the plugin is switched on and only to a role that may see it.
Settings	A form generated from the plugin's own settings list — including write-only fields for anything secret, never shown back once saved.
Data and migrations	Its own database tables, named under its own prefix, created by its own migration files — never another plugin's tables, and never the host app's own.
Permissions	Its own permission keys, checked exactly the way the app checks its own — a person needs the right one before a screen, an action or a tool lets them through.
Scheduled jobs	Recurring work (a due reminder, a nightly job), run per installation, only while the plugin is active there.
Record panels	A section added to an existing screen — a document or a customer's detail page — shown only while the plugin is active and only where it says it applies.
Tools for an AI assistant	The plugin can expose its own tools alongside Bizinly's own (see Connect with MCP), checked against the same permission as its screens.

A plugin only ever reads and writes its own tables directly; anything it needs from the host app — creating a document, looking up a product — goes through the app's own functions, the same way the app's own screens would call them. That keeps one plugin from reaching into another's data, and keeps every write behind the same permission check and the same audit trail as the rest of Bizinly.

Discovering and switching plugins on

Which plugins are available to an installation is decided when it is built — a project lists the plugin packages it wants, and only those are compiled in. A plugin that is not listed adds no code and no risk to a project that does not need it.

Whether an available plugin is actually on is a separate, per-installation decision, made afterwards in the admin area (Admin › Plugins): switched on or off, with its own settings filled in, independently of any other installation running the same package. A plugin that needs another module or another plugin to be on shows that plainly rather than half-working.

Switching a plugin off keeps its data — the tables stay, nothing is deleted — so turning it back on later picks up where it left off.

Existing plugins

Bizinly's plugins so far, as examples of what the system supports:

• Content — pages such as terms, privacy and cookies, written with a small editor, kept in versions, with SEO and a sitemap.
• Shop — an online storefront: cart, checkout, coupons, delivery options, and web orders that land as ordinary orders, invoices and payments.
• Inventory (coming soon) — stock per product and warehouse, receiving, counts, transfers and shipments; designed, and not yet switched on for a workspace — see Inventory and warehouses.
• Social — an activity feed on documents and customers, groups, comments and moderation.
• Manufacturing — bills of materials, routings, and production orders scheduled from sales orders.
• Projects — projects with tasks on a board, time logged against them, and a customer-facing summary.
• Workforce — rotas, clock in/out, leave, and timesheets.
• Payroll — pay runs built from Workforce's hours, with payslips and a bank-ready salary file, for the country rules it currently supports.
• Property management — holiday-rental units, a shared calendar, bookings synced with external calendars, and the invoices a stay produces.

Not every plugin fits every project: Payroll needs Workforce underneath it, and some are only offered on a full Bizinly installation rather than a starter project.

Anatomy of a plugin

A plugin is one npm package. Its shape, based on Bizinly's own Content plugin:

@bizinly/plugin-content/
  src/
    manifest.ts     the manifest below
    index.ts         the manifest plus data functions shared by every host
    bizinly/         the Bizinly-hosted screens and public pages
    starter/         the same plugin's part for a starter project
  migrations/
    0001_content.sql
  package.json

Its manifest declares what it is and what it needs — a simplified version:

export const manifest = {
  id: 'content',
  name: 'Content',
  version: '0.1.0',
  app: 'bizinly',
  hosts: ['bizinly', 'starter'],
  capabilities: ['routes', 'public-routes', 'menu', 'migrations'],
  permissions: ['content.manage'],
  menu: [{ label: 'Content.Menu_Pages', href: '/', icon: 'file', permission: 'content.manage' }],
  publicBase: '/legal',
  routes: [
    { path: '/', area: 'app', page: 'admin', permission: 'content.manage' },
    { path: '/[slug]', area: 'public', page: 'page' },
  ],
  tables: ['content_pages', 'content_page_versions'],
  migrations: ['0001_content.sql'],
};

A manifest that asks for something it was not declared for — a table outside its own prefix, a screen without the matching capability — fails at build time, before it ever reaches an installation.

Building a plugin, or getting one of Bizinly's own installed on your deployment, is arranged with the Bizinly team — book a call.

Related: Overview & architecture, The starter project, Connect with MCP.