# Workflow Concepts

A **workflow** is the complete portal experience for one role: which pages exist, how they're laid out, and what users with that role can do. Every user logs in, the system finds their role, and the workflow attached to that role shapes everything they see.

## How everything connects

```
User → Role → Workflow → Modules (pages) → Components
```

* A **user** is assigned a **role** when you give them access.
* The **role** is attached to one **workflow** (Settings tab → *Role* dropdown).
* The **workflow** is built from one or more **modules** — each module is a single page or functional area.
* Each **module's page** is designed in the **Page Builder** using **components**.

A workflow targets one of four **entity types** — Employee, Customer, Vendor, or Partner. The grouping you see on the Workflows page comes straight from this field.

## What a workflow defines

* **Which pages are available** — Dashboard, Order Form, Catalog, Reports, Public Page, Modal, and general-purpose Pages.
* **How navigation is structured** — sidebar items, header layout, page order.
* **What entity type it targets** — Employee, Customer, Vendor, Partner.
* **Which role gets it** — selected on the workflow's Settings tab.
* **Per-workflow configuration** — default catalog, default price level, PIN requirements, session variables, and global CSS.

## Workflows and roles

The relationship is **one workflow per role at any given time** — only one Published workflow can exist for a role. To swap versions, copy the workflow, edit the copy, then publish it; the old version is automatically set to Draft.

If two roles need the same portal experience, you can configure two separate workflows that look identical, or have one role use a workflow that the other role doesn't.

## The workflow lifecycle

{% stepper %}
{% step %}

### Create

On the Workflows page, click **Create Workflow**. Pick the entity type and BRM role, optionally start from a default template or copy an existing workflow.
{% endstep %}

{% step %}

### Configure

Open the workflow. The **Settings** tab carries the role link, the default catalog, the default price level, PIN requirements, and session variables.
{% endstep %}

{% step %}

### Add modules

On the **Workflow** tab, click **+ Module** to add pages — Dashboard, Order Form, Catalog, Reports, and so on. See [Module Types](/client-admin-guide/active-workflows/module-types.md).
{% endstep %}

{% step %}

### Design each module's page

Click any module card to open the Page Builder for that module. Drag in components, configure them, save.
{% endstep %}

{% step %}

### Test

There is no built-in preview today. Create a test user with the target role and log in to the User Portal in an incognito window to verify what the workflow looks like to a real user.
{% endstep %}

{% step %}

### Publish

On the Workflows page, click **Publish** on the workflow row. The workflow becomes live for any user with the assigned role. The previous Published version (if any) is automatically set to Draft.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
After publishing, end users may need to refresh their browser to see the latest pages. Most of the time the change reaches them automatically on their next navigation.
{% endhint %}

## Default workflows

<code class="expression">space.vars.productName</code> ships with default workflow templates per entity type. When you create a workflow, you can tick **Use Default Workflow Template** to start from one, or **Copy from Existing Workflow** to clone any current workflow. See [Default Workflows](/client-admin-guide/workflow-builder-overview/default-workflows.md).

## Best practices

* **Start with a default template.** Cloning is faster and safer than building from scratch.
* **Keep workflows focused.** Don't pile every feature into one workflow — match the role's actual job.
* **Name them clearly.** *Retail POS Cashier* beats *Workflow 1* when you're scanning the list a year from now.
* **Test with the target role.** Always log in as a test user to see what your workflow really looks like — admin previews can hide subtle role-based differences.
* **One workflow per role.** Don't try to multiplex two roles through conditional logic in one workflow. Two roles, two workflows is simpler to maintain.

## Related

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Workflow Builder</strong></td><td>The Workflows page — list, status, row actions.</td><td><a href="/pages/mLgK2JGhOVvPaMyi0m1U">/pages/mLgK2JGhOVvPaMyi0m1U</a></td></tr><tr><td><strong>Module Types</strong></td><td>Reference for every available module type.</td><td><a href="/pages/g2JG7KMppsgCgHq9QDJ3">/pages/g2JG7KMppsgCgHq9QDJ3</a></td></tr><tr><td><strong>Creating Custom Workflows</strong></td><td>Step-by-step build from scratch.</td><td><a href="/pages/HXAKNURkKoLjhJP3Y3ht">/pages/HXAKNURkKoLjhJP3Y3ht</a></td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.in8sync.com/client-admin-guide/workflow-builder-overview/workflow-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.