Server Connect Actions

Start here for Server Connect Actions (Workflows > Server Connect Actions): manager overview, a guided path, a first action, editor deep dives, and recipes & patterns.

Back to Reference Tours

Start here for Server Connect Actions (Workflows > Server Connect Actions): manager overview, a guided path, a first action, editor deep dives, and recipes & patterns.

App Flow (isolated)

App Flow (isolated): what it is

App Flow is a reusable client-side workflow that runs isolated from the page. It processes actions and data, and returns results back to the caller.

TIP: Think of an App Flow as a client-side function: call it, wait for results, then update the UI.

Isolated

No direct page access Inputs/outputs

Reusable

Call from many pages Same behavior

Returns data

Expose results To your UI

Use App Flow when you want a reusable workflow with inputs and outputs.

Keep it pure: treat it like a function (parameters in, results out).

If you need database or protected logic, call a Server Connect Action from the App Flow.

Calling an App Flow from a page

You connect a page to an App Flow using a Flow component, then run it from events.

The flow runs isolated, but it can receive parameters and return results.

Use a Flow component with `src` to point to your App Flow JSON.

Pass inputs with `dmx-param:*` (or via `run({...})`).

Use `flowId.run(...)` from an event to execute the flow.

Results and status

When you run an App Flow, use its status and data in your UI.

Use `flowId.running` to show loading/progress.

Read results from `flowId.data` after the run completes.

Handle failures via `flowId.lastError` (and branch your UI accordingly).

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Inline Flow (event actions)

Inline Flow is a sequence of actions inside an element’s event handler; it executes actions but does not return data.

Inline Flow (event actions): what it is

Inline Flow is a sequence of actions you add directly inside an element’s event handler (for example: click, submit, change). It executes actions in order, but it does not return data as a reusable result object.

WARNING: Inline Flows don’t return data. If you need results (data out), use an App Flow or Page Flow.

Fast

Great for small glue Few actions

In-page

Lives on an element Event-driven

No outputs

Executes actions No return data

Use Inline Flow for simple UI glue: toggle, show/hide, small sequences of actions.

Keep it short; if it grows, move it into a Page Flow or App Flow.

Remember: App Connect event expressions are not JavaScript — use App Connect actions/expressions only.

When to use Inline Flow

Inline Flow is best when the logic is tied to one element/event and stays short and readable.

Tied to one UI event (click/submit/change).

Short sequence of actions (UI glue, trigger an action, show a toast).

No returned data object (side effects only).

When to upgrade to a Flow component

Upgrade when the sequence becomes complex, you need reuse, or you want a clean inputs/outputs contract.

Upgrade for reuse: the same workflow is needed in multiple places.

Upgrade for clarity: the inline sequence becomes hard to understand/maintain.

Choose Page Flow for page-specific orchestration; choose App Flow for isolated reusable workflows that return results.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Page Flow (in-page)

Page Flow executes inside a page, can interact with that page’s components/actions, and can return data.

Page Flow (in-page): what it is

Page Flow is a client-side workflow that executes inside a specific page. It can interact with that page’s components/actions and can return data.

TIP: Use a Page Flow when the workflow belongs to one page and needs to interact with that page’s components/actions.

In-page

Runs in a page Page context

Interactive

Can call page actions Component access

Returns data

Expose results To the page

Use Page Flow when the workflow is page-specific and needs page context.

Great for multi-step UI interactions with branching (confirm, toast, navigate, refresh).

If it grows, keep it readable: name steps and handle errors explicitly.

Define a Page Flow (inline HJSON)

A Page Flow lives inside the page as a dmx-flow script block. It can branch and execute steps sequentially.

Define the flow inline as a `dmx-flow` script block in the page.

Keep it page-specific: it can interact with page variables/components/actions.

Use it to orchestrate multi-step UI flows (confirmations, branching, sequencing).

Run it and use results

Run the flow from an App Connect event, then read flowId.data, flowId.running, and flowId.lastError in your UI.

Use `flowId.run({ ... })` to pass parameters into the flow.

Read `flowId.running` to show progress while it runs.

Use `flowId.data` / `flowId.lastError` to update the UI based on outcomes.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Dedicated editor (App Flow)

Tour the App Flows editor: understand the canvas, nodes, connections, and how to run and debug flows.

Introduction

This tour assumes you already have an App Flow open in the dedicated editor.

This editor is for App Flows (the isolated flow type). For Page Flows and Inline Flows, you create and run them inside pages (App Connect).

NOTE: This editor is for App Flows (isolated). Page Flows and Inline Flows are created inside pages (App Connect).

Focused

Bigger workspace Less UI

Same concepts

Trigger + steps Branching

Great for

Large flows Complex UI

Use the manager panel to browse; use the editor to focus.

Everything still runs client-side.

Call APIs (or server endpoints) when you need data.

Editor Workspace

This is the dedicated App Flows editor. Build and edit your flow steps here.

Use the toolbar to search and access common actions and settings. This step matters because Toolbar is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Search

Use search to quickly find flows and steps in large projects. This step matters because Search is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Next Steps

Next: return to the App Connect Flows hub, or continue with another App Flow tour.

Go back to the App Flows hub for recipes and reference.

Use the Workflows Index to browse other Workflows areas.

Use the App Flows guided path if you want a linear sequence.

Recipes & patterns (App Connect Flows)

Common App Connect Flows patterns: Inline Flow for quick UI glue, Page Flow for in-page orchestration, App Flow for reusable workflows with outputs.

App Connect Flows: recipes & patterns

This how-to collection is meant to lower the entry cost for App Flows by starting from repeatable tasks instead of abstract theory. Use it to find the exact workflow you need, understand where that action lives in the editor, and then branch into the focused tour that matches your next step.

Inline Flow

Small glue No outputs

Page Flow

In-page orchestration Page context

App Flow

Reusable workflow Returns results

Inline Flow: quick sequences inside event handlers; keep it short.

Page Flow: multi-step UI orchestration inside a page; great for branching UI flows.

App Flow: reusable, isolated workflows with inputs/outputs; call from pages and use results.

Pattern: React to UI events

Start from a user action (click, submit, change) and run follow-up steps.

Use Inline Flow for a short sequence. Use Page Flow when it becomes multi-step with branching. Use App Flow when you want reuse + results.

Keep triggers predictable and named clearly.

For secure work, call a server endpoint and handle results in the flow.

Pattern: Branch logic cleanly

Use conditions to branch and run different steps based on values, responses, or UI state.

Treat errors as a branch (happy path vs error path), and keep results/status explicit so your UI can react.

Treat errors as a branch (happy path vs. error path).

Log or surface info early while building.

Pattern: Integrate data safely

Combine flows with data sources/actions (like API calls) to load, transform, and use data.

Rule of thumb: if it must be secure or touch the database, call a Server Connect Action, then use the response in your Page Flow / App Flow.

Prefer JSON-in / JSON-out building blocks.

Keep data shaping on the server when possible.

Pattern: Organize and reuse

Keep large projects manageable.

Inline Flow stays small and local. Page Flow keeps per-page orchestration readable. App Flow splits complex tasks into reusable flows and returns results.

Split complex flows into reusable sub-flows.

Prefer short, composable flows over one giant one.

Next steps

Pick what you want to learn next.

App Connect Flows

Start here for App Connect Flows: learn the three flow types (App Flow, Page Flow, Inline Flow) and jump into the dedicated App Flow editor tours.

Workflows: App Connect Flows

App Connect Flows are client-side workflows. They come in three forms — App Flow, Page Flow, and Inline Flow.

App Flow: isolated and returns results
Page Flow: runs inside a page and can use page context/actions
Inline Flow: actions in an event handler (no return data)

Start the guided path, or pick a topic.

TIP: Use Inline Flows for small UI glue. Use Page Flows for page-specific orchestration. Use App Flows when you want a reusable workflow that returns data.

App Flow

Isolated workflow Returns results

Page Flow

Runs in a page Can use page actions

Inline Flow

Actions in an event No return data

Manager overview (App Flow)

Manager (App Flow) overview: key areas and how they work together.

App Flows manager overview (App Flow type)

This UI is the App Flow builder in Workflows > App Flows. App Flows are isolated client-side workflows that return results.

For Page Flows and Inline Flows, you create them inside pages (App Connect).

NOTE: Flow types recap: App Flow = isolated + returns results. Page Flow = runs in a page + can use page actions. Inline Flow = actions in an event handler + no return data.

App Flows

This panel lists all your app flows. You can organize them into folders. This step matters because App Flows is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Search Flows

Use the search bar to quickly find any app flow. This step matters because Search Flows is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Global Settings

Configure shared settings for your flows, integrations, and project-level options. This step matters because Global Settings is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Flow steps (main panel)

When you select a flow, its steps appear in the main panel.

Next: take a closer look at managing the flows list (search, refresh, open in editor).

App Flow Editor Reference

Reference tour for the App Flow editor: editor layout, toolbar controls, flow structure, and how to navigate and organize flows.

Introduction

A quick reference of the most important areas in the App Flows UI (App Flow type).

App Connect Flows also include Page Flows and Inline Flows (created inside pages).

NOTE: If you’re looking for Page Flow or Inline Flow concepts, jump to the flow type tours from the hub.

Browse

Flows list Folders

Build

Steps Connections

Find

Search Navigation

Use this tour as a map when you feel lost.

For a first run, use the Workflows guided path.

For outcomes, use Recipes & patterns.

Flows List

All app flows live here. Use folders to keep things organized.

The toolbar contains common commands like Search and project-level settings. This step matters because Toolbar is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Steps Workspace

This is where you build the step-by-step workflow for the selected flow. This step matters because Steps Workspace is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Search

