Unify Logo Footer.svg
Unify Applications
Logo
Page Parameters & Routing

Page Parameters & Routing

Logo

7 mins READ

What Are Page Parameters?

Page parameters — also called page inputs — are typed values that a page declares as its interface with the outside world. They are how a page accepts data from the URL, from a navigation call, or from a parent frame that embeds the page.

When you navigate to a page with Go to Page, you specify the values to pass as inputs. Those values travel as URL query string parameters and are decoded by the page on load. Blocks bind to them using the pageParams or pageInputs namespace.

Note: Parameters arrive from outside the page — from the URL or from a navigation call. Variables are defined inside the page and are reset every time the page opens. Parameters are read-only within the page; variables can be updated by actions.

Declaring Page Parameters

Open Page Settings and navigate to the Query Parameters (or Inputs) section. Each input has two required fields:

FieldDescription
NameThe identifier used in bindings and in the URL query string. Use camelCase or kebab-case. Must be unique within the page. Cannot be pageInputs (reserved).
TypeThe data type: String, Number, Boolean, Object, or Array.

Tip: Undeclared query string parameters are silently ignored. If a block binding referencing pageParams.orderId returns undefined, the first thing to check is whether orderId is declared as an input in Page Settings.

Automatic Type Conversion

URL query strings are always plain text. UnifyApps automatically converts the string value to the declared type when the page initializes.

Declared typeInput stringConverted value
Number"42"42 (number)
Boolean"true"true (boolean)
Boolean"false"false (boolean)
Object'{"key":"value"}'{ key: "value" } (object)
Array'[1,2,3]'[1, 2, 3] (array)
String"any text""any text" (no conversion)

Warning: If the URL value cannot be converted to the declared type — for example, a non-numeric string passed to a Number parameter — the parameter resolves to undefined. Design your page to handle missing or invalid inputs gracefully.

Reading Parameters in Bindings

Anywhere in the builder that accepts a binding expression, you can reference page parameters using either of the supported namespaces:

{} Binding syntax for page parameters

// Using pageParams namespace {{ pageParams.orderId }} {{ pageParams.tab }} {{ pageParams.userId }} // Using pageInputs namespace (equivalent) {{ pageInputs.orderId }} {{ pageInputs.tab }} // In a conditional expression {{ pageParams.tab === 'activity' ? 'Activity' : 'Details' }} // As a data source filter {{ { orderId: pageParams.orderId } }}

Both pageParams and pageInputs refer to the same object — the set of resolved input values for the current page. Use whichever name you find more readable in context.

The Reserved pageInputs Parameter Name

pageInputs is a special reserved query parameter name. When the whole set of page inputs is serialized as a single JSON value and passed in the URL as ?pageInputs=…, the platform deserializes it and distributes the values to the corresponding declared inputs. This is used internally when a page is embedded or navigated to from a context that cannot construct individual query parameters separately.

Warning: This name is reserved. Declaring a parameter with this name causes a conflict and produces unpredictable behavior. Use a different name for your custom inputs.

Directly Passed Inputs

When a page is embedded (opened inside another page as a frame or modal) rather than navigated to as a full-screen page, the host can pass inputs directly through the embedding configuration rather than through the URL. Directly passed inputs take precedence over URL query parameters of the same name.

Parameter Defaults

You can set a default value for each declared parameter. This default is used in the builder and preview environments so you can see the page with realistic data without constructing a URL each time.

Warning: Parameter defaults are a design-time convenience. In the published application, if no value is present in the URL or from a navigation call, the parameter resolves to undefined — not the default. Design your page to handle missing parameters rather than relying on defaults as a fallback at runtime.

Page Outputs and Events

Pages are not only inputs — they can also communicate back to their openers through outputs and events.

Page Outputs

A page can publish named output values to the page or component that opened it (for example, a modal page returning a selected value to the page that launched the modal). Declare outputs in Page Settings alongside inputs, then use the Set Page Output action to write values to them at runtime.

Outbound Page Events

A page can declare and emit named events to notify the host context that something happened. Use the Emit Page Event action to fire an event with an optional payload. The host context listens using an event handler configured to react to that named event.

Inbound Page Events

A page can declare which named events it can receive from a host. These are configured as interactions on the page. When the host fires the named event, the page's configured action chain runs. Inbound and outbound events are separate declarations.

Note: Page events (outbound and inbound) are custom named signals exchanged between a page and its host. Page triggers (On Page Load, On Page Focus, Keyboard Shortcuts) are lifecycle hooks built into the platform. They are configured in the same Page Settings panel but serve different purposes.

Slugs and URLs

Each page has a slug — a short, URL-safe string that becomes the page's path segment. The full URL of a page is determined by its slug and the slugs of any folders it sits inside.

SettingDescriptionNotes
Page SlugThe URL segment for this page. Shown as "Page URL:" in the page creation dialog.Lowercase letters, digits, and hyphens only. Changing this after the app is live breaks existing external links.
PrivacyPrivate or Public access.Private requires sign-in. Public is accessible to anyone with the URL.
Document TitleShown in the browser tab.Defaults to the page name. Can be a fixed string or a dynamic binding (e.g., {{ pageParams.orderId + ' — Orders' }}).

Dynamic Document Title

A dynamic document title keeps the browser tab informative when a page displays record-specific content. For example, an order detail page can set its title to Order {{ pageParams.orderId }} so that users with multiple tabs can tell them apart at a glance.

🗎 Dynamic document title examples

// Order detail page Order {{ pageParams.orderId }} // User profile page (showing fetched name) {{ userQuery.data.name }} — Profile // Dashboard with filter {{ pageParams.team }} Dashboard

Default Pages

Your application has two configurable default page settings in App Settings:

SettingWhen it appliesOptions
Default page for signed-in usersA signed-in visitor opens the app's root URL without a specific page path.Fixed page, or a conditional expression that evaluates to a page name based on user attributes (role, organization, etc.).
Default page for signed-out visitorsAn unauthenticated visitor opens the app's root URL.Optional. If not set, unauthenticated visitors see the login prompt. If set to a Public page, they land there directly.

Tip: Use a conditional default page expression to send different users to different pages on first load — for example, send administrators to an admin dashboard and regular users to a personal overview page. The expression evaluates after the user's session is established, so user attributes like role and organization are available.

Privacy and Permissions

Every page has a Privacy setting and an optional Permissions configuration:

LayerSettingEffect
PrivacyPrivateOnly users who are signed in to the app can access this page. Unauthenticated visitors are redirected to the login screen.
PrivacyPublicAnyone with the page URL can access it. No sign-in required.
PermissionsRole-based rulesApplied on top of the Privacy setting. A signed-in user who does not have the required role sees a 403 / access denied response. Public pages can also have role permissions — they only apply to signed-in users.

Updating URL Parameters at Runtime

The Set URL Parameters action lets you update the current page's query string without triggering a full navigation or page reload. This is useful for:

  • Reflecting the current filter or sort state of a table in the URL so visitors can share or bookmark a specific view.

  • Tracking the selected tab on a tabbed page so the correct tab is restored on page refresh or when a link is shared.

  • Persisting pagination state in the URL.

Note: The action updates only the query parameters that have a corresponding declared input. Attempting to set an undeclared parameter name has no effect on the page state, though the URL may still reflect the change visually.