Simulate an app before publishing

Simulation validates, builds, and executes saved app code with a chosen input. It lets you test an unpublished draft and inspect logs and return values. It is not an automatic rollback environment: the app API client still sends real requests, and permitted external calls can have real effects.

Use a test organization and harmless examples first. The first app, form, and widget guides provide examples that need no business-data writes.

Open Edit and select a file in the group you want to run. The header's Simulate action identifies the active group. Check that name before starting, especially when an app contains several groups.

Save changes, or choose Save and continue if the simulator prompts you. The builder uses saved project contents. Unsaved editor text is not a reliable description of the code being executed.

Changing a field definition can change inferred server types. Save the form configuration as well as the source file before retesting a Form group.

Stage	What it establishes	What it does not establish
Validate app	The project satisfies the editor's type and runtime checks	That input or downstream data is valid at runtime
Build app	The saved source can be bundled	That the entry point has executed
Start simulation or widget action	The prepared program is invoked	That a write can be undone or that publication access is correct
Successful result	That invocation completed successfully	That other inputs, audiences, or scheduled dispatch will work

Validation errors identify a file and source location. Fix those before investigating runtime access. Build failures concern the project and its supported imports. Runtime failures occur after the function starts and may involve input, permissions, network policy, or the function's own logic.

Schedule: choose Start simulation after the build completes. The entry point is main() and receives no extra input.

Form: fill the rendered form and submit it. campai validates the form definition, converts its field IDs to configured Names, and passes the values directly to main(result). For a field named reference, read result.reference.

Widget: use the rendered React interface. An action('name', …args) call invokes that named server export. Inspect both the visible result and the simulation's action/result entries.

Record changes: choose a configured event type and the record used as input. The simulator can load an existing record from the organization; it does not need to create or delete that record to call your handler. Use a designated test record and avoid logging its full contents. The event string and record are supplied to main(action, record).

The runtime's simulation flag adds API-call diagnostics. The API implementation then performs the same HTTP request through fetch; the flag does not replace write operations with mocks.

Consequently, a simulation that calls Create contact can create a contact if the app has the required access. A call to an external service can also send data or trigger that service. Test these operations only with deliberate fixtures and a cleanup plan. A timeout or failed later step does not undo an earlier successful write.

Simulation diagnostics can include API parameters. Keep personal data and secrets out of unnecessary log statements, and review who can see the app's logs.

For a form, test a valid submission, a missing required value, and a value that is structurally valid but violates your business rule. For a widget, test more than one action argument set and a controlled error. For a record handler, test the configured event branches and repeated input.

Use the expected output as an assertion. “No error” is weaker than “one repeated contact event still produces only one review item” or “the confirmation contains the submitted reference.” For API-backed code, read back the intended test record and verify the resulting fields rather than assuming an HTTP success means your workflow is complete.

After a passing simulation, review server access and the group's client access or trigger settings. Publish the intended version, then test the published entry point separately. The owner-only simulator does not prove that a public visitor, contact, or admin meets the published access policy.

For Schedule groups, manually executing main() does not verify automatic dispatch or its time zone. Follow the separate check in Run an app on a schedule.

Keep the tested source version and test inputs with your release notes or internal verification record. If you edit code after testing, repeat the relevant checks before publishing that update.