Customization & extensibility

Every brand runs differently. Each HQ can make SignaUnit its own and fit it into existing tools, without forking the product.

The approach has three layers:

1. A standard core that every brand shares.
2. Per-HQ customization, done through configuration rather than custom code.
3. An extension layer for sending SignaUnit events to your own systems and, later, for connecting tools.

One standard core for every brand

Every tenant gets the same core: priorities and objectives, follow-through at each unit, and a rollup of what moved. The meaning of a priority, a version, an acknowledgement, a check-in and the rollup is identical for every brand.

That sameness is deliberate:

• Upgrades reach everyone. No brand is stuck on a custom branch that can’t take improvements.
• Results stay comparable. Adoption and KPI change against baseline are calculated the same way everywhere, so the rollup means what it says.
• Customization can’t weaken the guarantees. Tenant isolation, the audit log and the owner-first rules sit in the core, beneath anything a brand configures.

See Concepts for the core model.

Per-HQ customization (configuration, not code)

HQ admins tailor SignaUnit to their brand through settings. Nothing here requires a developer or a separate deployment.

Custom fields

HQ can add its own fields to objectives, initiatives, units and check-ins. For example, a “launch wave” field on initiatives, a “territory type” field on units, or a “campaign code” field on objectives.

• Each field has a type (such as text, number, date, yes/no or a choice from a list), and values are checked against that type when they’re saved.
• Fields are defined per tenant. One brand’s fields are never visible to another.
• Custom field values are stored inside the tenant’s isolated data and are covered by the same row-level security as everything else. See Security and data isolation.

Checklists and audit templates

HQ configures its own checklists and audit templates: the items, how each is scored and weighted, and the severity of findings. Templates are versioned, so editing one that’s in use creates a new version and past results stay comparable. See Audits.

HQ-defined objective types Planned

Beyond the built-in kinds of priority (lead response, conversion, profitability, a launch or a brand standard), HQ will be able to define its own objective types. Each type carries its own default KPI, follow-through cadence and check-in template, so a new priority of that type starts with sensible settings already filled in.

Every objective type still has to tie to helping units find or convert leads, or run profitably.

Extension layer

Outbound webhooks

SignaUnit can notify your own systems when something happens, so your HQ dashboards, data warehouse or internal tools stay current without polling. Webhook events cover:

Event	Sent when
Priority published	HQ publishes a priority or a new version of one
Priority assigned	A priority comes into scope for a unit, for example when a new unit opens
Check-in recorded	An owner or an import records progress against a priority
Audit closed	An audit is completed and its corrective actions are settled
KPI updated	A KPI value changes from an import or a check-in

Every delivery is:

• Signed, so your receiving system can verify it came from SignaUnit and wasn’t altered.
• Retried if your endpoint is temporarily unavailable.
• Logged, so HQ admins can see what was sent, when, and whether it succeeded.

Webhook payloads follow the same owner-first rules as the rest of SignaUnit: they describe units, franchisees and outcomes, never per-person activity by franchisee-side users.

Scoped API Planned

A scoped API will let your developers read and write SignaUnit data from your own systems. Access will be granted per tenant through API keys or OAuth clients, each limited to the scopes you choose (for example, read the rollup but not change priorities). API access stays inside your tenant’s isolated space.

Plugins and tenant-installed apps Planned

Later, SignaUnit will support a small plugin model: integrations a tenant chooses to install, each declaring up front which scopes it needs. HQ admins will see and approve those scopes before installing, and can remove a plugin at any time.

The plugin model isn’t part of v0.1.

Connect to the tools you already use Planned

SignaUnit is designed to sit alongside your existing stack, not replace it. Through the connector framework, it will pull KPIs in and push status out to the systems your HQ already runs:

• FranConnect and other franchise management suites, through sign-on links and deep links, so SignaUnit sits next to the suite your owners already open. Planned
• Point of sale systems for food and retail brands, for sales and ticket measures. Planned
• CRMs and one field-service / operations connector for conversion and customer follow-up. Planned
• QuickBooks for unit-level revenue and margin. Planned

None of these connectors is built yet. In v0.1, results come in through CSV KPI import and manual check-ins. See the Integrations roadmap for the full list and order, and KPI import for how imported values are used.

Guardrails

Customization is meant to make SignaUnit fit your brand, not to change what it is. A few rules hold no matter what is configured:

• Customization never weakens tenant isolation. Custom fields, templates, webhooks, API clients and plugins all live inside the tenant boundary and are covered by row-level security and the cross-tenant leak tests.
• The owner-first line still applies. HQ deals with franchise owners about outcomes. Custom fields, checklists and webhooks can’t be used to direct, track or manage franchisee staff. Custom fields on check-ins describe the unit’s result, not who did the work.
• Changes are recorded. Creating or changing custom fields, templates, webhooks and API access is written to the tenant’s audit log.

SignaUnit is designed around standardizing outcomes. It isn’t legal advice. Your franchise counsel should review how your brand configures fields, checklists and templates.

What’s in v0.1

Capability	Status
Standard core (priorities, follow-through, rollup)	v0.1
Custom fields on objectives, initiatives, units and check-ins	v0.1
Checklists and audit templates	v0.1
Signed, retried, logged outbound webhooks	v0.1
HQ-defined objective types	Planned
Scoped API with per-tenant keys or OAuth clients	Planned
Plugin model with declared scopes	Planned
Connectors for FranConnect, POS, CRM, QuickBooks and one field-service / operations connector	Planned

If your brand depends on a system, tell us what you’re rolling out.