Guide

Build your own flow.

From a process in your head to a published workflow your team can use: nine steps by hand, or let your favourite AI assistant write the first draft, connections to your other systems included.

Step by step

01
Map the process on paper first
Write down, in plain words, what happens from the first request to the last outcome. Answer five questions:
- Who starts it, and what do they need to tell you (the form)?
- Who must approve, in what order, and does anything change the route (an amount, a risk level, a type)?
- How long may each step take (the deadline), and should weekends count?
- What happens when someone rejects or sends it back?
- Does another system need to know, for example an ERP, CRM or HR system?
Set up your people
Under Administer, open Organisation to add departments and their heads, then Users and roles to add people, give each a role and choose their line manager. ProcessIQ routes work by role (for example Approver or Process Operator), by line manager and by department head, so the people and managers you set up here decide who receives each step.
Connect your other systems (optional)
Under Administer, open Integrations and add one integration per system: a name, the base address, how ProcessIQ signs in (none, API key, bearer token or basic) and the secret. The secret is stored encrypted and never shown again. Integrations are available on plans that include API integrations; see pricing.
Workflow designers then pick the integration by name and choose only the path, never the host, so a workflow cannot be used to reach arbitrary servers. Every call is logged with its result.
04
Create the workflow
Open Workflows. You have four ways to start:
- Templates tab: copy one of the ready-made workflows and change it. The quickest way.
- Build with AI: describe the process in a few sentences and review the draft.
- Import: upload a JSON file, for example one written by your own AI assistant (see the prompt below).
- New workflow: start from a blank canvas.
Design the request form
Add the fields the requester fills in. Choose a type for each (text, number, currency, date, choice, file and more), mark what is required, and use conditions to show a field only when it matters, for example a reason that appears only above a certain amount. Calculated fields work out totals for you. Keep the form to what the approvers and connected systems actually need.
06
Draw the route
On the canvas, add steps and connect them. The building blocks are:
- Approval: any, all, sequential, majority or percentage of the approvers, with a deadline, a fallback person and optional limits by amount.
- Task: work for a person or role to complete, with a due time and priority.
- Condition: choose a route from the form, for example form.amount > 10000.
- Timer and Notification: wait, or tell someone.
- Parallel fork and join: run reviews at the same time.
- API call: send or fetch data through one of your integrations, keep parts of the answer for later steps, and route failures to a person.
Validate and simulate
ProcessIQ checks the design and lists every problem in plain words, for example an approval with no rejected route. Fix them, then run a simulation with sample data to see which path a request would take before anyone uses it.
Publish
Publish when the checks pass. Every publish creates a new version and keeps the old ones. Requests already running finish on the version they started with, so you can improve a workflow without disturbing work in progress.
Try it, then improve it
Submit a request as a requester, then sign in as the approvers to act on it. Use Reports to see volumes, completion times and where deadlines are missed, then edit the workflow and publish a new version. You can practise every step in the live demo first.

Intelligence

Let your favourite AI design it.

This prompt teaches any AI assistant (ChatGPT, Claude, Gemini or your own) how ProcessIQ workflows are built, so its answer imports straight into ProcessIQ: steps, approvers, deadlines, conditions, the request form and calls to your own systems.

ProcessIQ's built-in Build with AI drafts approvals, tasks and forms from a description. It does not create connections to your integrations, which is why this prompt exists.

Copy the prompt below.
Fill in the square-bracket parts: your business, the process in plain words, your roles, and your connected systems with the exact names you will give them in ProcessIQ.
Paste it into your favourite AI assistant and send it.
Copy only the JSON code block from the answer and save it as a file, for example my-flow.json. The AI also lists what to check before importing.
In ProcessIQ, create each integration it names, using exactly the same names (Administer, then Integrations).
Open Workflows, choose Import and select the file. The workflow appears as a draft.
Open it in the designer, validate, simulate with sample data and publish.

Prompt for your AI assistant

You are an expert business-process designer. Design ONE workflow for the product "ProcessIQ" (workflow automation and approvals) and return it as a single JSON object that I can import into ProcessIQ.

Reply with the JSON in one code block. After the code block add a short list called "Check before importing" with your assumptions, the integrations I must create in ProcessIQ, and any roles I must have. Do not add other commentary.

# 1. About my business and this process (I fill this in)

