Server Connect Actions: Control Flow & Reuse

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.

Screenshot: Opening the sample action…Click to open the larger image

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.

Screenshot: Orient yourself in Server Connect editorClick to open the larger image

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.

Screenshot: Containers create nested flowsClick to open the larger image

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.

Screenshot: If Properties: the condition + branchesClick to open the larger image

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

Screenshot: Then/Else steps are normal stepsClick to open the larger image

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.

Screenshot: Multi-branch container: expression + casesClick to open the larger image

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.

Screenshot: Case branches stay readable in the treeClick to open the larger image

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.

Screenshot: Try/Catch Properties: map failures to responsesClick to open the larger image

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.

Screenshot: Core action: Error (and Catch variables)Click to open the larger image

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.

Screenshot: Repeat Properties: iterate + shape outputClick to open the larger image

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.