Server Connect Actions: Core Concepts

A beginner-friendly mental model for Server Connect Actions in the editor: inputs → steps → JSON output, data scope, and output schemas.

Core concepts

This tour builds the basic mental model for Server Connect Actions: inputs go in, steps process data, and the output defines the JSON your client receives.

Inputs

Request data Parameters

Steps

Process values Build results

Output

Return a clean JSON shape

Think of an action as inputs, processing steps, and output.

Keep each step small and clearly named.

The output shape is part of your API contract.

Opening the sample action…

Loading the example action into the Server Connect editor.

If this is the first time, it can take a moment while the editor initializes.

The Server Connect editor is ready

The sample action is now open in the dedicated editor, so the next steps can focus on the workflow tree, inputs, and selected-step details.

Inputs & variables (request data)

Inputs usually come from the request:

GET (query string)
POST (form/body)
Path params (URL variables, $_PARAM)
Session / Cookie (logged-in context)

Defining inputs up front makes actions safer and easier to understand: you can validate early and keep the workflow predictable.

Where $_GET shows up in the tree

In the editor tree, global input “scopes” are shown as nodes like $_GET, $_POST, $_PARAM, $_SESSION, and $_COOKIE.

$_GET is the query string part of the URL (everything after ?).

$_PARAM: URL path parameters

$_PARAM is the URL path parameters (route variables), like /users/:id.

Example: GET /api/users/42 → $_PARAM.id = 42.

Use path params for identity (which record), and query string for filters (how to list/search).

Inputs deep dives (recommended next)

If you want to go deeper, these tours cover each input source separately with real example workflows you can click through.

URL inputs: `$_GET` + `$_PARAM`

Body inputs: `$_POST` (forms + JSON)

Session & Cookie: `$_SESSION` / `$_COOKIE`

Core action: Set Value (the workhorse)

The selected step is a Core → Set Value action.

In the Properties panel:

Name is the step identifier you bind to later.
Global Name (key) stores the value as a variable (so other steps can use it).
Value is usually an expression like {{$_GET.user_id}}.
Output decides if it is returned in the JSON response.
Data Type helps Wappler treat the value as text/number/boolean/etc.

Steps run top-to-bottom (data scope)

Steps execute in order. A step can use request inputs (GET/POST/Session/etc) and output from previous steps.

This is why naming steps matters: the name becomes the handle you bind to later.

Tip: when an expression gets too complex, create a separate step that computes a clean value.

Order matters

Top-to-bottom pipeline

Scope matters

Previous steps only

Readable

Small steps named well

Keep validation near the top of the workflow.

Treat each step as a small, testable unit.

Prefer composing steps over huge expressions.

Expressions + Output Type (number/text/boolean)

This Set Value step computes a derived value.

Look at these Properties:

Value: you can compute from earlier variables (here: note → length).
Data Type / output type: set it so the result behaves like a number.

Tip: keep expressions short; if it gets complex, split it into multiple steps.

Boolean flags (great for UI logic)

Boolean outputs are perfect for the client/UI: you can bind them directly to show/hide states.

This Set Value step uses Data Type = boolean and Output = true to expose a simple flag in the JSON response.

Output: what the client receives

A Server Connect Action returns JSON.

Some steps are just intermediate (internal). Others are marked as output, meaning their result is included in the response.

A good beginner goal is a predictable response shape: one main object/array for data, plus optional extras like totals, flags, or messages.

Internal steps

Build up data safely

Output steps

Return results as JSON

Predictable

Easier to bind in the UI

Keep output names stable to avoid breaking pages/apps.

If the UI needs it, output it; otherwise keep it internal.

Temporary output of intermediate data is a good debugging trick.

Schema (meta) makes binding easy

When an output is an object or an array, describing its fields (schema/meta) unlocks a better experience: reliable binding and type hints, better pickers and autocomplete, and easier debugging.

If you’re building data for the UI, treat the output schema as part of the contract.

TIP: A stable, well-described JSON response is what makes App Connect bindings feel “visual” instead of “guessing strings”.

Simple outputs (text/number/boolean) are straightforward.

Complex outputs (object/array) benefit most from schema.

If the UI can’t “see” a field, it’s usually a schema/output issue.

A practical way to debug and grow actions

When something doesn’t work, debug in the same order the server runs:

inputs (is the request data present and valid?)
step configuration (is each step using the right bindings?)
step output (does each step produce what the next step expects?)

As actions grow, use containers (If/Try/Repeat) and keep steps focused.

Output an intermediate value temporarily to inspect it.

Prefer composing multiple small steps over one giant step.

Use try/catch for expected failures (API calls, file IO, etc.).

Wrap-up

You now have a mental model for Server Connect Actions: inputs → steps → output, plus why schema matters.

Pick a next tour based on what you want to do next.

Next steps

Pick a related tour to continue.