Business: [describe your organisation, its size and industry]
Process to automate: [for example purchase approval, employee onboarding, refund requests]
Who starts it: [roles or departments]
What happens, in plain words: [steps, who approves, thresholds such as "above 10,000 needs finance", deadlines, what happens on rejection, exceptions]
Roles in my ProcessIQ organisation: Requester, Approver, Department Manager, Organisation Admin, Organisation Owner, Process Operator, Workflow Administrator, Workflow Designer, Reporting Analyst, Auditor [add any custom roles here]
My connected systems (ProcessIQ "integrations"): [for each one: its exact name | what it does | the endpoints to call, for example "POST /api/purchase-orders with amount and vendor, returns data.id"]. Write "none" if there are none.

# 2. Output format

{
  "name": "short title",
  "description": "one sentence",
  "category": "HR | Finance | Procurement | IT | Legal | Compliance | Operations | Sales | Marketing | Other",
  "referencePrefix": "1 to 8 letters, for example PR",
  "graph": { "nodes": [ ... ], "edges": [ ... ] },
  "form": { "fields": [ ... ] }
}

# 3. Nodes

A node is {"id", "type", "name", "config", "position": {"x", "y"}}. Ids are short and unique (for example "start", "mgr", "fin"). Give every node a position: x grows by 220 for each step from left to right, and parallel or alternative branches differ in y by 120.
Allowed types only: start, end, approval, task, condition, timer, notification, parallel_fork, parallel_join, api_call. Do not use any other type.

- start: exactly one. No config.
- end: at least one. config {"outcome": "completed"} or {"outcome": "rejected"}.
- approval: config {"mode": "any | all | sequential | majority | percentage", "approvers": [ASSIGNEE], "fallback": ASSIGNEE, "slaHours": 24, "slaMode": "calendar | business", "allowSelfApproval": false, "requireCommentOnApprove": false}. For "percentage" also add "threshold": a number from 1 to 100. Optional approval limit by amount: "amountField": "<form field key>" and "approvalLimit": <number>. Optional "separateFromPriorApprovers": true when the same person must not approve twice.
- task: config {"title": "...", "assignee": ASSIGNEE, "fallback": ASSIGNEE, "dueHours": 48, "dueMode": "calendar | business", "priority": "low | normal | high | urgent"}.
- timer: config {"durationMinutes": 60, "mode": "calendar | business"}.
- notification: config {"title": "...", "message": "...", "recipients": [ASSIGNEE]}.
- condition: no config. It chooses a route from the expressions on its outgoing edges.
- parallel_fork and parallel_join: run steps at the same time. No config. A fork has exactly ONE incoming edge (put a task or notification before it if several routes lead to it) and at least two outgoing edges. Its matching join has at least two incoming edges and exactly ONE outgoing edge.
- api_call: calls one of my integrations. See section 6.

# 4. Who does a step (ASSIGNEE)

