Workflows

Pinch sets this up for you

Your customer success manager configures workflows, decisions, variables, and playbooks during onboarding. The defaults are tuned to your actual data and work for most merchants. You can skip this page unless you want to customize behavior yourself.

The Workflows page is where every Pinch decision is defined. The dashboard shows two views: an analytics view (the default — a flow diagram of how recent events were routed) and an editor view (click Edit flow to enter).

There are two workflows on every account:

• Orders workflow — runs on every order event at checkout time. Use it for reseller-abuse detection (block bot orders, hold limited-release orders for review), return-abuse pre-screening (flag a known abuser's order before it ships so CX can intercept), or both. The Orders workflow's job is decisioning at the point of order, which makes it useful any time you want to act before the box ships.
• Returns workflow — runs on every return initiation. The classic return-abuse path.

You switch between them via the tabs at the top.

The analytics view

The default Workflows view is a Sankey-style diagram with three columns:

• All Responses — total events that ran through the workflow in the selected window (e.g., 100% | 2.0M)
• Decision — split between ALLOW and REVIEW and (if any) DENY, with counts and percentages
• Action — which named branch matched inside each decision lane (e.g., Default Approve, Pinch-First-Order, VIP, Pinch-Second-Order)

The numbers above each bar are formatted as percentage | count. This view is read-only — it's the report card on how the workflow has actually been firing. Use it weekly to sanity-check that traffic is flowing through the branches you expect.

Top-right has the same time range selector as Analytics: Today through 1Y and Go Live.

The editor

Click Edit flow to enter the visual editor.

Top bar

Element	What it does
Decisions (left, back-arrow)	Return to the Workflows analytics view without saving.
Allow / Review / Deny (lane tabs)	Switch between the three lanes. Each lane holds the Decisions that produce that outcome.
Default: {name} dropdown	The fallback Decision when no other branch matches. Typically Default Approve.
Preview & Save (top right)	Dry-run the workflow against recent events before publishing.

The canvas

The canvas shows the active lane top-down. Each numbered row is one branch:

Execute → 1 → [Decision: VIP] → If: [High Margin condition] → Elif: [High Margin Cond 2]
         → 2 → [Decision: Pinch-First-Order] → If: [Pinch First Order condition]
         → 3 → [Decision: Pinch-Second-Order] → If: [Pinch Second Order condition]

Branches are evaluated top-down. The first branch where the condition matches wins, and the workflow stops evaluating further branches in that lane.

Decision blocks

Each row references a Decision — a named, reusable rule definition with three properties:

• A Decision Type: Allow, Deny, or Review. This determines which lane the Decision sits in and the outcome it produces.
• A Sub Decision label: a configurable name surfaced on every API response and in the dashboard (e.g., Default Approve, Suspect Abuse, Egregious, High Customer Value). The Sub Decision label is also the segment name that Playbooks can target.
• An optional Decision Reason template: a human-readable explanation that appears in the API response.

Decisions are created and edited inside the Workflow editor as you build the flow. When you drop a new branch onto the canvas, you give it a name (which becomes the Sub Decision) and pick its Decision Type — that's the Decision.

The same Decision can be used in both the Orders and Returns workflow without duplication; click an existing Decision block to swap it for a different one. Click the three-dot menu on the block to disable that branch without deleting it (useful for A/B testing).

Condition blocks

To the right of each Decision is one or more condition blocks linked with If / Elif. Each condition has:

• A name (e.g., "High Margin", "Pinch First Order")
• A join: All of the following are true (AND) or Any of the following are true (OR)
• One or more rules of the form [Variable] [Operator] [Value]

Example condition:

All of the following are true

• Where Customer Value by Email Greater than 1000
• And Return Rate by value by Email Less than 0.35
• And Orders placed from this email in last 6 months Greater than 2

The variables come from the Variables library. The operators are standard comparisons (Greater than, Less than, Equal to, Not equal to, Contains, Is empty, Is not empty). The value is the threshold you set.

Adding to the canvas

Hover between any two rows to reveal a + button — clicking it inserts a new branch in that position. The bottom of the canvas has an explicit Add Action button.

Zoom and lock

The bottom-left corner of the canvas has + / - zoom controls, a fit-to-screen icon, and a lock that prevents accidental edits while you read the workflow.

Preview & Save

Clicking Preview & Save runs the modified workflow against the last 24 hours of real events without committing changes. You see a diff: which events would have flipped from ALLOW to REVIEW, which REVIEWs would now ALLOW, etc.

Only publish (commit) once the preview matches what you intended. Once published, the new logic runs on every new event immediately.

Email Templates submenu

Underneath the Workflows entry in the left nav is a sub-page called Email Templates.

Templates list

The Email Templates page lists every reusable email body Pinch can send when a workflow branch triggers an email action. Each row shows:

• Template name (e.g., "Return Block Warning")
• Event type tag — the workflow event that fires this template (e.g., Return Warning)
• Updated date
• Language code (e.g., EN)
• Row actions: duplicate, edit, more menu

Filter tabs at the top let you narrow by event type. Top-right has + New Template.

Template editor

Click a template row to open the editor:

Field	Purpose
Template Name	Internal name, shown only in the editor
Sender Email (optional)	Overrides the default sender for this template — useful for sending VIP-tier emails from a different domain
Event Type	Maps the template to a workflow event (e.g., Return Blocked Warning)
Language	Multilingual templates are supported — same event, different language
Email Subject	The subject line
Email Body	The body — supports inline variable interpolation
Available Variables	Click any pill (e.g., {customer_name}, {RETURN_POLICY_LINK}, {order_number}) to insert it at your cursor position
Preview	Live preview of the rendered email with variables resolved against a sample customer

Standard variables available:

• {customer_name} — first name of the customer
• {order_number} — the disputed order's ID
• {RETURN_POLICY_LINK} — your store's return-policy URL (set in Integrations → Customer Support)
• More variables are added per event type

How Workflows interact with the rest of Pinch

What	Where
Decisions referenced in workflow branches live in	Decisions library
Variables referenced in conditions live in	Variables library
Email Templates fired by workflow actions live in	Workflows → Email Templates
Outcomes (ALLOW / DENY / REVIEW) show up in	Review queue and your RMS's customer-tag reads
Real-time signals that variables aggregate from	Pinch Identity Number

See also

• Decisions — the reusable rule blocks that workflows compose
• Variables — the signals workflow conditions reference
• Review queue — where REVIEW decisions end up
• Playbooks — automated actions triggered when a workflow puts a customer into a segment