Use search to quickly locate flows in large projects. This step matters because Search is part of Manager Appflows, and understanding that context makes the next action easier to repeat in your own project.

Next steps

Pick what you want to learn next.

App Flow: First flow

Explore App Flow: First flow: First App Flow (mental model), App Flow, and steps (and outputs).

First App Flow (mental model)

App Flows are isolated client-side workflows. They run with inputs, execute steps (including branching), and can return results for your page to use.

TIP: If you need to orchestrate actions on a single page (and access that page’s components), consider a Page Flow instead.

Inputs

Parameters in From page

Steps

Actions Branching

Outputs

Results out Back to page

Use App Flows when you want a reusable workflow that returns results.

An App Flow is isolated: it doesn’t directly access page components; pass inputs and use outputs instead.

For protected data or database access, call a Server Connect Action from your App Flow.

Create an App Flow

Use Workflows > App Flows to create a new App Flow file. Organize flows into folders as your project grows.

Add steps (and outputs)

Add steps to implement your workflow. Steps typically run top-to-bottom and can branch based on conditions.

Prefer explicit outputs so the page that calls the flow can use the results.

Global Settings

Global Settings is where you configure shared items for your project that are used by flows and integrations.

Next steps

Test the flow in your app context. Debug client-first: check trigger → step inputs → step outputs → branch conditions.

Action structure

Understand a Server Connect Action file: inputs/variables, steps, output, and how data flows through an action.

Introduction

Use this tour to build a dependable mental model of how a Server Connect action file is organized before you try to debug or extend one. You will follow the flow from inputs to nested steps to output, so larger actions feel like readable pipelines instead of a wall of nodes.

Inputs

Parameters and request data

Steps

Work happens step-by-step

Output

Shape the JSON response

Think in three layers: inputs → steps → output.

Containers (If / Try / Repeat / Switch) create hierarchy.

Small, named steps make debugging much easier.

The Server Connect editor is ready

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

The Steps tree

The center/left tree is the source of truth for your action.

Each node is a step. Some steps are containers (they contain child steps).

Containers create hierarchy

Some steps are containers (they own a nested list of steps).

Examples: If / Switch / Try-Catch / Repeat / For Each.

Use containers to keep logic readable instead of making one long flat list.

Properties belong to the selected step

When you select a step in the tree, the Properties panel shows the inputs/options for that step.

Use the tree as the control surface: the current selection is what drives the details on the right.

Outputs shape the response

An action returns JSON. Your Output step(s) determine what the client receives.

A useful mental model is: intermediate steps fetch/transform data, then the output decides what to return.

Tip: keep output predictable; it makes front-end binding easier.

Intermediate steps

Build data incrementally

Output

Return a clean JSON shape

Predictable shape

Easier to bind on the client

You can return a single object, arrays, or a structured response with multiple keys.

When debugging, temporarily output intermediate results to inspect them.

Keep naming consistent (e.g., data, total, errors).

Output contract (and terminal steps)

Think of Output as the API contract: a stable JSON shape that your client-side code binds to.

For object/array outputs, describing fields (schema/meta) helps autocomplete, pickers, and keeps bindings consistent over time.

Some steps are “terminal” (they end the flow) such as Response, Error, Redirect, or End. Use them to return early from validation/permission checks or to stop after a final response.

NOTE: Most of the time, the best workflow is: validate → build data → return clean output. Terminal steps are for special cases.

Prefer one main output shape per endpoint.

Use terminal steps when you need a clear early-exit path.

If bindings are missing in the UI, check output + schema first.

Conclusion

Recap the structure and continue with a related deep dive.

Next steps

Pick a related tour to continue.

Adding steps

All the ways to add and organize steps in the Server Connect Actions editor (Actions panel, drag & drop, inline + controls, context menu).

Introduction

Adding steps becomes much easier once you understand how each new node changes the action flow instead of just the tree shape. This tour frames step insertion as a workflow decision, so you can see where logic belongs, how order affects results, and why named steps make later debugging easier.

Actions panel

Browse step types Insert quickly

Inline +

Insert before/after or inside containers

Drag & drop

Reorder steps Copy/move fast

You’ll learn 4 insertion methods: Actions panel, inline +, drag & drop, and context menu.

Most workflows start by selecting a step, then inserting relative to it.

Keep steps small and named well; it pays off in debugging.

Insert from the Actions panel

The tour opens the Actions panel so you can browse available step types (Database, HTTP, Files, Logic, …).

Typical workflow:

Select a step in the tree
Click a step type in the Actions panel to insert it relative to your selection

Tip: if you don’t see the Actions panel, use the left panel toggle in the editor header.

Inline + controls

The editor shows inline “+” insertion controls around steps (before/after) and inside container steps.

Use these when you want to insert something quickly without opening any panel.

Drag & drop

You can drag steps to reorder them, and in many cases you can also drag a step type from the Actions panel into the tree.

Tip: use drag & drop to quickly clean up the flow after experimenting.

In the Steps tree, right-click a step to access common actions:

Insert step before/after/inside
Duplicate / delete
Convert or wrap (depending on step type)

This is often the fastest way when your hand is already on the tree.

Where the new step goes

Most insertion methods work relative to the currently selected step.

You can insert before or after a step, or insert inside a container step (like an If / Try / Repeat / Switch).

Tip: when in doubt, click the step you want to insert next to, then add the new step.

Before / After

Insert next to a step

Inside containers

Add nested steps

Selection matters

Click a step first

Adding steps is easiest when you have a clear insertion point.

Containers create hierarchy; keep it readable.

If your new step ends up in the wrong place, just drag it to reorder.

Conclusion

Recap what you learned and choose where to go next.

Next steps

Pick a related tour to continue.

Server Connect Editor: Building actions (hub)

Start here for building Server Connect Actions in the editor: adding steps, action structure, properties, and reuse.

Building actions in the editor

Choose a building-actions topic: adding steps, thinking in action structure, configuring properties, and reusing logic.

Server Connect Actions: Control Flow & Reuse

Learn the power tools in the editor: conditionals, switch/select, try/catch, loops, parallel, and reusable library actions.

Control flow + reuse

This tour shows the control-flow tools that make larger server actions readable and reusable: If, Select/Switch, Try/Catch, loops, parallel patterns, and library actions.

If / Select / Switch

Branch based on conditions

Try / Catch

Handle errors explicitly

Loops + reuse

Repeat work Reuse actions

Use containers to model branching instead of inline complexity.

Keep each branch focused and name steps clearly.

When a pattern repeats across endpoints, turn it into a library action.

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.

Orient yourself in Server Connect editor

Start with the wider context in the Server Connect editor so the next control makes sense in the full workflow. In the next step, you will focus on Containers create nested flows and see how it fits into this area.

Containers create nested flows

In the Steps tree, some actions are containers: they own nested steps.

Typical containers: If/Then/Else, Switch/Select, Try/Catch, Repeat/While, Group/Parallel.

This tour opens a sample action so you can see these patterns in a real workflow.

Conditionals: If / Then / Else

If / Then / Else is your go-to for branching logic.

Common uses include validating inputs, handling missing records, enforcing permissions, and returning a friendly error shape early.

Tip: keep the condition readable—compute complex expressions in a separate step first.

Guard early

Fail fast safe defaults

Two paths

Then vs Else clear intent

Readable

Small branches named steps

Prefer one condition per If; chain multiple Ifs when needed.

Put the simplest checks near the top of the action.

Return predictable error shapes for the UI.

If Properties: the condition + branches

With the If container selected, focus on the Properties panel:

If: the expression that decides the branch.
Then and Else: the nested steps that run in each path.

Rule of thumb: compute complex expressions in a Set Value step first, then keep If readable.

Then/Else steps are normal steps

Inside Then/Else you add normal steps (often Set Value, Return, or Error).

Select the step and look at its Properties:

Global Name (key) defines the variable name
Value defines the computed value
Output controls if it appears in the response

Multi-branch: Switch / Select

When there are more than two choices, Switch/Select is often clearer than stacking many If blocks.

Use it when you need to handle a set of known cases, and add a default branch when your flow needs a safe fallback.

Keep each case focused on one outcome.

Avoid duplicated steps across cases (extract repeated bits).

When unexpected values are possible, add a default branch deliberately.

Multi-branch container: expression + cases

The Select container’s Properties describe:

Expression: what you’re switching on (mode/type/status/etc)
Cases: each case has a match value and nested steps
Optional Default / fallback case when your flow needs one

This sample focuses on explicit named cases, but Select can also include a default path when unexpected values are possible.

Case branches stay readable in the tree

In the Steps tree, each Select case can stay small and still converge on one predictable output contract.

That is the real goal: branch for clarity, then keep the response shape consistent across the cases you expose.

Try/Catch: handle expected failures

Use Try / Catch when a step can fail and you want a controlled result.

Common patterns: return a structured error response, map a low-level error into a user-friendly message, or add fallback logic.

Tip: only catch what you can handle—don’t hide unexpected errors.

IMPORTANT: Use try/catch for expected failures. For logic errors (wrong bindings, missing fields), fix the flow and schema instead.

Keep Catch simple: map the error to a predictable response.

Avoid hiding errors silently; make failures visible during development.

Prefer validating inputs before the risky step.

Try/Catch Properties: map failures to responses

Try/Catch is a container with two nested parts:

Try: steps that might throw/fail
Catch: steps that handle the error

In Catch you usually build a predictable JSON response (status + message + details) instead of letting the request crash.

Core action: Error (and Catch variables)

The Error action is how you intentionally fail with a message.

Select the Error step and inspect:

Message: what gets returned/thrown

Then look at Catch steps: they can use the caught error (often via $_ERROR) to build a friendly response.

