Flows

Part of the IP4CMS portal. ← All module guides

What it's for — Flows are how you build the forms residents and staff fill in and the multi-step onboarding journeys they complete. You build a flow template once — an ordered set of steps with the questions, content, actions and transitions inside each step — and run it many times. Each run is a flow instance that captures the answers and tracks progress to completion. In IP4CMS this powers member and customer onboarding and the forms people submit. (In some deployments this area is labelled Forms in the navigation, but the underlying module is the same.)

Where to find it — In the main portal navigation open Flows. The module opens on the Flow Templates list by default. From there you can reach Flow Templates, Onboarding Types, Flow Instances and Onboarding Records. Template configuration also has a settings area under Settings → Flows.

Before you start

• Licence — your tenant must have the Flows module enabled. If you cannot see the Flows menu item, the module is not licensed for your site.
• Permissions — building and running flows is permission-gated. Without the relevant permission the matching buttons (Create Template, Edit, Create Instance, Status) simply do not appear. See Permissions & access.

Key tasks

Build a flow template (steps, items and versions)

A template is the blueprint. Open Flows → Flow Templates and click Create Template (or Edit on an existing one).

Template Information

• Template Name (required, minimum 3 characters) — the internal name operators see in the list.
• Description — optional notes on what the flow is for.
• Instance Subject Template — an optional pattern used to compute a readable subject for each instance. Use content-key placeholders, e.g. Application for {{first_name}} {{last_name}}. The placeholders are filled from answers as the flow runs.
• Webhook Endpoint — an optional URL that is called when an instance of this flow completes. Use this to notify an external system.

Steps — Click Add Step to add a step. Each step has:

• Step Key (required) — a short unique key (e.g. personal_details) used to reference the step in conditions. Keys must be unique within the template.
• Name and Description — shown to the person running the flow.
• Entry Step — marks the step where the flow begins.
• Exit Step — marks a step that can end the flow.
• Steps run in the order you arrange them and can carry availability and transition rules so later steps only appear when earlier answers qualify.

Items — Inside each step click Add Item to add the building blocks. The available item types are:

• Question — collects input. Input types include text, number, date/datetime, email, phone, textarea, select, multiselect, checkbox, radio, file, image and a multi-field form. Questions support required flags, placeholders, help text, validation rules (min/max, length, regex pattern, or a Luhn check-digit algorithm), and filtered dropdowns whose options depend on an earlier answer.
• Content — display-only text, HTML, image, video or document shown to the user.
• Action — runs a backend handler when reached (for example setting an onboarding status, or sending and verifying a one-time PIN by email or SMS).
• Section — groups items together; can require all child items be completed before moving on, and can display as default, tabs or wizard.
• Transition — a button that moves the flow (next step, go to a named step, or end the flow).

Each item has an item key (for conditions) and a content key (the name its answer is stored under in the instance data). Keep content keys stable and meaningful — they are what subject templates and downstream systems read.

Saving and versions — Click Save Template. You can also Import JSON when creating a new template to load a prepared definition. Open a template's detail page to mark it Active (only active templates can create instances) and to view its Version History — each saved change is snapshotted as a numbered version, and running instances stay pinned to the version they were created from.

Define onboarding types

An Onboarding Type is a catalog entry that points at a default flow template and supplies branding for the welcome screen. Open Flows → Onboarding Types and click New onboarding type.

Fields:

• Code (required) — a short unique code for the type.
• Name (required) and Description.
• Flow template (required) — the template a journey of this type will run.
• Welcome page customisation — Welcome title, Welcome message, and Desktop background / Mobile background / Welcome logo images. These values are used on member and partner onboarding welcome pages ahead of the portal defaults.

Onboarding types are the bridge between a journey "kind" (e.g. a new resident, a supplier) and the flow that journey should run. Member Types reference an onboarding type so that signing up as a given member type launches the right flow; member types are managed under Settings → Member Types.

Launch and track flow instances

A flow instance is one run of a template.

To launch one manually, open a template's detail page and click Create Instance. Most instances, however, are created automatically — when a member or customer begins an onboarding journey, or when a survey is sent out, the system creates the instance for them.

To track instances, open Flows → Flow Instances. The list shows each instance's name, computed subject, status and timestamps. Search by name or subject, filter by status or template, and Export CSV for reporting.

Click View on an instance to open its execution page. There you see:

• The instance name and status badge — draft, in_progress, completed or cancelled.
• A step progress indicator showing each step as active, completed, pending or skipped.
• The questions and content for the current step, where you can fill in or review answers.
• For completed instances, a summary of captured values and any webhook delivery status.

Use History on an instance to review the recorded changes to its answers over time.

Review onboarding records

An Onboarding Record is the runtime journey object that ties an onboarding type, its flow instance and the person being onboarded together. Open Flows → Onboarding Records.

The list shows the linked Member, Customer, Organization/partner, Type, Status and submission/resolution timestamps. Search across onboarding, member, customer and flow IDs, filter (including by partner), and Export CSV.

Click View to open a record and see its details — name, email, phone, type, status, linked flow instance, and created/updated/submitted/resolved dates. If you have update rights, click Status to change the record's status (for example to approve or reject a submission).

How the data connects

The Flows module is the shared workflow engine for several portal features:

• Templates → instances — every flow instance is created from a template at a specific version, and copies that version's steps and items so the run is stable even if you later edit the template. Answers are stored in the instance under each item's content key.
• Onboarding — an onboarding type names a default flow template and welcome branding. Member types point at an onboarding type, so a person signing up as a given member type runs the matching flow. At runtime an onboarding record links the member, customer or supplier to the flow instance that drives their journey, and an action item inside the flow can set the record's status as it progresses.
• Members & customers — onboarding records reference the member, customer or supplier the journey belongs to, so completing a flow feeds real records elsewhere in the portal.
• Surveys — surveys are built on top of flow templates and instances: a survey template wraps a flow template, and each response is a flow instance. So building a survey reuses the same step-and-item builder described here.
• Taskr / external systems — a template's Webhook Endpoint fires when an instance completes, letting downstream systems (including task or workflow tools) pick up the result.

Permissions & access

Access is controlled by these permissions. A user with admin:full:access is granted all of them.

Onboarding-type create/update/delete actions are gated by the corresponding create/update/delete rights, and buttons hide automatically when you lack permission.

Tips & gotchas

• Active toggle controls launching. Only templates marked Active can create instances. If "Create Instance" is missing or a journey won't start, check the template is active.
• Keep keys stable. Step keys, item keys and especially content keys are referenced by conditions, subject templates and downstream systems. Renaming a content key on a live template can break subject lines and integrations — prefer adding a new version over silently re-keying.
• Instances are version-pinned. Editing a template does not change instances already in progress; they keep the version they were created from. Use Version History to see what changed.
• One flow per onboarding record. Each onboarding record links to at most one flow instance, so re-running a journey generally means a new record/instance pair rather than re-using the old one.
• Set the subject template early. It only computes a readable subject from answers that exist — placeholders that reference keys collected later in the flow stay blank until those answers come in.
• Webhooks fire on completion. If an external system needs the result, confirm the Webhook Endpoint is set and reachable; the instance summary shows delivery status.
• "Forms" vs "Flows". Some sites relabel this module as Forms in the menu. The screens, builder and concepts are identical.