{"kind": "manager"} (the requester's line manager) | {"kind": "department_head"} | {"kind": "requester"} | {"kind": "role", "value": "<role name from section 1>"} | {"kind": "field", "value": "<key of a form field of type user>"} (the person the requester picks).
Never name a real person and never use kind "user". Every approval and task needs "fallback": {"kind": "role", "value": "Organisation Admin"} so it can never get stuck.

# 5. Edges and conditions

An edge is {"id", "from", "to", "outcome", "condition", "isDefault", "label"}.
- Edges leaving an approval must have "outcome": "approved" or "rejected" (and optionally "returned" to send the request back for correction). Every approval needs both an approved edge and a rejected edge.
- Edges leaving start, task, timer, notification and parallel nodes have no outcome, and each of those nodes (except a fork) has exactly ONE outgoing edge.
- Every node has a name. start has no incoming edge. end has no outgoing edge.
- A condition node has two or more outgoing edges. Each has a "condition" expression, and exactly one has "isDefault": true (that edge has no condition).
- Every node must be reachable from start and every path must reach an end.
- Expressions use form.<fieldKey> and vars.<name> (values saved from api_call responses). Operators: == != < <= > >= && || ! + - * /, "in [...]". Strings use single quotes. Functions: len(x), contains(a, b), lower(x), isEmpty(x).
  Examples: form.amount > 10000 | form.risk == 'high' && form.amount > 500 | form.country in ['NG', 'GH'] | vars.creditOk == true

# 6. Connections to my other systems (api_call)

Use an api_call node whenever the process must read from or write to one of the systems I listed. Config:
{"integration": "<exact integration name from section 1>", "method": "GET | POST | PUT | PATCH | DELETE", "path": "/relative/path", "headers": {"X-Source": "flow"}, "body": "<JSON text>", "timeoutSeconds": 15, "maxAttempts": 3, "mapping": {"poNumber": "data.id"}}
Rules:
- "path" is relative, starts with a single "/", and never contains a host or "://". The host comes from the integration.
- Never put credentials, tokens or an Authorization header anywhere. ProcessIQ adds authentication from the integration settings.
- Insert form answers with placeholders: {{form.fieldKey}} inside JSON strings, {{json:form.fieldKey}} for numbers, booleans or whole JSON values, {{url:form.fieldKey}} inside the path or query string. Saved values are read with {{vars.name}}.
- "mapping" saves parts of the JSON response into variables. The key is the variable name (letters, digits and underscores, starting with a letter) and the value is the dot path in the response, for example "data.id" or "items.0.name". Use the variables later in conditions (vars.poNumber) and in further api_call bodies or paths.
- "timeoutSeconds" is 1 to 30. "maxAttempts" is 1 to 5.
- Each api_call has exactly one success edge (no outcome, or "outcome": "success") and should have one "outcome": "failed" edge that leads to a task for a Process Operator or to an end with outcome "rejected".
Example node: {"id": "erp", "type": "api_call", "name": "Create purchase order", "config": {"integration": "ERP", "method": "POST", "path": "/api/purchase-orders", "body": "{\"amount\": {{json:form.amount}}, \"vendor\": \"{{form.vendor}}\"}", "mapping": {"poNumber": "data.id"}}}

# 7. The request form

"form": {"fields": [ {"key", "label", "type", "required", "options", "min", "max", "maxLength", "pattern", "visibleWhen", "requiredWhen", "calculation", "defaultValue", "section", "helpText"} ]}
- key is camelCase and unique. Types: text, textarea, number, currency, date, datetime, select, multiselect, radio, checkbox, yesno, email, phone, file, user, department, calculated, richtext.
- select, multiselect and radio need "options": [{"value": "a", "label": "A"}].
- Pair every currency amount with a "currency" select field (for example NGN, USD, EUR, GBP).
- visibleWhen and requiredWhen are expressions on other fields, for example "form.type == 'replacement'". A "calculated" field has "calculation", for example "form.quantity * form.unitPrice".
- Ask only for what the approvers and the connected systems actually need. Use "section" to group long forms.

# 8. Design rules

- Practical: 3 to 12 steps. Put approvals in the order a real organisation would, with SLAs in hours that match the urgency.
- Use conditions where amounts, risk or type change the route. Use "business" time for SLAs that should skip weekends and holidays.
- Every rejection ends the request clearly (an end node with outcome "rejected", optionally after a notification to the requester).
- Finish with a notification to the requester when the request is approved.

# 9. Changing a flow later

If I paste an existing flow's JSON and ask for a change, return the COMPLETE updated JSON object again (not a patch), keep every id that is not affected, and keep the same output rules as above.

If ProcessIQ reports problems

Copy the list of issues from ProcessIQ, send this follow-up in the same conversation and import the corrected file.

Follow-up prompt

ProcessIQ reported these problems when I imported your workflow:

[paste ProcessIQ's list of issues here]

Return the complete corrected JSON in one code block, following the same format and rules as before. Change only what is needed to fix these problems.

Good to know

Never paste passwords, tokens or API keys into an AI assistant. The prompt does not need them: you add credentials to the integration in ProcessIQ, where they are kept protected.
The prompt tells the AI never to name real people. It assigns steps by role, line manager or department head, so the result works for any organisation with those roles.
Nothing goes live on its own. You always review the draft, validate, simulate and then publish.
The workflow can only call integrations that an administrator has created, and only on the paths you approve.

Ready to build yours?

Start a free trial, or look around the live demo first.

Start free trial Try the live demo

Build your own flow.

Step by step

Map the process on paper first

Set up your people

Connect your other systems (optional)

Create the workflow

Design the request form

Draw the route

Validate and simulate

Publish

Try it, then improve it

Let your favourite AI design it.

If ProcessIQ reports problems

Good to know

Ready to build yours?