Loops: Repeat vs While

Loops are great for transforming arrays or running repeated operations.

Repeat iterates over a list (think: for-each). While repeats until a condition becomes false (use carefully to avoid infinite loops).

Tip: prefer Repeat when you already have an array.

Prefer Repeat for data lists you already have (queries, API results).

Make the repeated step(s) small; avoid deeply nested logic if possible.

If you need loop output, make the output schema explicit.

Repeat Properties: iterate + shape output

With Repeat selected, check Properties:

Repeat: the list/array you iterate over
Output fields: what each iteration produces
Exec: the steps that run for each item

If you want loop results in the response, make the output schema explicit here.

Parallel & Group: organize work

Group keeps related steps together (and can help readability).

Parallel runs branches at the same time (when supported), which can speed up independent work like multiple API requests.

Tip: parallelizing only helps when tasks don’t depend on each other.

Use Group to keep long actions readable.

Use Parallel when there are no data dependencies between steps.

Make sure the outputs you need are clearly named.

Reuse: Library actions (Include vs Exec)

Library actions let you reuse logic across multiple actions.

Include inlines steps into the current flow. Execute (Exec) runs another action as a callable unit with its own output.

TIP: Library actions are the “functions” of Server Connect: reuse them to keep endpoints small and consistent.

Prefer reuse over copy/paste for business rules and validation.

Keep library actions focused on one responsibility.

Document inputs and output shape (schema) so they’re safe to reuse.

Wrap-up

You’ve seen the main patterns behind complex actions: containers, branching, loops, and reuse.

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

Next steps

Pick a related tour to continue.

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.

Server Connect Editor: Inputs (hub)

Start here for inputs in the Server Connect Editor: URL ($_GET/$_PARAM), POST body ($_POST), and session/cookies.

Inputs in a Server Connect Action

Choose an inputs topic. Inputs are the data your action receives (URL, body, session/cookies) and are available to bind in step properties as $_GET, $_PARAM, $_POST, $_SESSION, and $_COOKIE.

Server Connect Actions Editor

Tour the Server Connect Actions Editor: build action flows, configure step properties, and test outputs quickly.

Introduction

This tour opens a sample Server Connect Action in the dedicated editor so you can explore the editor workspace, view modes, and panels in context.

Focused

Bigger workspace Less UI

Same concepts

Inputs + steps Output

Great for

Large actions Complex logic

Use the manager panel to browse; use the editor to focus.

Everything still runs server-side and returns JSON.

You can always jump back to the Server Connect Actions hub.

Editor workspace

This is the dedicated Server Connect Actions editor. This workspace is optimized for editing a single action: steps on the left/center, properties on the side, and quick toggles in the header toolbars.

View mode and panels

In the steps header area you can:

Switch between Tree and Flow view
Show/hide the Actions panel (when available)
Show/hide the Properties panel

These controls help you focus when actions get large.

Properties panel

Select a step in the tree, then use the Properties panel to configure its inputs and options.

Tip: if you don’t see Properties, use the header toggle to show it.

Properties panel (compact layout)

On smaller windows or compact layouts, Properties may appear in a different panel.

If you don’t see it on the right, look for it in the secondary panel area.

Actions panel (inserting steps)

When the Actions panel is available, it’s your catalog of step types.

Typical workflow:

Open the Actions panel
Find a step (Database, HTTP, Files, Auth, …)
Insert it into your action flow/tree

Inserting steps

There are a few common ways to add steps: via the Actions panel (when available), via the tree context menu (right‑click), or by duplicating an existing step and tweaking it.

Next, continue with the Server Connect Actions hub for a guided path and practical recipes.

Prefer smaller steps that do one job well.

Use output steps deliberately (they shape your JSON response).

Use folders/naming consistently for long-term maintenance.

Next Steps

Next: continue with the deep dives for adding steps, understanding action structure, and working with properties.

Go back to the Server Connect Actions hub for recipes and reference.

Use the Workflows Index to browse other Workflows areas.

Use the Server Connect Actions guided path if you want a linear sequence.

Properties & inputs

How to configure steps using the Properties panel, including expressions, pickers, and common patterns.

Introduction

This tour shows how to configure steps via the Properties panel: editing inputs, using expressions, and applying common patterns.

Select a step

Properties follow your selection

Edit inputs

Literals or expressions

Use pickers

Lists, dialogs, helpers

Select a step in the tree to load its properties.

Most inputs accept either a literal value or an expression.

Use the Properties panel to keep step behavior explicit and documented.

The Server Connect editor is ready

This tour uses a real workflow step so the Properties panel can show actual inputs and bindings right away. In this sample, update_client is selected for you.

Properties panel

This panel shows the configurable inputs/options for the selected step.

If you don’t see it, enable it via the editor header toggle.

The selected step drives the Properties panel

This tour keeps a real step selected for you. Here the update_client step is active, so the Properties panel shows its actual update settings and bindings.

That is the key rule: Properties always follow the current tree selection.

Literals vs expressions

Most inputs accept either a literal (plain text/number) or an expression (bind to previous step output, request data, environment, …).

Tip: treat expressions like code: keep them readable and name intermediate results in separate steps.

Literals

Simple fixed values

Expressions

Dynamic values from data

Keep it readable

Name steps and outputs

Prefer making a separate step to compute a value instead of a huge inline expression.

Use consistent naming so it’s obvious where values come from.

When debugging, output intermediate data temporarily.

Expressions are bindings (not JavaScript)

Server Connect expressions are bindings: they read data and produce a value.

They are not general JavaScript (no statements, assignments, callbacks, or creating new functions). When you need logic, use dedicated steps or a library action, then bind to that step’s output.

IMPORTANT: If an expression feels like “real code”, it usually belongs in a separate step (or a reusable library action).

Good: `{{steps.query.data[0].id}}`

Good: `{{steps.validate.is_valid ? steps.data : null}}`

Prefer a step for logic, then bind to its output

Conclusion

Recap what you learned and choose where to go next.

Next steps

Pick a related tour to continue.

Server Connect Editor

Overview and deep dives for the dedicated Server Connect Actions editor: panels, adding steps, action structure, and properties.

Server Connect Editor

Choose a topic to explore. This tour assumes you already have a Server Connect Action file open in the dedicated editor (open one from Workflows > Server Connect Actions).

Server Connect Actions: Guided path

A short, linear learning path for Server Connect Actions (Workflows > Server Connect Actions).

Server Connect Actions: what you’re building

Server Connect Actions are server-side workflows: inputs → steps → JSON output. Use them for secure work like data access, authentication, and reusable endpoints.

Runs on server

Secure by default

JSON output

Reusable building blocks

Edit modes

Manage list + dedicated editor

Use Workflows > Server Connect Actions to browse and organize your actions.

Open a Server Connect Action to edit it in the dedicated full editor tab.

This guided path starts with a simple endpoint and grows from there.

Action auto-selection

On Next, the tour tries to select the first available Server Connect Action automatically. You can still preselect a different action yourself. If this project has no actions yet, the tour stays here and points you to First Server Connect Action.

When a valid Server Connect Action already exists, the tour selects it automatically.

A different action can still be preselected manually before continuing.

If no actions exist yet, First Server Connect Action is the right next tour.

Selected action opens in editor

With a Server Connect Action selected, click Next to open it in the dedicated editor. If the selection is lost, the tour stays on this step and asks you to select or auto-select an action again.

Use the selection from the previous step, or choose a different action in the tree.

Click Next to open that action in the dedicated editor tab.

Next steps

Ready to build your first Server Connect Action?

Demo walkthrough: Client forms (Create/Edit/Delete)

Learn how Server Connect Actions power forms: POST validation, dbupdater INSERT/UPDATE/DELETE, and client-side error/success states.

Open the demo page

This walkthrough starts from a real demo page so the frontend form and backend action can be understood as one connected workflow. Opening the Add Client page first gives you the practical context for every later step, from form submission to validation to database changes in the action file.

The Add Client page opens

We start with the new-client form. It POSTs to a Server Connect action that validates input and inserts a row in the database.

The add form is ready for inspection

With the Add Client page open, the next steps can focus on the form element and the backend action it posts to.

Frontend: a Server Connect Form (POST)

A Server Connect Form is an HTML form wired to a Server Connect endpoint. App Connect tracks state (executing/data/lastError) so you can show success/error UI.

The Add Client page opens in the HTML editor

This step opens the Add Client page in the HTML editor so the form can be selected cleanly afterward.

The add-form canvas is ready

The design surface is ready, so the form can be selected without mixing file-open and selection actions in the same step.

The form element

This form uses is=“dmx-serverconnect-form” and action=“/api/clients/insert”. When submitted, it posts form fields to the backend action.

Success + error states

Notice the UI binds to client_form.data and client_form.lastError. That’s the same pattern you’ll reuse across all forms: show success when data exists, show errors when lastError is set.

Backend: validate inputs and INSERT

Now we open the /api/clients/insert action. This is where you validate input and write to the database safely.

The /api/clients/insert action opens

We open the action and select the insert step so you can inspect the real validation and INSERT flow.

$_POST inputs (validation)

At the top of the action are $_POST inputs. These define expected fields and validation rules (required, min/max length, email, etc.). The goal is to reject bad data before it reaches the database.

The INSERT step is selected

This step selects the insert_client workflow step so the “Insert Options” button is available in the Properties panel.

Locate the "Insert Options" button

In the Properties panel, locate the “Insert Options” button for the selected INSERT step. This step matters because Locate the “Insert Options” button is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

The Updater dialog (INSERT) opens

The Database Updater dialog opens for this INSERT step. This step matters because The Updater dialog (INSERT) opens is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

