Custom (HTML/JS)

Renders markup and scripting you provide, inside the form.

Where to find it

Architect Panel → Data:

• Datastores — the datastore, then Table Designer to add or edit a field

Architect Panel → Layout & Pages:

• App Code — extensions, which are usually the better home

The escape hatch

Everything else on a form is described as configuration and rendered by the platform. This is where you step outside that, which makes it powerful and makes it the thing to justify rather than reach for.

Where it is warranted

• A visualisation or control no field type provides.
• Presenting information in a shape the form cannot express.
• An interaction genuinely specific to one screen.

What you take on

Custom markup is not maintained by the platform. It does not automatically follow theme changes, does not inherit responsive behaviour, and is not covered by accessibility work done elsewhere.

Every upgrade is a thing to check, and the person who wrote it will not always be there. That is the real cost, and it is paid over years rather than at the point of building.

It is invisible to everything else

Anything this field does is opaque to reporting, to the audit trail and to permissions. A value it manipulates is not a field; a decision it makes is not recorded.

If information matters, it belongs in a real field. Use this to present, not to hold.

Permissions do not apply to it

The most important caution. Field security governs the platform's own fields; it does not govern what your markup chooses to display.

If custom code fetches or renders something, that is your responsibility to gate. It is entirely possible to build a field that shows a restricted user something the rest of the form correctly hides — and it will not look like a permissions failure.

Consider an extension instead

The platform has a proper place for custom code, with version control, review and a defined interface. A field is convenient for something small and self-contained; an extension is the right home for anything that will live, grow or be reused.

Ask which you are building. "Small and self-contained" has a way of becoming neither.

Test where it will actually be used

Different browsers, a phone, a printed record, an export. Custom markup is the most likely thing on a form to behave differently across those, precisely because the platform is not managing it.

Write it for the next person

Comment it, and note somewhere that the field exists. A form containing custom code nobody knows about is a surprise waiting for whoever next touches that screen.

Worked example

A form shows a small custom visualisation of a record's progress, drawing on values held in ordinary fields. The values themselves are real fields, so reporting works and the audit trail is complete; the custom field only draws them. It is documented in the datastore's notes and checked at each upgrade.

Recommendations

• Present, do not hold — keep data in real fields.
• Gate what you render yourself; field security will not.
• Prefer an extension for anything that will grow.
• Record that it exists for whoever comes next.