Events and Startup

Page Flow controls what happens when a Page or Form initializes and how it responds to events after it opens.

Use startup logic to prepare the initial Page experience. Use event-driven logic to respond to actions such as selecting a Button, changing an input, or choosing an action in a Widget. Some workflows also include asynchronous operations that finish later, such as Database requests or Cloud Flow calls.

A well-organized Page Flow keeps these responsibilities distinct so users see the right information at the right time.

For the visual editing canvas and block connections, see Editor Basics. For guidance on selecting block families, see Choosing Blocks.

Understanding When Logic Runs

Different parts of Page Flow run at different points in the Page or Form experience.

Execution Context	When It Runs	Typical Purpose
Startup	As the Page or Form initializes, according to the supported Page Flow runtime.	Establish initial state, set up interactions, and begin initial data loading.
Event Handler	When the event configured for a particular element or control occurs.	Respond to a click, value change, menu selection, or another supported event.
Asynchronous Completion	After a pending operation returns or a deferred task completes.	Use returned data, handle failure, or update the interface after processing.
Form Lifecycle	At supported stages of a Form workflow.	Initialize Form values, validate, submit, and handle success or error.

These contexts can cooperate. For example, startup logic can configure a Button event handler and load the first set of records. Later, the Button event handler can run another query and update the display when the result is available.

Page Flow executes in the browser. It can coordinate permitted Project data operations, but protected authorization, secret credentials, and trusted business decisions belong in the appropriate Backend capabilities such as Cloud Flow.

Startup Logic

Startup logic prepares a Page or Form for its initial use.

Common startup tasks include:

• Set initial Page state or default values.
• Read URL parameters when the Page uses them.
• Show or hide Page Elements based on the intended initial presentation.
• Enable or disable controls until they are ready.
• Set initial messages or status content.
• Register the event-driven behavior the Page needs.
• Begin loading data for a Data Table, Data Design, or other supported display.
• Prepare a Widget or other Page component using its supported configuration.

For example, a customer-management Page might initialize a filter, disable a Refresh Button while data is loading, retrieve the initial customer list, and then show either the records or an appropriate status message.

Flow Start Is an Organizational Marker

The Flow Start block identifies a recommended starting location for organizing a Page Flow on the canvas.

It is important to understand what it does not do:

• It does not generate a runtime operation of its own.
• It is not a mandatory root to which every other block must be connected.
• Placing a block under Flow Start does not make it an event handler.

The actual execution of a block depends on the structure and behavior of the generated Page Flow, including whether the block registers an event handler or belongs inside a callback or procedure.

Use Flow Start to make the main initialization structure easier to locate, not as a substitute for choosing the correct execution context.

For its exact behavior, see General Blocks — Flow Start.

Organizing Startup Tasks

A practical startup design separates initial preparation from operations that may finish later.

Page Initialization
  Prepare initial display and state
  Configure supported event handlers
  Start loading initial data
    When data is available
      Update the display
    When loading fails
      Show an appropriate message

This is a conceptual sequence, not the names of specific Page Flow blocks.

When building startup logic:

1. Identify what the visitor should see immediately.
2. Decide which elements or controls need initial values or states.
3. Configure event behavior for interactions the Page should support.
4. Start any required data or Backend operations.
5. Put dependent UI updates in the appropriate result or completion path.
6. Save and Preview the Page to verify the startup sequence.

Do not make the entire Page wait for unrelated data when it can display useful content first. If initial data is not yet available, provide a loading or empty-state experience as appropriate.

Startup and URL Parameters

URL parameters can provide a starting selection or filter for a Page.

For example, a catalog Page opened at a URL containing a product category might use that category to set a visible filter and load matching results.

The intended sequence is:

Page initializes
  Read the relevant URL parameter
  Validate or normalize the value
  Set the starting filter
  Load matching results
  Display the results or an empty state

The URL Parameter Value block is documented in the General Blocks reference.