Preview + parameters (advanced)

Preview shows the generated SQL and parameters. This helps you verify you’re using parameterized queries (safe) instead of string concatenation (unsafe).

Close the Updater dialog

Close the Database Updater dialog to return to the Server Connect editor. This step matters because Close the Updater dialog is part of the Database Updater dialog, and understanding that context makes the next action easier to repeat in your own project.

Frontend: edit + delete flows

The Edit page shows three typical backend patterns: GET a record by id, POST updates, and POST deletes.

The Edit Client page opens

This page loads one client (GET) and provides update + delete forms (POST).

The edit-page Structure panel is ready

The Structure panel is ready, so the data-loading component can be selected without mixing file-open and selection actions in one step.

Server Connect GET component

This dmx-serverconnect loads a single client via /api/clients/get and passes a parameter (id) from the route/query.

Update form (POST)

This form posts to /api/clients/update. It includes a hidden id plus editable fields, and binds values from the GET response.

Delete form (POST)

This second form posts to /api/clients/delete. Keeping delete separate makes intent clear and simplifies server-side validation.

Backend: GET a record by id

The GET action uses a SELECT with a WHERE rule using the incoming id. This is the pattern behind details/edit pages.

The /api/clients/get action opens

We open the GET action and select the client step. The WHERE clause uses {{$_GET.id}}.

WHERE rule uses $_GET.id

The important idea: the id is an input, validated as a number, then used in the WHERE rule as a parameterized expression.

The SELECT step is selected

This step selects the client workflow step so the “Query Builder” button is available in the Properties panel.

Locate the "Query Builder" button

In the Properties panel, locate the “Query Builder” button for the selected SELECT step. This step matters because Locate the “Query Builder” button is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

The Query Builder dialog opens

The Query Builder dialog opens so you can inspect the SELECT, including the WHERE rule and any sub-queries for related data.

Close Query Builder

Close Query Builder to return to the Server Connect editor.

Backend: UPDATE and DELETE (dbupdater)

Update and delete actions follow the same safety rule: always validate inputs and always verify the WHERE clause.

The /api/clients/update action opens

UPDATE typically sets values and uses WHERE id = {{$_POST.id}} to target one row.

The UPDATE step is selected

This step selects the update_client workflow step so the “Update Options” button is available in the Properties panel.

Locate the "Update Options" button

In the Properties panel, locate the “Update Options” button for the selected UPDATE step. This step matters because Locate the “Update Options” button is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

The Updater dialog (UPDATE) opens

The Database Updater dialog opens so you can inspect the SET values and WHERE rules for the UPDATE step.

Close the Updater dialog

Close the Database Updater dialog before continuing to the DELETE action. This step matters because Close the Updater dialog is part of the Database Updater dialog, and understanding that context makes the next action easier to repeat in your own project.

The /api/clients/delete action opens

DELETE is the most destructive action. The WHERE rule is non-negotiable — it must precisely target the intended row(s).

The DELETE step is selected

This step selects the delete_client workflow step so the “Delete Options” button is available in the Properties panel.

Locate the "Delete Options" button

In the Properties panel, locate the “Delete Options” button for the selected DELETE step. This step matters because Locate the “Delete Options” button is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

The Updater dialog (DELETE) opens

The Database Updater dialog opens so you can verify the WHERE rules before any delete runs.

Close the Updater dialog

Close the Database Updater dialog when you are done reviewing the DELETE configuration. This step matters because Close the Updater dialog is part of the Database Updater dialog, and understanding that context makes the next action easier to repeat in your own project.

Wrap-up

You saw how pages use GET for loading and POST for create/update/delete — and how Server Connect Actions validate and perform safe database operations.

Continue learning

Pick a related tour to go deeper.

Demo walkthrough: Clients list (API → Page)

Trace the Clients list page end-to-end: a Server Connect SELECT action feeds a dmx-serverconnect component and a repeater.

Open the demo page

This walkthrough begins on a real Clients list page so the relationship between the page, the data loader, and the backend action is visible from the start. Opening the page first gives you the context needed to trace how Server Connect results move from API output into App Connect rendering.

The Clients page opens

We open the Clients list page. It loads data via a Server Connect action and renders it via App Connect bindings.

The page is ready for inspection

With the page open, the next steps can trace how the frontend component and repeater bind to the backend action.

Frontend: load data from an API

First we look at how the page loads data: a dmx-serverconnect component calls a Server Connect endpoint and stores the JSON response.

The Clients page opens in the HTML editor

This step opens the page in the HTML editor so the Structure panel can be used in the following step.

The Structure panel is ready

The page is open in the HTML editor, and the Structure panel is ready so the Server Connect component can be selected cleanly.

Server Connect component

This component performs the request. In this page it is named sc_clients and calls /api/clients/list.

Component properties (URL + state)

In Properties you can see the URL (/api/clients/list) and, at runtime, state like executing, lastError, and data.

The design canvas is ready

The design surface is ready, so the repeater can be selected without mixing file-open and selection actions in the same step.

Repeater uses the response

This repeater renders one card per client. Its repeat expression is sc_clients.data.clients, so it depends on the JSON key returned by the backend action.

Backend: the Server Connect action

Now we open the Server Connect action that powers the page. The step name becomes the JSON key the page binds to.

The /api/clients/list action opens

This opens the backend endpoint used by the page and selects the query step used by the frontend binding.

Orient yourself in Server Connect editor

Start with the wider context in the Server Connect editor so the next control makes sense in the full workflow. In the next step, you will focus on The SELECT step is selected and see how it fits into this area.

The SELECT step is selected

This step selects the clients workflow step so its Query Builder button is available in the Properties panel.

The clients step output

The clients step outputs the data key used by the page. That’s why the page repeats sc_clients.data.clients.

Locate the "Query Builder" button

The Query Builder dialog opens

The Query Builder dialog opens and shows the same SELECT step used by this page. This step matters because The Query Builder dialog opens is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

Database Query Builder dialog

This dialog shows the structured SELECT query behind the clients step. From here you can inspect the source table, returned columns, filters, sorting, and preview output.

Table source

Start in the table tree to confirm the base table/view used by this clients step and any joined sources.

Selected columns

Next check Columns to verify which fields are returned to the page (and any aliases used in output).

Filters (WHERE)

Then inspect WHERE conditions to see how this query narrows records before they are returned to the frontend repeater.

Preview & test (advanced)

Finally use Preview to inspect generated SQL and test results. For parameterized queries, set test values before running.

Close Query Builder

Close Query Builder to return to the Server Connect editor and continue tracing how this selected workflow step feeds the page.

Connect backend output → frontend bindings

We return to the page and connect the exact backend output key to the frontend binding expression.

Return to views/clients.ejs

We go back to the page so you can see the binding again in context.

The repeater element is ready

The design canvas is ready again, so the repeater can be selected cleanly before the binding is explained.

Repeat binding

The repeat expression sc_clients.data.clients means: take the response stored in sc_clients.data, then iterate the clients array returned by the Server Connect action.

Wrap-up

You traced a real page to its real backend action. Next you can learn forms (POST) and database updaters (INSERT/UPDATE/DELETE).

Continue learning

Pick a related tour to go deeper.

Demo walkthrough: Contact edit (update + delete)

Use the real contact edit page and its update/delete actions to connect restored form state, validated inputs, and the backend updater steps.

Introduction

The contact edit flow is a good counterpart to the App Connect restoration tour because it shows the backend contract behind that restored state. The page loads one contact, posts updates with relationship and boolean fields, and keeps delete separate so the destructive path stays explicit.

Start from the real contact edit page and its two forms.

Trace the validated update action behind the restored controls.

Compare that richer update contract with the simpler delete action.

Frontend: one restored edit form plus one delete form

The contact edit page makes the user-facing contract explicit before you inspect the actions. One form updates the contact and keeps the restored relationship, boolean, and tag state in view. A second form handles delete as a separate destructive path.

The contact edit page opens

Start on the real contact edit page so the restored field state and the two submit paths are visible in context. This page is where one existing contact becomes either an update request or a deliberate delete request.

Design view is active for the contact edit page

Switch to Design view before selecting the update and delete forms so the next steps can inspect the live page structure instead of spending time on editor setup.

The update form owns the restored edit state

#contact_form posts to /api/contacts/update, carries the hidden id plus the editable relationship, text, email, checkbox, and tags fields, and exposes success or failure back into the same card through contact_form.data and contact_form.lastError.

The delete form stays separate because the outcome is destructive

#contact_delete is its own serverconnect form with its own success and error state. That keeps the destructive path explicit instead of burying delete inside the richer update form contract.

Backend: the update action

Once the page contract is clear, the update action becomes easier to inspect. The action accepts the relationship, text, email, phone, boolean, and tag fields explicitly, then maps them into one dbupdater UPDATE step for the contact record.

The update action opens in the Server Connect editor

The real update action is now visible in the editor, so the page contract has turned into concrete server logic. This is where the restored client, checkbox, and tags fields become validated inputs plus one database update step.

$_POST declares the editable relationship, boolean, and tag fields

At the top of the update action, $_POST defines the fields the backend will accept: id, client_id, first_name, last_name, title, email, phone, is_primary, and tags. That contract is what keeps the restored page state aligned with a validated backend shape.

The update step maps the accepted fields into one record update

update_contact is the step that turns the accepted form values into column updates on clients_contacts. Selecting it makes the updater configuration visible instead of leaving the workflow as a black box.

The updater settings show the exact contact fields being persisted

The SQL control on update_contact is where the edit contract becomes concrete column assignments on clients_contacts, including client_id, is_primary, and tags. This keeps the full contact edit workflow readable because the persistence logic stays concentrated in one dbupdater step.

