Build the capabilities your business needs

A custom workflow becomes easier to maintain when it reuses the customer identity, permissions and action services already in the platform. Use these guides to add a specialist capability, connect another service or build a new operating screen while keeping business context shared.

A maintenance company could build an equipment-service workspace linked to its existing customers. An agency could turn its kickoff process into an approved checklist. The bundled plugin examples show working patterns you can study and adapt directly, from a small report to a complete operator workspace.

Choose an extension path

What you want to add	Building block	A useful starting example
A page, navigation item and settings	Module	Inventory registration
A report over existing records	Report plugin	Business Pulse
A reviewed operation that creates work	Workflow plugin	Client onboarding
Information or actions from another service	Integration adapter	Stripe invoicing
A new operation an assistant can use	AI tool	Meeting commitments
Access from an external assistant	MCP	Connect your client

These are starting patterns. An App can also own new business records, a custom lifecycle and a complete operating screen. App design explains how to choose shared primitives or domain-specific work. Customization distinguishes current settings from source changes.

A module describes how a capability appears and is configured. A connector supplies access to another system. A plugin adds behavior using whatever capabilities the workspace already makes available. All three fit together, but each does a different job, so picking the right one first saves you from redoing the wiring later.

Build on what the platform already knows

Keep a customer's identity, conversations and activity attached to the existing records. Let the shared services handle permissions, proposed actions and execution results. Your extension can focus on the part that is specific to your business: what deserves attention, which inputs matter, and what the next step should be.

That is also a useful brief for a coding assistant. Give it one example to follow, the business outcome, the source records, the required approvals and a concrete acceptance test. Ask it to explain how the extension uses the existing services before introducing new infrastructure. Your first change walks through the development entry path.

An example brief you can adapt

Build a report that finds customers whose service review is due. Use existing customer and task records. Show the source record and reason for each finding. Keep the first version read-only, and include a fictional overdue example, an empty result and a disabled state.

This is a proposed extension, not a bundled service-review feature. Starting with a bounded report makes the result easier to check. You can add a separately reviewed task-creation workflow once the report is useful.

Connect another service

For a service with an API or suitable export, add an adapter that maps its information into the workspace's records. Inbound changes can use webhooks. A custom connection still needs authentication, data mapping, permissions and failure handling; not every provider is already supported.

The extension reference covers the contracts and tests. You can modify the source under its MIT license and run your own deployment. Keep changes focused so future updates remain easier to integrate.

Create software with AI

Use a coding assistant to build and verify source changes today. The planned in-app experience will let you describe an App, preview an isolated draft, inspect its code and permissions, and publish a version you can update or roll back. That builder is not shipped yet. Build Apps with a coding assistant gives a complete brief and explains the intended flow.