What to expect

Whatever you are moving from, these are the differences people most often notice. None of them are obstacles; all of them are worth knowing before you publish.

Scripts run in a sandbox

Field scripts are ordinary JavaScript, with a defined set of functions and no access to the network, storage or page. Most field-level scripts port directly. Anything that fetched data, read the device, or touched the page needs another approach — usually a Record Lookup, a Smart List, or a webhook. See the script function reference.

Read-only decides whether a calculation can be overwritten

A calculated field that is not read-only fills in its value and lets the person type over it. Mark it read-only for the calculation to own the value. There is no separate “allow override” setting. See Values people can overwrite.

The field key is the durable identity

Labels can change freely. Changing a field key is a migration that moves data, and the places that mention the key are listed rather than rewritten. If your old forms had stable element or column names, keep them as keys. See Field keys.

Subforms are real records

A subform entry is a record on the child form, with its own permissions, status and history — not only a row inside the parent. Use a repeatable section for rows that only make sense inside the record. See Sections, repeatables and subforms.

Approval is a workflow

Records on a form that requires review wait in a queue for a manager’s decision, and the decision is recorded. Somebody holding an assigned record can edit it but cannot approve it. See Approvals.

Offline is the default

Every form is available offline once downloaded, and the app says whether a record has left the phone yet. See Working offline.

Choice fields store the value, not the label

Exports, webhooks and the API carry northgate, not Northgate Depot. Reports built on the old tool’s labels will want a lookup, or the label columns the export includes. See Sending data elsewhere.