Backend: the delete action

The delete action is intentionally narrower than the update action. It accepts only the contact identifier, runs one dbupdater DELETE step, and hands control back to the dedicated delete form on the page.

The delete action opens in the Server Connect editor

The real delete action is now visible in the editor. This workflow is deliberately smaller because the delete form has a narrower contract: identify one contact, delete it, and return control to the page so the destructive result can be shown clearly.

The delete action accepts only the contact identifier

Unlike the update action, the delete action needs just one required input: the contact id. That smaller contract is a useful reminder that actions should accept only the data they actually need for the operation.

The delete step is selected in the workflow tree

delete_contact is the one step that performs the removal. Selecting it makes the delete-specific updater configuration visible and keeps the workflow easy to audit.

The delete step resolves to one DELETE query

The SQL control for delete_contact shows the delete action in its simplest useful form: one required id and one DELETE against clients_contacts. That makes it easy to compare with the more detailed update workflow you just inspected.

Conclusion

The contact edit workflow stays readable because the page and actions divide responsibility clearly. The page keeps the restored relationship, boolean, and tag state visible, while the Server Connect actions own the validated update and delete operations behind that interface.

Keep restored edit state and server-side contracts aligned.

Use explicit inputs for relationship and boolean fields instead of letting them drift implicitly.

Keep delete separate when the consequence and validation needs are different.

Demo walkthrough: Files library (query + links)

Use the real files page and list action to connect the files library query, its project/client joins, and the links the page exposes downstream.

Introduction

The Demo Projects HQ files page is useful after upload as well as during upload. The list action reloads the file library with joined project and client context, and the page turns those results into outbound file links plus project navigation.

Start from the real files page and its repeated library table.

Trace the list action that joins file, project, and client data.

See how the page exposes download-style and project-navigation links from that result.

Frontend: the files table is a downstream usage surface

The files page is not only an upload form. Its table is the downstream usage surface where uploaded files become real links, project context, and sortable business information that users can act on.

The files page shows the downstream library view

Start on the real files page so the table and links are visible before inspecting the backend query. This is where the uploaded files stop being a server-side result and become usable library rows for the user.

Design view is active for the files page

Switch to Design view before selecting the files table so the next steps can inspect the live page structure instead of spending time on editor setup.

#files_list binds each row to one file record, including the direct file URL and the related project link. That makes the page a real downstream usage surface rather than a passive upload receipt.

Backend: one list query provides file, project, and client context

The files list action stays readable because it does one clear job. It selects from projects_files, joins the related project and client names, and returns the data the page needs for both file links and surrounding context.

The files list action opens in the Server Connect editor

The real list action is now visible in the editor. This is the backend counterpart to the files table, and it keeps the downstream file library readable by gathering the file rows and their context in one query.

The Server Connect editor becomes the main inspection area

The real files list action is now open in the dedicated Server Connect editor. Focus on the workflow tree and the Properties panel first so the next steps can move from the overall action structure into the selected query details.

The list action is one select query, not a chain of scattered steps

The files action uses one dbconnector select step named files, which is why the page can rely on one stable dataset. The file rows, related project name, and related client name all come back from that same action output.

The Properties panel shows the selected query configuration

Once the files query step is selected, the Properties panel becomes the main place to inspect how that query is configured. Use this broader panel view before zooming into the SQL control that summarizes the joins and ordering.

The query joins project and client names onto each file row

The query does more than fetch raw file fields from projects_files. It also joins clients_projects and clients so each row already includes project_name and client_name when the page renders the table.

The list stays useful because newest files come first

The query orders by uploaded_at descending, which matches how users usually expect a files library to behave after recent uploads. That ordering decision is part of the downstream usage experience, not just a backend detail.

Conclusion

The files library stays understandable because the page and action divide responsibility cleanly. The query returns file rows with the project and client context already joined, and the page turns that result into usable file and project links.

Treat the files table as a real downstream usage surface, not only an upload afterthought.

Join the context the page needs instead of forcing the UI to reconstruct it.

Let backend ordering and joined fields support the way users browse recent files.

Demo walkthrough: Files upload (repeat + refresh)

Use the real files page and upload action to connect multipart upload, repeat-driven inserts, and the frontend refresh loop.

Introduction

The Demo Projects HQ files page is a useful upload example because it does more than transfer bytes. The form posts multipart data, the action uploads each file, a repeat step persists one database row per uploaded file, and the page refreshes the visible library when the request succeeds.

Start from the real files page and upload form.

Trace the upload action from multipart input to repeat-driven inserts.

See how the page refreshes its live data after success.

Frontend: upload, feedback, and refresh

The files page keeps the upload contract readable on the frontend. The form names the upload action, the Dropzone field provides the batch of files, and the success hook refreshes the page data so the new files appear without manual reloading.

The files page opens

Start on the real files page so the upload form, success feedback, and files table are all visible in one place. This is the page that submits the upload request and proves whether the refresh loop exposes the new files immediately.

Design view is active for the files page

Switch to Design view before selecting the upload form and the repeated list so the next steps can inspect the live page structure instead of spending time on editor setup.

The upload form defines the request and success loop

#file_upload_form posts to /api/files/upload, sends multipart data, and wires a success handler that resets the Dropzone and reloads both sc_files and sc_summary. That one form expresses the whole frontend contract for upload plus visible refresh.

The page links project selection, Dropzone files, and the repeated list

The page keeps the upload story concrete: #upload_project_id provides project context, #files_dropzone contributes multiple files, and #files_list repeats over sc_files.data.files. That is why the upload result becomes visible on the same page without a manual reload.

Backend: upload first, then repeat inserts

The upload action is split into two useful phases. First it stores the physical files and returns an array of uploaded items. Then a repeat step iterates that array and inserts one database row per uploaded file.

The upload action opens in the Server Connect editor

The real upload action is now visible in the editor. This is where the page contract turns into two distinct server phases: store the uploaded files first, then persist one database row per uploaded file.

$_POST accepts project context and a multiple file field

At the top of the action, $_POST defines the two real inputs the backend is willing to accept: one numeric project_id and one multiple file field named demo_files. That explicit contract is what makes the later repeat step predictable.

The repeat step shows where one request becomes many inserts

save_uploads is the critical workflow node here. It iterates the upload_files output so one form submit can create one database row for every uploaded file instead of flattening the whole batch into a single record.

Each repeated iteration inserts one file record

Inside the repeat, insert_file maps the current uploaded item into projects_files columns such as filename, path, url, type, and size while reusing the posted project_id. That is the handoff from uploaded asset metadata to the project library table.

The SQL control exposes the persisted file metadata

The SQL control for insert_file makes the persistence contract concrete. Every repeated item writes one row to projects_files, carrying forward the project reference and the uploaded file metadata that came back from the upload step.

Conclusion

The files upload flow stays understandable because the phases are explicit. The page collects project context and files, the action uploads them, the repeat step persists one row per file, and the page reloads the visible data when the request completes.

Treat multipart file input and database persistence as separate phases.

Use repeat when one request should create one record per uploaded file.

Refresh the live page data after success so the result is visible immediately.

Demo walkthrough: User update (routing + session + security)

Use the real users/update.json action in Demo Projects HQ to connect route params, session context, permissions, and a secure database update.

Demo Projects HQ: User update with routing, session, and security

Use this page as the strongest server-side Demo Projects HQ path for identity-aware CRUD. The real users/update.json action is a good showcase because it pulls together route-driven record selection, session-based identity, permission thinking, and a real database update.

The goal is to give you one concrete server-side path that shows how Wappler’s routing, login context, and database actions fit together in a real project.

Demo walkthrough: Task edit (update + delete)

Use the real task edit page and its update/delete actions to connect edit-form state, dbupdater steps, and result handling.

Introduction

The Demo Projects HQ task edit flow is useful because it keeps the full edit lifecycle visible in one place. The page loads the current record, posts updates to one Server Connect action, posts deletes to another, and shows the result of each request back on the same screen.

Open the real edit page first so the forms have context.

Trace /api/tasks/update to the dbupdater UPDATE step.

Trace /api/tasks/delete to the dbupdater DELETE step.

Frontend: one edit page, two submit paths

The task edit page makes the user-facing contract explicit before you even open the backend files. One form updates the record, a second form deletes it, and each one keeps its own result state instead of blurring everything into one request.

The task edit page opens

Start on the real task_edit.ejs page so the update and delete forms are not abstract. This is the page that collects the current task state, exposes the success/error feedback, and decides which action each form posts to.

Design view is active for the edit page

Switch to Design view before selecting the update and delete forms so the next steps can inspect the live page structure instead of spending time on editor setup.

The update form owns the editable task state

#task_form is the main edit contract on the page. It posts to /api/tasks/update, carries the current task values, and exposes update success or failure back into the same form area through task_form.data and task_form.lastError.

The delete form is separate because the outcome is different

#task_delete is not just another submit button inside the update form. It has its own action, confirmation step, executing state, and success/error message because deleting a task is a different contract from editing one.

Backend: the update action

Once the page contract is clear, the update action becomes easier to reason about. The action defines its accepted fields first, then maps those fields into one dbupdater UPDATE step for the task record.

The update action in the Server Connect editor

The real update action is now visible in the editor, so the page contract has turned into concrete server logic. This is where the edit form stops being browser state and becomes validated input plus one database update step.

$_POST defines the fields the action is willing to accept

At the top of the update action, $_POST describes the allowed edit fields and their validation rules. That contract is what keeps the backend explicit about dates, numbers, required values, and the tag array before the database step runs.

The update step is selected in the workflow tree

update_task is the step that turns the accepted form values into column updates on projects_tasks. Selecting it makes the database-oriented properties visible instead of leaving the workflow as a black box.

