Extensions

An extension is custom server-side code registered with the platform, bound to a point in its behaviour, and run under controlled conditions.

Where to find it

Architect Panel → Automation:

• Extensions — the extension registry, its versions and runs

Architect Panel → Layout & Pages:

• App Code — the in-browser editor

Architect Panel → Data:

• Datastores — what an extension typically acts on

Why this rather than a code field

A Custom PHP Code field is convenient and unmanaged: it is edited in a form, invisible to version control, reviewed by nobody, and runs inside the request with the platform's own access.

An extension is the supported alternative. It is registered, versioned, resource-limited, monitored, and can be disabled without touching a datastore. For anything that will live, grow or matter, this is the right home.

How it binds

An extension declares a hook — the point in the platform's behaviour it attaches to — and a binding, which narrows where it applies: a datastore, a field, or a named key.

That binding is what stops an extension being global. Something intended to run on one datastore should be bound to it, not left to check whether it should act.

It runs out of process

The important architectural point. An extension does not run inside the request the way a code field does, which is what makes the limits and the circuit breaker below possible.

It also means an extension that hangs or exhausts memory does not take the request with it — which is the difference between a bad deployment being an inconvenience and being an outage.

Every extension is code you own

Registered, sandboxed and monitored, and still yours to maintain. It gets the same review and testing as anything else you deploy — the platform bounds the damage, it does not make the code correct.

Keep the number small

Each is a thing to maintain, test at upgrade and reason about when something behaves unexpectedly. A handful of well-chosen extensions is manageable; a long list accumulated over years is a liability nobody fully understands.

Prefer configuration where it exists

The standing principle. Before writing an extension, check whether a workflow, a journey, a rule or a calculated field would do — configuration is visible, reviewable and does not need testing at every upgrade.

Record what each one does

Name, purpose, what it binds to, who owns it. Extensions are written once and consulted years later, usually urgently, by somebody who was not involved.

Worked example

An organisation runs three extensions: one scoring risk on referral, one pushing approved orders to a supplier, one generating a nightly reconciliation. Each is bound to one datastore, each is documented with an owner, and everything expressible as a workflow was left as one.

Recommendations

• Use extensions rather than code fields for anything lasting.
• Bind narrowly rather than checking inside the code.
• Prefer configuration where it can do the job.
• Document each one with an owner.