Treat URL parameters as browser-provided input. Do not use a parameter by itself as proof that a user is authorized to access a record or perform a protected operation.

Events

Events allow Page Flow to respond when a user or a supported Page component performs an action.

Examples include:

Event Source	Example Interaction	Possible Page Flow Response
Button	User selects Refresh.	Load updated data.
Input	User changes a filter value.	Validate the selection and update results.
Menu or Link Control	User selects an application action.	Open a Form or perform a supported interaction.
Form	A Form initializes, validates, or submits.	Run Form-specific lifecycle logic.
Data Table Widget	User selects a standard or custom record action.	Open a Form or use selected-row context.
Data Design Content	User selects an action on a rendered item.	Handle the action for the appropriate item.
Other Supported Widgets	A configured widget exposes an applicable event or action.	Coordinate surrounding Page behavior.

Not all elements or Widgets expose the same events. Use the supported event and action mechanisms for the selected element.

Event Action

The Event Action block registers an event handler for a specified event on a selected Page or Form element.

Its main inputs include:

Input	Purpose
Event	Specifies the event name to listen for.
Element	Identifies the element whose event is being monitored.
Tasks	Contains the blocks that run when the event occurs.

For example, a Refresh Button can have an event handler whose tasks load current records and update the display.

Conceptually:

Register event behavior for Refresh Button
  When the configured event occurs
    Call refreshResults

The handler's nested tasks run when the event occurs, rather than simply because the handler was configured.

To reference a target element, use the supported element identifier or selector. Ensure the element is present in the relevant Page or Form and that its reference matches the saved design.

For exact inputs and behavior, see General Blocks — Event Action.

Event Information

Some handlers need to know what triggered them.

The Action/Event Info block provides the current event information object within a supported Event Action callback. This can be useful when behavior depends on event-specific details rather than only on the selected element.

Use event information only when necessary. For a straightforward Button action, a named procedure may be easier to understand than inspecting a complete event object.

For the supported structure, see General Blocks — Action/Event Info.

Registering Events and Handling Events

It helps to distinguish two separate steps:

1. Registration: The Page Flow sets up the event listener or other supported action behavior.
2. Execution: The handler's tasks run when the matching event occurs.

For example, loading customer records during startup and loading them again after a Refresh Button click are different execution paths. Both may call the same loadCustomerRecords procedure, but only the click handler should respond to the Button event.

Avoid running work immediately during initialization when it is intended to happen only after user interaction.

Conversely, make sure any supported listener or action setup is in place when the user needs it. If an element is created or rendered dynamically, verify how the chosen event mechanism applies to that rendered content rather than assuming every new instance automatically inherits an earlier listener.

Forms and Their Lifecycle Events

A Form has an internal lifecycle in addition to the event-driven behavior of the Page that opens it.

Supported Form lifecycle moments include:

Form Lifecycle Moment	Typical Role
On Init	Initialize fields and read shared context or edit data.
Before Validation	Run checks or prepare values before the normal validation step.
After Validation	Review values or validation results.
On Submit	Coordinate submission or a custom processing workflow.
On Success	Handle completed Form operations.
On Error	Handle failure and recovery feedback.

These are Form Page Flow lifecycle moments, not generic Button event names.

For example, selecting Add Registration on an event Page can open a Form and pass the selected event as shared context. The Form's On Init logic can then use that context to prepare fields. Its submission and result handling belong to its own lifecycle.

Keep three types of information distinct:

• Shared context: Additional workflow information passed by the opening Page, including to New Forms.
• Edit data: Original record information used when editing an existing record.
• Current Form data: The values presently entered into the Form.

For details, see Opening Forms as Modals and Form Page Flow.

Events in Data Tables and Data Design

Widgets and repeated content may need more specialized event handling than a fixed Button on a Page.

Data Table Actions

A Data Table Widget can expose actions such as New, Edit, and custom row actions. Page Flow can coordinate the action with a modal Form, record-specific logic, or a refresh.