The updater settings map page fields into one UPDATE query

The SQL control on this step is where the page fields become column assignments on projects_tasks. This action keeps the edit workflow readable because the update logic stays concentrated in one dbupdater step instead of being scattered across custom code.

Backend: the delete action

The delete action is intentionally simpler than the update action, but that simplicity is the lesson. It takes one required identifier, runs one dbupdater DELETE step, and hands control back to a dedicated delete form on the page.

The delete action in the Server Connect editor

The real delete action is now visible in the editor. This one is shorter because the delete form has a narrower contract: identify the task, remove it, and return control to the page so the delete result can be shown clearly.

The delete action accepts only the record identifier

Unlike the update action, the delete action needs just one required input: the task id. That smaller contract is a useful reminder that actions should accept only the data they actually need for the operation.

The delete step is selected in the workflow tree

delete_task is the one step that performs the removal. Selecting it makes the delete-specific updater configuration visible and keeps the workflow easy to audit.

The delete step resolves to one DELETE query

The SQL control for this step shows the delete action in its simplest useful form: one required id and one DELETE against projects_tasks. That makes it easy to compare with the more detailed update workflow you just inspected.

Conclusion

The task edit workflow stays understandable because the page and the action files agree about responsibility. The page owns the user-facing state, while the Server Connect actions own the validated update and delete operations behind it.

Keep update and delete flows separate when they have different consequences.

Use $_POST inputs to define the contract before the database step runs.

Let page feedback and action logic reinforce each other instead of drifting apart.

Demo walkthroughs: Demo Projects HQ

Beginner-to-advanced walkthroughs using the Demo Projects HQ project, connecting Server Connect Actions to the frontend pages that call them.

Demo Projects HQ walkthroughs

Pick a walkthrough. Each tour connects a real page (frontend) to the Server Connect Actions (backend) that power it.

Recipes & patterns

Common Server Connect Actions recipes you can reuse: database CRUD, emails, security, and more.

Server Connect Recipes

Use these recipes when you know the outcome you want but have not yet decided how to structure the action. Each pattern connects a common backend job to the kind of steps Server Connect uses well, so you can choose a practical starting point before building the full action.

CRUD

Query Insert/Update/Delete

Integrations

Email Webhooks

Security

Auth Access control

Pick a recipe based on the outcome you want.

Start with database + security if your endpoint touches data.

Keep actions small and composable when possible.

Connect to a Database

Create a Database Connection for your target(s), then reuse it across all your Server Connect Actions.

Create one connection per environment/target.

Reuse the connection in all DB steps.

Create Queries and CRUD

Use Database Query / Insert / Update / Delete steps to read and write data. Combine with input variables for filters and record IDs.

Validate inputs before writing.

Return consistent JSON shapes for the UI.

Send an Email

Use the Mailer step to send form data or notifications. Test locally first, then configure production credentials.

Test with a safe recipient first.

Store credentials in the right place for your deployment.

Secure Actions

Use Security Provider settings to restrict access, protect data endpoints, and manage logged-in user sessions.

Protect endpoints that return private data.

Use session/user context in steps when needed.

Next steps

Pick what you want to learn next.

Server Connect Actions

Start here for Server Connect Actions (Workflows > Server Connect Actions): manager overview, a guided path, a first action, editor deep dives, and recipes & patterns.

Server Connect Actions (start here)

If you’re new, start with the Server Connect Manager Overview, then take the guided path (manager → editor).

Use the manager to browse and organize Server Connect Actions. Use the editor hub to learn what happens inside one action (inputs → steps → output).

First Server Connect Action

First Server Connect action: add steps, test the API response, and use it in a page or component.

First Server Connect Action (mental model)

Server Connect Actions are server-side workflows that return JSON. They’re your safe boundary to the database and private services.

IMPORTANT: If it must be secure, validate input, or touch the database: do it in Server Connect Actions (not in the browser).

Inputs

GET / POST Session

Steps

DB, logic Integrations

JSON output

Used by pages/apps

Create an action (endpoint) and give it a clear name.

Define inputs so your steps can use dynamic data.

Add steps top-to-bottom, then test and inspect output.

API group

Server Connect Actions live under the API group. Click Next to select it automatically.

Add + name API Action

Next will add a new API Action under API. This step matters because Add + name API Action is part of Manager Serverconnectmanager Tree, and understanding that context makes the next action easier to repeat in your own project.

Name the new API Action

Next will rename the new action to a friendly starter name. This step matters because Name the new API Action is part of Manager Serverconnectmanager Tree, and understanding that context makes the next action easier to repeat in your own project.

The new action opens in the editor

The manager hands off to the dedicated Server Connect editor so the new action can be configured there.

The Server Connect editor is ready

The new action is now open in the dedicated editor, so the next steps can focus on its inputs and workflow steps.

Orient yourself in Server Connect editor

Start with the wider context in the Server Connect editor so the next control makes sense in the full workflow. In the next step, you will focus on Define Input Variables and see how it fits into this area.

Define Input Variables

Define inputs under Globals (GET/POST/Route/Session). These become available as dynamic data when configuring steps.

Add Steps

Add steps (DB Query, Insert/Update/Delete, Mailer, File Upload, etc.). Steps run top-to-bottom, so keep validation near the top.

Global Settings

Global Settings is where you configure shared items like database connections and security providers for the project.

Next steps

Run the action and inspect the JSON output. If something fails, work top-to-bottom: inputs → step config → step output.

Workflow Recipes

Task-focused workflow recipes: choose server-side or client-side logic and continue into the right implementation family.

Workflow Recipes

Use these workflow how-tos when you need an immediate next action instead of a broad conceptual overview. Each path is meant to connect a real task to the right Wappler surface, so you can start from the problem you have and move into the focused tour that solves it.

Decide whether the work belongs on the server or in the client.

Start in the right family instead of mixing concepts.

Use the umbrella hub for comparison, not for deep implementation detail.

Choose Server-Side Logic

Start with Server Connect Actions when the workflow must reach protected data, enforce security, or expose a reusable endpoint for the rest of the app.

Use server-side logic for trusted data work.

Keep auth and protected business rules there.

Continue into the Server Connect family for actual building steps.

Choose Client-Side Logic

Start with App Connect Flows when the workflow reacts to user interaction, page state, or client-side branching that does not require server trust boundaries.

Use client-side flows for interaction-driven logic.

Keep UI responsiveness and page behavior there.

Continue into the App Flows family for focused editor guidance.

Switch Families Cleanly

If your first guess was wrong, switch families deliberately instead of forcing one tool to do another tool’s job. The clean handoff is part of the product’s learning model.

Stop and re-evaluate where the logic should run.

Switch families before the solution gets tangled.

Use the Workflows hub whenever you need to re-orient.

Next steps

Return to the Workflows tours menu to continue with quick orientation, workflow guidance, or concept reference.

Use Quick Overview when you want the short mental model.

Use General Usage for the umbrella workflow.

Go deeper through Server Connect or App Flows when you are ready to build.

Workflows: Guided path

Pick a guided path for Server Connect Actions or App Connect Flows, then explore editors and recipes.

Introduction

Workflows are visual, step-by-step builders. In Wappler they come in two separate areas: Server Connect Actions (server-side) and App Connect Flows (client-side). Pick one to start based on what you’re trying to build.

Server-side

Secure work Data + auth

Client-side

UI + logic Branching

Bigger workspace

Dedicated editors Full focus

Choose a guided path for Server Connect Actions or App Connect Flows.

Workflows panels help you manage lists; dedicated editors are for focused editing.

Use the Workflows Index anytime to browse.

Choose a guided path

Pick the guided path that matches what you want to learn first.

Server Connect Actions

Guided path Server-side

App Connect Flows

Guided path Client-side

Server Connect Actions: build secure endpoints that return JSON.

App Connect Flows: build client-side flows triggered by UI events.

Each path stays focused on its own area.

Next steps

Start one of the guided paths, or go back to the Workflows Index.

Start Server Actions guided path to learn server-side workflows.

Start App Flows guided path to learn client-side workflows.

Use the Workflows Index anytime to browse other topics.

Workflows: Quick Overview

Get a quick overview of Workflows: the split between Server Connect Actions and App Connect Flows, and how to choose the right starting point.

Workflows Overview

Workflows is Wappler’s umbrella for visual logic builders. The first thing to understand is not every workflow belongs in the same place: server-side logic and client-side logic are separate on purpose.

Server Connect Actions run on the server and handle data, security, and reusable endpoints.

App Connect Flows run on the client and handle UI-driven logic and branching.

The fastest way to stay productive is to start in the family that matches where the logic should run.

Two Logic Areas

The core split is simple: use Server Connect Actions when the work must happen securely on the server, and use App Connect Flows when the work is driven by client-side state or interaction.

Server-side: data access, auth, protected actions.

Client-side: UI state, event flow, conditional interaction.

If you are unsure, ask where the data and trust boundary belong.

Family Entry Points

This Workflows family is an organizer, not the deepest editor guide. Its job is to send you into the correct dedicated family quickly instead of letting you mix mental models.

Use the guided path when you want help choosing.

Use the dedicated Server Connect family for server-side building.

Use the dedicated App Flows family for client-side building.

Conclusion

The beginner takeaway is simple: Workflows is the map, not the final destination. Pick the logic area that matches your task, then go deeper there.

Start with the guided path if you are still unsure.

Choose Server Connect for secure server-side logic.

Choose App Connect Flows for client-side interaction logic.

Workflows Reference

Reference tour for Workflows: taxonomy of server-side and client-side workflows, where each family fits in Wappler, and how they connect.

Introduction

