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 optionally a default case).

Keep each case focused on one outcome.

Avoid duplicated steps across cases (extract repeated bits).

Use a default branch to handle unexpected values safely.

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

This pattern is often clearer than stacking many If blocks.

Case steps: return consistent output

Each case should produce a consistent output shape.

In this sample, the selected Select container shows the case definitions in Properties, including the values that set mode_message for the response.

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.