Per-workflow revenue attribution. Identifies which automations actually generate $ vs which just shuffle contacts around.
At a glance
Per-workflow commerce-revenue attribution. For each HubSpot workflow that ran in the window, the dollar revenue from contacts who completed a commerce order within 7 days of being touched by that workflow. Separates the automations that actually pay for themselves from the ones that merely shuffle contacts between lists. Computed as sum(commerce.order.total) WHERE order.customer_email IN workflow.enrolled_contacts AND order.created_at - workflow.action_completed_at <= 7 days, grouped by workflow_id.
Calculation
Calculated automatically from your HubSpot data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A services consultancy at $620k MRR running HubSpot Operations Hub plus a Stripe-billed engagement model alongside a Shopify Plus subscription store for productised offerings. Reading on 14 Apr 26 over the trailing 90 days (15 Jan 26 to 14 Apr 26). Top 6 workflows by attributed revenue:
Roll-up:
Five things this picture reveals:
01_post_demo_followupis the highest-leverage workflow at $101 per enrolment. Sales-rep-triggered post-demo emails convert demo-takers into paying customers within a week. The merchant should not retire this even if open-rate looks middling; revenue-per-enrolment is the right lens, not engagement.- **
06_subscriber_welcomelooks busy but produces 9,640 in 7-day attributed revenue. The workflow is “shuffling contacts around”, not paying for itself. Two options: shorten to a single email, or add a stronger offer in the second email. - **
04_winback_dormant_60druns at 42,800) even though the per-enrolment figure looks weak. Winback campaigns succeed by playing the volume game; the merchant should keep the workflow but expect modest per-touch numbers. - The list-segment refresh lag bias affects
02_trial_to_paid_nurturereading. This workflow useslifecyclestage = trialas its enrolment trigger. When HubSpot’s trial-to-customer transition arrives via Stripe webhook, there is a 5-15 minute lag before the workflow next-action evaluates and the contact exits the workflow. During that lag, the workflow can fire one extra “still on trial?” email after the user already converted. The card credits revenue correctly (last-touch within 7 days), but the workflow’s open-rate looks artificially low because of those late-firing sends. - Workflow-trigger vs send-time attribution conflict surfaces here. A buyer who received a
02_trial_to_paid_nurtureemail AND a Marketing-Hub campaign-send AND a Sales-rep one-to-one in the 7 days before purchase has the order attributed to whichever fired last. The same purchase shows up inEmail-Attributed Commerce Revenue(campaign attribution) and in this card (workflow attribution), but only one wins last-touch credit. Reconcile by adding the two cards: total marketing-attributed revenue should not exceed total commerce revenue.
Sibling cards merchants should reference together
This is the workflow-attribution slice of HubSpot’s commerce revenue picture. Pair with these to triangulate:Reconciling against the vendor’s own dashboard
Where to look in HubSpot: HubSpot does not natively show per-workflow commerce revenue; it knows what its workflows fire and what its emails open, but commerce-order data lives in a different system. Closest individual views:HubSpot → Automation → Workflows → (workflow) → History (per-workflow enrolment + action history) HubSpot → Reports → Analytics tools → Marketing email (per-email send/open/click) Stripe Dashboard → Reports → Net Volume / Shopify Admin → Analytics → Sales (commerce-side revenue)The merchant traditionally reconciles by exporting workflow-enrolment history, exporting commerce orders, and joining on email; this card automates that nightly per workflow. Why our number may legitimately differ from the merchant’s expectation:
Cross-connector reconciliation:
This card IS the cross-connector view (HubSpot workflows × commerce orders). The natural triangulations:
Known limitations / merchant FAQs
Why does my workflow show 186,000 from the same audience? Two attribution models. This card credits a workflow only when the workflow’s last-action fired within 7 days BEFORE the order. Shopify counts every order from that audience regardless of marketing touch. The 95% gap is mostly buyers who would have purchased anyway (organic return) plus buyers who were touched by a different channel in the 7-day window. The honest measure of incremental workflow value is a holdout test: suppress 10% of the workflow’s audience for 30 days and compare conversion. My workflow ran 12,600 enrolments and only 86 buyers, that is 0.68% conversion, what is wrong? Conversion rate alone is the wrong lens. Look at 112 AOV produces 0.77 per enrolment is below your audience-fatigue threshold, retire or shorten the workflow. For top-of-funnelsubscriber_welcome workflows, $0.77 per enrolment is normal; for bottom-of-funnel cart-abandon workflows, it is failing.
Vendor discrepancy with HubSpot’s own dashboard, who is right?
HubSpot’s dashboard shows workflow performance (enrolments, action-completions, email opens, email clicks) but does NOT show commerce revenue per workflow. There is no vendor number to be wrong about. This card is the missing report; the merchant has historically reconciled it manually with CSV exports.
List-segment refresh lag, does it affect this?
Yes meaningfully. Workflows triggered by list-membership inherit list-refresh lag (15-60 minutes for active lists, longer for static). Buyers who become eligible for the workflow but purchase before the workflow enrols them are not credited. This biases attributed revenue downward for list-triggered workflows; event-triggered workflows (form-submit, deal-stage-change) are largely lag-free.
Lifecycle-stage definitions, do they affect this card?
Indirectly. Workflows that branch on lifecyclestage will fire different actions depending on stage; if a stage-backfill happens during the window, the action-history changes mid-period. The card sums total revenue per workflow regardless of which branch fired, so the top-level number is stable; per-action breakdown drilling can look noisy on backfill days.
Multi-portal aggregation, how does it work?
One card per portal. Workflows in portal B do not appear in portal A’s card. If the merchant runs a primary marketing portal plus a sandbox portal, only the primary should be wired into commerce; the sandbox card will be empty or contain test data. For agencies running multi-region portals, expect each region’s card to surface its own top-revenue workflows.
Workflow-trigger latency vs send-time, what does this card measure?
The card uses workflow_action_completed_at (send-time, not trigger-time). A workflow triggered at 09:00 that fires its email at 09:14 has the action-completion timestamp at 09:14; that is the anchor for the 7-day window. Trigger-time is irrelevant for attribution; what matters is when the contact was actually touched.
Today-volatility, why does this swing?
Workflows fire continuously; commerce orders fire continuously. The card refreshes daily. Day-to-day swings of 5-15% are normal because a single $50k deal closing today via a 01_post_demo_followup workflow shows up in tomorrow’s reading. The 90D rolling window smooths most of this; sub-weekly trend reading is noisy and should be ignored.
Action playbook on workflow under-performance:
- Sort workflows by
$ per enrolmentascending; the bottom 5 are candidates for review. - For each, check enrolment volume; high-volume low-$ workflows are the audience-fatigue risk.
- For each, check whether the workflow’s last action is “send-email” or just a property-set; property-set-only workflows often shuffle data without driving revenue.
- A/B test: shorten the workflow to half its current length, or replace the email creative.
- Re-baseline after 30 days; if $ per enrolment doubles, the change paid off.