Think of this reference tour as a workflow map across the main Wappler areas you revisit while building and shipping an app. It helps you recognize where common tasks begin, how one area hands off to another, and which follow-up tours deepen the part of the workflow you need next.

Workflows is the umbrella family, not the only editor guide.

Server Connect Actions and App Connect Flows solve different classes of problems.

The clean split is what keeps the manual and onboarding understandable.

Umbrella Family

Use this family when you need orientation across workflow types, cross-links into the right area, or a compact explanation of the server-side versus client-side split.

Navigation and comparison live here.

Detailed building steps live in the sub-families.

This is the reference layer for the overall model.

Server Versus Client

The core reference distinction is execution model: Server Connect Actions execute on the server, while App Connect Flows execute in the client context.

Server execution supports protected data and reusable endpoints.

Client execution supports interface-driven flow and state transitions.

The distinction is architectural, not cosmetic.

Dedicated Families

Use the dedicated families for depth: Server Connect Actions for server-side workflows, and App Connect Flows for client-side flow design and editor usage.

Dedicated families carry the implementation detail.

This family carries the cross-family map.

That separation keeps both docs and onboarding easier to grasp.

Next steps

Continue with the Workflows hub for guided entry points, or move into the dedicated Server Connect or App Flows families for deeper detail.

Return to the Workflows hub.

Use Server Connect for server-side workflow detail.

Use App Flows for client-side workflow detail.

General Usage

Typical Workflows path: choose the right logic area, move into the dedicated editor, and continue with the right family guide.

Introduction

A typical Workflows path has three decisions: choose where the logic should run, move into the dedicated editor family, and then keep building there instead of bouncing between concepts.

Decide server-side versus client-side first.

Open the family that matches the execution model.

Use the dedicated guides there for building details.

Choose the Runtime

The first useful question is runtime, not tool name. Ask whether the logic belongs on the server for security and data access, or in the client for UI response and local interaction.

Server runtime: protected logic and data work.

Client runtime: interaction and local app logic.

This choice prevents a lot of beginner confusion later.

Move into the Dedicated Family

Once the runtime is clear, stop treating Workflows as the whole lesson. Move into Server Connect Actions or App Connect Flows and stay in that family while you build the first working result.

Use Server Connect tours for endpoints and server logic.

Use App Flows tours for client-side flow design.

Depth belongs in the sub-family, not in the umbrella hub.

Return Only for Orientation

Come back to the Workflows family when you need to re-orient, compare the two logic areas, or hand off to another workflow type. Use it as a map, not as your only building guide.

Return here when switching logic domains.

Stay inside the focused family while learning deeply.

Use the umbrella hub for navigation and context.

Workflow Finish

The practical Workflows habit is to choose the execution model early, then keep the learning path focused. That is how the docs and tours stay easy to grasp instead of collapsing into one giant concept pile.

Decide runtime first.

Build in the matching family.

Use this hub when you need context or a handoff.

Workflows

A guided starting point for Workflows: Server Connect Actions (server-side) and App Connect Flows (client-side).

Workflows

Choose a Workflows tour to start. If you are new, begin with Quick Overview, then continue with the guided path or the sub-family that matches your goal.

Server Connect Actions: URL inputs (GET + Param)

Understand URL inputs in Server Connect: query string ($_GET) and path params ($_PARAM), plus how to test them reliably.

URL inputs: query string (GET) + path params

This tour builds a clear mental model for URL-based inputs.

Query string (GET): ?page=2&q=hello (after the ?). Path params ($_PARAM): /api/items/42 (in the URL path).

You’ll learn where to define these inputs in the action, and how to bind them in step Properties.

GET (query)

?page=2
&q=hello

PARAM (path)

/items/:id
/items/42

Binding

Use $_GET and $_PARAM
in expressions

Define inputs under Inputs so they’re typed and validated.

Use GET for optional filters, sorting, and paging.

Use PARAM for resource identity, such as the :id in a route.

The sample GET action is ready

This tour uses the real clients/get.json action from Demo Projects HQ. It already defines $_GET.id as a typed input and uses it in the query step, so the Properties panel shows meaningful values instead of an empty placeholder.

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 and the selected query step.

Where to define inputs

In a Server Connect Action, inputs are defined under Inputs.

This is where you add named, typed parameters for each source (GET / POST / PARAM / SESSION / COOKIE). Defining inputs up front lets you:

validate early
set defaults
keep bindings predictable

$_GET: query string values

This real action defines $_GET.id under Inputs. In Demo Projects HQ it is typed as a number and validated as required before the query runs.

That makes the API contract explicit: the action expects an id, and the rest of the flow can rely on it.

The selected step consumes that input

The client query step uses the validated input directly in its WHERE rule: {{$_GET.id}}.

This is the pattern to teach in tours: define the input under Inputs, then show a real step consuming it in Properties.

Trace the contract in the workflow tree

The workflow tree is the quick visual check that your input contract is easy to follow: define the input under Inputs, then keep the consuming step clearly named so you can trace what depends on it.

Use the same pattern for route params: define them under Inputs, type them, then bind them in the step that uses them.

Wrap-up

You now know where URL-based inputs come from and how to bind them.

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

Quick recap

GET is the query string for optional filters. PARAM is the URL path for resource identity.

Keep inputs typed and validated so the rest of the workflow stays predictable.

Define GET and PARAM inputs under Inputs with clear names, types, and rules.

Bind the values in the steps that use them so the contract stays easy to trace.

Use path params for identity and query params for filters.

Next steps

Continue with Body inputs (POST) for form and JSON payloads, or Session & Cookie inputs for logged-in context and preferences.

POST: validate incoming form fields and JSON body values.

SESSION/COOKIE: read authenticated context and persisted preferences.

Back to the editor hub when you want the broader map again.

Server Connect Actions: Body inputs (POST)

Understand POST body inputs (form fields and JSON), how to define them, validate them, and bind them safely.

Body inputs (POST): forms + JSON

This tour explains POST body inputs.

HTML forms usually send URL-encoded fields (or multipart when files are included). API clients often send JSON (application/json).

You’ll learn where to define POST inputs, how they show up as $_POST.*, and how to validate them.

POST body

Form fields JSON body

Validation

required min/max length

Binding

Use `$_POST.*` inside steps

POST is the request body (not the URL).

Define POST inputs so they are typed and validated.

Treat user input as untrusted: validate early.

The sample POST action is ready

This tour uses the real clients/update.json action from Demo Projects HQ, so you can inspect actual $_POST fields, real validation rules, and a real update step consuming them.

Orient yourself in Server Connect editor

Start with the wider context in the Server Connect editor so the next control makes sense in the full workflow. In the next step, you will focus on Define $_POST inputs under Inputs and see how it fits into this area.

Define $_POST inputs under Inputs

POST inputs are defined under Inputs → POST.

This is where you add fields like note, mode, email, etc.

Why define them?

You get defaults + validation rules
Bindings become predictable: {{$_POST.note}}
Your flow reads like a contract (what the action expects)

Binding POST fields in steps

This real update step consumes POST fields such as {{$_POST.name}}, {{$_POST.email}}, and {{$_POST.status}}.

Because the fields were defined first under Inputs, the bindings in Properties stay readable and predictable.

Validate POST inputs (don’t guess types)

The real $_POST inputs in this action show the kind of rules tours should teach: id is required and numeric, name has min/max length, email has email validation, and status is required.

That turns input configuration into a visible contract instead of guesswork inside later steps.

Form vs JSON (what changes?)

Both forms and JSON send data in the request body.

Form submissions send key/value fields (URL-encoded or multipart). JSON requests send a structured object.

In Server Connect, you still bind to body fields using $_POST.*. The key is to validate and type inputs so later steps don’t guess.

Use form encoding for classic HTML forms.

Use JSON for API-style requests (fetch/mobile).

Use multipart when uploading files (then you’ll use `$_FILES`).

Wrap-up

You now have a clear model for POST inputs: define + validate, then bind.

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

Quick recap

POST = request body.

Define inputs so you can validate and type them, then bind with $_POST.* in step Properties.

Use POST for creating/updating data and sending longer payloads.

Always validate required fields and constraints.

Keep raw inputs separate from derived values.

Next steps

Continue with sessions/cookies for logged-in context, or go back to the editor hub.

Session & Cookie inputs

Core Concepts tour

Back to the editor hub

Understand session vs cookie data, how they relate to login/auth, and how to use them as inputs in actions.

This tour builds a clear mental model for “stateful” inputs.

SESSION is server-side per-user data (who they are, what they can do). COOKIE is a small client-stored value sent with requests.

You’ll learn where to define these inputs and how to bind them safely in step Properties.

SESSION

Server-side\nper-user state

Client-stored\nrequest header

Security

Don’t trust\nraw client data

Session is where authenticated identity usually lives.

Cookies are for small values; never trust them blindly.

Define inputs under Inputs so they’re typed/validated.

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 tree selection and the Properties panel it drives.

Tree selection drives the Properties panel

This sample action already includes SESSION and COOKIE-related steps in the workflow tree. Keep the tree selection in mind, because that is what populates the Properties panel on the right.

Both SESSION and COOKIE feel like “inputs”, but they behave very differently.

SESSION lives on the server (the browser typically only sends a session identifier). COOKIE lives in the browser and is sent as a request header.

Practical rule: trust SESSION more than COOKIE. Cookies can be missing, modified, or copied between browsers.

SESSION = server-side per-user state (identity/role).

COOKIE = client-side storage (preferences, small tokens).

Never store secrets or permissions “only in a cookie”.

$_SESSION: bind the current user

SESSION inputs are typically how your action knows who is calling it.

Example: $_SESSION.user_id often comes from your login/auth flow.

