App Code

The In-Browser Editor

App Code is the in-browser editor where extension code is written, checked and tried out. It opens full screen, keeps every save as a version, and stores the code in the platform's database rather than in files on the server, so nothing has to be deployed by hand.

Where to find it

Architect Panel → Layout & Pages:

• App Code — the editor for extensions, opened in a full-screen window

Architect Panel → Automation:

• Extensions — where a version is approved, put live, rolled back or switched off

Who can use it

Any administrator can open App Code, create extensions, write and save code, run the checker and do a dry run. Only an architect can approve a version, publish it, roll back or put an extension live. Anyone else who tries sees "Only an architect may" followed by the action, and a reminder that they can write and check code and ask an architect to put it live. Because every administrator can reach it, treat access to the administration screens as access to App Code.

What it edits

The tree on the left has sections for Extensions, Snippets, Document Templates, E-mail Templates and Legacy Custom PHP. Today only Extensions can be edited. Opening an item in another section says "Editing ... is not wired up yet." Legacy Custom PHP, where it is shown, is read-only. Use the Filter… box to find an item in the tree.

The screen

• Top bar: New, Save, Check, Dry run and Publish, plus the command palette (Ctrl+K).
• Editor: the open file. With nothing open it reads "Nothing open".
• Side tabs: Assistant (AI help writing code), Versions (every saved version, with publish and roll-back buttons for architects), Data (the datastores and fields the code can use) and Activity.
• Keys: Ctrl+S saves, Ctrl+Enter checks, Ctrl+R does a dry run, Ctrl+W closes the file and Ctrl+K opens the palette.

Creating an extension

1. Click New. Answer What should it do? by choosing the hook, then give it a Name and a Key. The key must start with a letter and use lowercase letters, numbers and underscores, 3 to 64 characters.
2. Write the code, or describe what it should do in the Assistant tab and click Write it. The assistant's code is saved as a draft for you to review.
3. Click Save (Ctrl+S). Each save that changes the code creates a new version; nothing goes live.
4. Click Check. Findings appear beside the lines they concern, with a summary of how many there are. A version that fails is still saved, but cannot be approved.
5. Click Dry run to run it once without writing or sending anything.
6. An architect sets the extension's binding (see Extensions), then clicks Publish, which approves the version, publishes it and makes it live in one step.

There is no autosave and no checking as you type: save and check deliberately.

What goes wrong and how to tell

• "This page has been open a long time and its security token expired.": reload and save again.
• "No AI provider is configured for writing code on this installation": the assistant needs an AI provider. See AI Gateway.
• "This hook needs the extension runner, which is not available on this system, so it cannot be dry run here.": the hook runs outside the platform and this system has no runner.
• The assistant's code fails the checker: it sometimes suggests things extensions cannot do. Read the findings and correct it, or ask again more specifically.

Worked example

A developer opens App Code from Layout & Pages, clicks New, chooses the workflow step hook and names it "Check credit limit" with the key check_credit_limit. They write the code, save, and click Check: one finding about a function extensions may not call. They fix it, save again (version 2), check clean and run a dry run. They are not an architect, so Publish is refused; they ask the architect, who reviews version 2, sets the Bound Key to match the workflow step and clicks Publish.

Recommendations

• Save and check little and often; versions are free.
• Review assistant output line by line before saving it as your own.
• Keep publishing with architects, and keep the architect group small.
• Remember App Code edits extensions only; templates are edited in their own screens.

Working on Extension Code

This article is for the architect who commissions, reviews and approves extension code. It sets out what extension code can and cannot do today, what the code checker enforces, and what to look for before approving a version, so you can judge a request and a piece of code without writing either.

Where to find it

Architect Panel → Layout & Pages:

• App Code — where the code is written, checked and dry run

Architect Panel → Automation:

• Extensions — where it is approved, put live and monitored

What extension code can do

• Work with what the hook hands it. When drawing a field, that is the field, its current value, whether the form is being viewed or edited, and the current user's display name and groups. It is not given the rest of the record.
• Read and write platform data, where the hook allows it. The Hooks card on the Extensions screen lists each hook's capabilities. One query returns at most 1,000 records.
• Write messages to the Error Log, which is the way to leave a trace for later diagnosis.

What it cannot do today

• Call outside services or websites. There is no way for an extension to make a web request, whatever the Outbound hosts setting says.
• Send e-mail or handle files.
• Read stored credentials such as API keys.
• Run on record save, on a page, as an endpoint or as a scheduled task. Those hooks are listed but the platform does not call them yet. Use a field or a workflow step.

A request that needs any of these is not an extension today. Look at Workflow Builder steps or API Clients instead.

What the code checker enforces

Every saved version is checked before it can be approved. It refuses, among other things:

• A full file. Extension code is the body only, and code that starts with an opening PHP tag is refused with a message saying so.
• Functions that are not on the allowed list: "... is not on the list of functions an extension may call".
• Code that is too large or too deeply nested, over 64 KB or too complex.

Passing the checker means the code uses only permitted building blocks. It does not mean the code is correct, efficient or safe with your data: that is what review is for.

Permissions are the code's responsibility

Data read and written by an extension does not go through the field-level security that applies on screens. If an extension shows or changes data, the code must itself decide who should see or change it, typically from the user's groups it is given. Ask about this in every review.

Reviewing a version before approval

1. Open the extension in App Code and select the version in the Versions tab. Check the Gate result is a pass.
2. Ask the developer to walk you through it: what it reads, what it writes, and what happens when a value is empty.
3. Run Dry run. It writes nothing and sends nothing, and it supplies no record, so it shows the code runs rather than that every case is handled.
4. Check the binding (Bound to) is the field or workflow step you intended.
5. Approve and put it live, then watch Recent runs on the Extensions screen.

What goes wrong and how to tell

• Repeated failures in Recent runs after going live: usually an empty or unexpected value. Roll back and have it handled.
• "the code checker is not installed on this server, so no extension can be accepted": the hosting administrator must install it before any version can be approved.
• Assistant-written code that will not pass: the assistant may suggest building blocks that do not exist. Treat its output as a draft.

Worked example

A manager asks for an extension that looks up a supplier's credit rating from an outside service when a purchase request is saved. The architect checks this article: extensions cannot call outside services and the record-save hook is not called yet, so the request is redirected to a workflow with an outbound API call. A second request, to show a warning on the purchase form when the order value exceeds the requester's limit, fits a field extension. The architect reviews the code, confirms it reads only the fields it needs, dry runs it, binds it to the order value field and puts it live.

Recommendations

• Check a request against the can-and-cannot lists before anyone writes code.
• Ask how empty values are handled in every review.
• Insist the code enforces its own permissions where it shows or changes data.
• Prefer configuration wherever it can do the job.