For a row action, use the selected record context provided by the supported action mechanism. Do not assume the current row can be identified only by its visible text or position in the table.

For more information, see Data Table Widget and Forms and Widgets.

Rendered Data Design Items

A Data Design defines a reusable item layout that may be rendered multiple times with different values.

For example, each product card may contain a View Details Button. Page Flow must associate the triggered action with the appropriate rendered product, using the supported rendering and interaction mechanism and, where applicable, stable ID and ID2 values.

Do not assume that an action attached to one manually edited element automatically identifies every rendered instance or the correct record. Test interactions with multiple items, not just one.

For more information, see Rendering Data Design.

Keeping Flows Readable with Procedures

As a Page Flow grows, separate the main execution paths from reusable procedures.

Meaningful procedure names describe outcomes or responsibilities, such as:

• initializePage
• loadCustomerRecords
• applySelectedFilter
• openRegistrationForm
• handleRegistrationSaved
• refreshResultsTable

A good pattern is to make event handlers small and let named procedures perform the substantial work.

Startup
  Call initializePage
  Call loadCustomerRecords

Refresh Button Event
  Call loadCustomerRecords

Registration Saved Result
  Call refreshResultsTable

This is a conceptual organization example, not literal Page Flow block syntax.

This makes it easier to understand when each operation runs and to reuse the same behavior from more than one event.

Use visual blocks to communicate the main control flow. Reserve Custom Code and Code Expression blocks for focused JavaScript that is clearer than an equivalent collection of blocks.

For more information, see Custom Code.

Asynchronous Behavior

Some Page Flow operations take time to complete. Examples include:

• Reading or changing permitted Project data.
• Calling Cloud Flow or an external endpoint through a supported interface.
• Loading a Widget's data.
• Waiting for a deferred task or another asynchronous result.

Starting an asynchronous operation is not the same as receiving its result.

Handle Results at the Correct Time

For operations that provide callbacks, result branches, or completion blocks, place dependent behavior in the corresponding completion path.

For example:

User selects Load Orders
  Show loading status
  Start permitted data operation
    On successful completion
      Update the results area
      Remove loading status
    On error
      Show an error message
      Remove loading status

The example illustrates execution order. The actual inputs and completion structure depend on the selected blocks.

Do not update a results area as if a request has succeeded before the data or result is available.

Deferred Tasks

The Page Flow block reference also includes deferred-task operations. These can help coordinate work that resolves later.

Examples include:

Block	Purpose
Create Deferred Task	Creates a deferred task represented by a Promise.
Complete Deferred Task	Completes a deferred task with a result.
Wait on Deferred Task to Complete and Then Do	Runs nested tasks after a deferred task resolves.
Wait for Multiple Deferred Tasks Completion	Supports coordination of more than one deferred task.

Some deferred-task blocks emit JavaScript await expressions or statements and therefore require an appropriate asynchronous context. Do not place them arbitrarily in a synchronous execution path.

For precise inputs, outputs, and usage requirements, see General Blocks.

Operations That Finish Out of Order

Two requests started close together may not finish in the same order they were started.

For example, a visitor might select one search filter and immediately select another. If the earlier request finishes last, it could overwrite more recent results unless the workflow is designed to prevent that outcome.

When this matters:

• Keep track of which request or selection is current.
• Use the completion result associated with the correct operation.
• Avoid applying an outdated result to the current display.
• Ensure loading indicators and enabled states reflect the operation currently in progress.

The method used depends on the supported blocks and any focused custom JavaScript needed for the workflow.

Example: Initial Data and a Refresh Button

Consider a Page containing a Data Table Widget and a Refresh Button.

The Page should load initial records and also let the visitor request updated information.

Prepare the Page

1. Add and configure the Data Table Widget in the Page Editor.
2. Add the Refresh Button.
3. Give important elements clear names and verify their saved references.
4. Open Page Flow from the Page Editor.

Configure the Behavior