Once you have a user id, you can safely load the user record, apply permissions, and scope database queries.

Use session role for permissions

A common pattern is storing a simple role/permission in the session (or deriving it after login).

Here we compute is_admin from $_SESSION.role.

Tip: permissions should ultimately be enforced on the server (DB rules, authorization steps), not only in the UI.

Cookies are good for small preference-like values.

Example: $_COOKIE.theme (dark/light) can control UI theming or return different CSS.

Important: treat cookies as untrusted input. Validate allowed values, and keep permissions in SESSION or the database.

To add these inputs:

Select Inputs
Add a new input with a name (like user_id, role, theme)
Choose a Data Type and add rules (required, allowed values, etc.)

Then you can bind them anywhere using $_SESSION.* and $_COOKIE.*.

Wrap-up

You now know what session and cookie inputs are, and when to use each.

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

Quick recap

SESSION is trusted server-side per-user state (identity/role). COOKIE is client-provided values (prefs/tokens) that must be validated.

Use inputs + rules to keep the rest of your workflow predictable.

Use SESSION for identity/authorization context.

Use COOKIES mainly for preferences and small client state.

Validate cookie values; enforce permissions server-side.

Next steps

Continue with other input sources, or go back to the editor hub.

URL inputs (GET + Route)

POST body inputs

Back to the editor hub

Server Connect Editor: Database actions (hub)

Start here for database steps in Server Connect Actions: SELECT queries with the Query Builder and INSERT/UPDATE/DELETE with the Updater dialog.

Database actions

Pick a database topic to explore. These tours focus on the database dialogs opened from Server Connect step properties (Query Builder and Updater).

Database: Insert (Updater)

Use the Database Updater dialog (opened from a dbupdater INSERT step) to set values and review conceptual SQL preview.

The Demo Projects HQ INSERT action opens

This step loads the real clients/insert.json action from Demo Projects HQ so the Updater dialog uses the project’s live database connection and schema.

The Server Connect editor is now the focus

The action now opens in the dedicated Server Connect editor. Collapse the manager so the workflow tree and Properties panel become the clear focus before selecting the database step.

The INSERT step is selected

This step selects the insert_client workflow step so its SQL/Updater options are shown in the Properties panel.

Locate the "Insert Options" button

The Updater dialog opens

The “Insert Options” control opens the Database Updater dialog for this INSERT step. This step matters because The Updater dialog opens is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

Database Updater dialog (INSERT)

This dialog configures the INSERT query: choose the target table, set column values, and optional RETURNING. The SQL shown in Preview is a conceptual representation of the generated statement, not a data preview.

Values

The Values pane maps columns to values (constants or expressions). This example uses $_POST inputs from the action to build the inserted row.

Preview

Use Preview to inspect the generated SQL structure. In Updater dialogs this is conceptual SQL preview only; Preview Data/testing is available in Query Builder dialogs.

Close the Updater dialog

When finished reviewing, you can close the Database Updater dialog to return to the Server Connect editor.

Next steps

Continue with UPDATE or DELETE (where rules), or return to the Database actions hub.

Database: Update (Updater)

Use the Database Updater dialog (opened from a dbupdater UPDATE step) to set values, define WHERE rules, and review conceptual SQL preview.

The Demo Projects HQ UPDATE action opens

Loading the real clients/update.json action from Demo Projects HQ so the Updater dialog uses the project’s live database connection and schema.

The Server Connect editor is now the focus

The action now opens in the dedicated Server Connect editor. Collapse the manager so the workflow tree and Properties panel become the clear focus before selecting the database step.

The UPDATE step is selected

This step selects the update_client workflow step so its SQL/Updater options are shown in the Properties panel.

Locate the "Update Options" button

The Updater dialog opens

In the Properties panel, click the “Update Options” button to open the Database Updater dialog for this UPDATE step.

Database Updater dialog (UPDATE)

For UPDATE, you configure two key things: the new values (SET …) and the filtering rules (WHERE …) that decide which rows get updated.

Values (SET)

Map each column you want to update to a value. Values can be expressions, like $_POST inputs, or fixed constants.

Conditions (WHERE)

The WHERE builder defines which rows are affected. Use grouped AND/OR logic and parameterized expressions to prevent accidental mass-updates.

Preview

Use Preview to inspect the generated SQL structure. In Updater dialogs this is conceptual SQL preview only; Preview Data/testing is available in Query Builder dialogs.

Close the Updater dialog

When finished reviewing, you can close the Database Updater dialog to return to the Server Connect editor.

Next steps

Continue with INSERT or DELETE, or return to the Database actions hub.

Database: Delete (Updater)

Use the Database Updater dialog (opened from a dbupdater DELETE step) to define WHERE rules and review conceptual SQL preview.

The Demo Projects HQ DELETE action opens

Loading the real clients/delete.json action from Demo Projects HQ so the Updater dialog uses the project’s live database connection and schema.

The Server Connect editor is now the focus

The action now opens in the dedicated Server Connect editor. Collapse the manager so the workflow tree and Properties panel become the clear focus before selecting the database step.

The DELETE step is selected

This step selects the delete_client workflow step so its SQL/Updater options are shown in the Properties panel.

Locate the "Delete Options" button

The Updater dialog opens

In the Properties panel, click the “Delete Options” button to open the Database Updater dialog for this DELETE step.

Database Updater dialog (DELETE)

For DELETE, the most important part is the WHERE rules. Always verify the conditions so you delete only the intended rows.

Conditions (WHERE)

Build and verify your WHERE rules carefully. Use parameters/expressions (like $_POST.id) rather than string-concatenating values.

Preview

Use Preview to inspect the generated SQL structure. In Updater dialogs this is conceptual SQL preview only; Preview Data/testing is available in Query Builder dialogs.

Close the Updater dialog

When finished reviewing, you can close the Database Updater dialog to return to the Server Connect editor.

Next steps

Continue with SELECT/INSERT/UPDATE, or return to the Database actions hub.

Database: Query Builder (SELECT)

Use the Database Query Builder dialog (opened from a dbconnector SELECT step) to inspect tables, columns, conditions, sorting, and preview the generated SQL.

The Demo Projects HQ SELECT action opens

This step loads the real clients/list.json action from Demo Projects HQ so the Query Builder opens against the project’s live database connection and schema.

The Server Connect editor is now the focus

The action now opens in the dedicated Server Connect editor. Collapse the manager so the workflow tree and Properties panel become the clear focus before selecting the database step.

The SELECT step is selected

This step selects the clients workflow step so its SQL/Query Builder options are shown in the Properties panel.

Locate the "Query Builder" button

The Query Builder dialog opens

The “Query Builder” control opens the Database Query Builder dialog for this SELECT step. This step matters because The Query Builder dialog opens is part of Serverconnecteditor Properties Control Sql, and understanding that context makes the next action easier to repeat in your own project.

Database Query Builder dialog

This dialog edits the structured SQL behind your dbconnector SELECT. You can switch panes for columns, conditions (WHERE), sorting (ORDER BY), and then preview/test the generated query.

Tables tree (left panel)

Use the left panel to browse schema and add tables/columns. For multi-table queries you can also define joins and edit join/table options.

Columns (SELECT list)

Columns define what the query returns. You can add columns, set aliases, and apply aggregates (COUNT/SUM/etc).

Conditions (WHERE)

Conditions filter rows. The builder supports grouped AND/OR rules and expression values (including Server Connect inputs like $_GET / $_POST).

Sorting (ORDER BY)

Sorting controls the result order. Add one or more sort rules (column + direction).

Preview SQL and Preview Data

Use Preview to inspect generated SQL and run Preview Data against your connection. This data preview/testing workflow is available in Query Builder dialogs (SELECT), not in Updater dialogs.

Close the Query Builder

When finished reviewing, close the Database Query Builder dialog to return to the Server Connect editor.

Next steps

Continue with the Updater dialog tours for INSERT/UPDATE/DELETE, or go back to the Database actions hub.

Demo walkthrough: Route, page, and action handoff

Use Demo Projects HQ to connect route-aware pages, layouts, and the real Server Connect actions that power them.

Demo Projects HQ: route, page, and action handoff

Use this bridge when you want one clear route-to-server map. In Demo Projects HQ there are two important handoffs. First, Routing Manager selects the route, Pages Manager exposes the real layout and content files behind that route, and the main layout route runs api/auth/current_user before EJS renders so shared partials can read current_user from locals. Second, once the page is in the browser, the content page can call additional Server Connect actions through dmx-serverconnect components or dmx-serverconnect-form.

That distinction matters: some data is attached server-side during route rendering, while other data is fetched client-side after the page loads. Continue into the validated Demo Projects HQ walkthroughs below depending on whether you want the layout/session path, data loading, or form posting.

Routing starts with the real route map

Begin on the real Routes root in Routing Manager. This is the first handoff in the chain: it shows which routed page structure is matched before any layout or Server Connect action is involved.

Pages Manager overview

Keep the full Pages Manager surface in view before focusing on one routed file. This is where the route map turns into concrete layout and content files in Demo Projects HQ.

The routed layout folder

The layouts folder is where the route-level shell becomes concrete in Demo Projects HQ. Seeing it here makes the handoff explicit: routes do not stop at URL patterns, they resolve into reusable layout files before any page-level Server Connect logic runs.

The real layout tile

The live main.ejs tile is the concrete layout file behind the routed shell in Demo Projects HQ. It is also the place where route-level server data becomes visible in practice: app/config/routes.json assigns api/auth/current_user to the main layout, so current_user is already available in EJS locals for the navbar and sidebar before the content page renders. From there, the content page can add its own Server Connect actions to load interactive JSON, submit forms, or apply security-aware updates inside that routed structure.