Custom PHP Code

Runs server-side code you provide as part of the field.

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, the maintained way to add server-side logic

Architect Panel → Security:

• Permissions — who can create or edit code fields

Treat this as the serious one

Server-side code runs with the platform's own access, not the user's. It is not constrained by field security, row-level access or classification unless you constrain it yourself.

Everything below follows from that.

Who may create one

Creating or editing a code field is equivalent to deploying code. It should be restricted to the people who would be allowed to deploy, and it should not be something an administrator can do because they happen to have edit access to a datastore.

This is worth checking rather than assuming — it is exactly the permission that gets granted broadly for convenience.

Enforce permissions yourself

The platform's layers protect the platform's own operations. Code you write reaches data directly, so if it returns something the viewing user should not see, that is a disclosure the surrounding permissions will not prevent.

Check, in the code, that the person is entitled to what it produces.

It runs where users wait

Code in a field executes as part of loading or saving. Something slow, or something calling an external service, makes the form slow — and an external call that hangs makes it hang.

Anything substantial belongs in a background task, not in a field.

Handle its own failures

An unhandled error here does not fail quietly — it can take the form with it. Assume every external call fails, every value can be missing and every input can be malformed, and make sure the field degrades rather than breaking the screen.

Prefer an extension

The platform has a proper home for server-side logic, with version control, review, testing and a defined interface. Code in a field has none of that: it is edited in a form, invisible to your repository, and reviewed by nobody.

Use a field only for something genuinely small and specific to that screen. Anything else is an extension.

Keep an inventory

Code fields are easy to lose track of. Nobody greps a database, and a field written three years ago runs on every form load with nobody aware of it.

Keep a list of where they are, so a security review or an upgrade can find them.

Never put credentials in one

They belong in the platform's own credential storage, where they are encrypted and rotatable. A secret in a code field is a secret in the audit trail, in backups, and visible to anybody who can view the field.

Worked example

A field calculates a risk score from values on the record — small, self-contained, no external calls, no credentials, and it checks the user's access before returning a figure. Everything more substantial in the same application is an extension, held in version control and reviewed. Both code fields in the system are listed in the technical documentation.

Recommendations

• Restrict creation as you would deployment.
• Check permissions in your own code.
• Use an extension for anything beyond trivial.
• Keep an inventory — nobody will find these otherwise.