Organize the logic conceptually as follows:

Page initialization
  Prepare loading or status display
  Configure Refresh Button event behavior
  Load initial records
    When complete
      Update or refresh the displayed information
      Show ready state
    When failed
      Show an appropriate error

Refresh Button event
  Prevent repeated requests when appropriate
  Load current records
    When complete
      Update or refresh the displayed information
    When failed
      Show an appropriate error
  Restore available controls

This is not a literal list of block names. The actual Data Table configuration and refresh operations depend on whether the Widget uses direct Project table loading or Custom Query.

Test the Complete Interaction

Preview the Page and confirm:

• Initial records load as intended.
• The Refresh Button triggers the intended operation.
• The Page does not imply loading succeeded before completion.
• Errors do not leave the interface permanently disabled or loading.
• Repeated clicks do not create unexpected overlapping operations.
• User permissions and data rules are respected.

For Widget-specific behavior, see Data Table Widget.

Previewing Startup and Events

Preview the Page or Form after saving Page Flow changes. Testing only the visible layout does not verify that startup, events, and asynchronous results behave correctly.

Test	What to Check
Initial load	Startup initializes the correct Page state and content.
Direct URL opening	Any required URL parameters are handled correctly.
Repeated opening	The Page or modal behaves correctly when reopened.
Event handling	Actions run in response to the intended event, not unexpectedly at startup.
Disabled or missing blocks	The intended execution path is enabled and connected correctly.
Asynchronous success	Dependent content updates only after the operation succeeds.
Asynchronous failure	The user receives an appropriate message and can recover.
Rapid repeated actions	Duplicate or stale requests do not produce confusing results.
Form context	Shared context and edit data are handled correctly where applicable.
Permissions	Client-side behavior does not assume access beyond the current user's allowed operations.

If something does not run, verify the event source, element reference, enabled state, block connections, and whether the relevant logic belongs to startup or to an event callback.

For step-by-step diagnosis, see Previewing and Troubleshooting.

Good Practices

• Make startup predictable. Prepare essential Page state and begin only the initial work that is needed.
• Keep event handlers focused. Delegate reusable or complex work to clearly named procedures.
• Use Flow Start for organization. Do not assume it is a required or executable event root.
• Handle asynchronous results explicitly. Update the Page only when the result needed for that update is available.
• Provide user feedback. Show loading, success, empty, and error states when they help explain the workflow.
• Keep form lifecycles separate. The opening Page and the Form can have different responsibilities and Page Flows.
• Use stable references. Check the selected element and record context for event-driven or repeated content.
• Keep protected processing on the Backend. Browser-side events and validation do not enforce sensitive permissions.
• Test repeated interactions. Reopening a Page or modal and rapidly repeating actions can expose problems not visible in a single successful test.

Common Mistakes

Avoid these patterns:

• Treating the Flow Start block as a mandatory runtime event handler.
• Placing user-action logic in startup so it runs before the user acts.
• Expecting an event handler's nested tasks to run when the handler is registered.
• Selecting the wrong element or event when configuring Event Action.
• Assuming every Widget or rendered item exposes the same event mechanism.
• Updating the Page before an asynchronous operation has returned the necessary result.
• Ignoring errors or leaving a control disabled after processing fails.
• Applying an older asynchronous result after the visitor has made a newer selection.
• Treating Form lifecycle events as interchangeable with generic Page events.
• Using browser-side checks as the only protection for restricted data or business rules.

Page Flow is easier to build and maintain when startup prepares the experience, events respond to actions, and asynchronous completion handles results. Keeping those stages clear helps produce predictable Pages and Forms.

Related Topics

• Page Flow
• Editor Basics
• Choosing Blocks
• Forms and Widgets
• Data and Cloud Flow
• Custom Code
• Previewing and Troubleshooting
• Form Page Flow
• Page Flow Blocks
• General Blocks
• Page Actions
• Forms Blocks
• HTTP and Web Hooks