Skip to content

General Usage

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

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.

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.

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.

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.

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.