Olmec Dynamics
H
·8 min read

How to Create Shopify Return Requests From Google Forms Using Make.com and Shopify

Automate Shopify return requests from Google Forms using Make.com and the Shopify Returns API, validate submissions, map return items, and alert exceptions to Slack.

Introduction

Returns are one of the handful of merchant tasks that still end up as manual admin: a customer fills a form, someone reads the email, finds the order in Shopify, and opens the admin to start a return. That creates delay, mistakes in line-item selection, and no consistent audit trail.

This guide shows how to accept return requests via Google Forms (or the sheet behind it), validate and normalise the submission in Make.com, then create a programmatic Return object in Shopify using the Admin API. You will end up with an auditable, idempotent pipeline and clear exception routing to Slack so your ops team only touches the edge cases.

What you will know by the end: the exact Make.com modules to use, the fields to capture in Google Forms, how to map return lines to Shopify order lines, and how to handle the common gotchas in production.

What You'll Need

  • A Google Form and the linked Google Sheet to collect return requests
  • A Shopify store, Admin API access (private app or OAuth), and permission to create Returns via the Admin API (GraphQL Return object, API version 2026-01 or later recommended)
  • A Make.com account to orchestrate (paid plan recommended for production retries and webhooks)
  • A Slack workspace and channel to post exception alerts
  • Optional: a Google Sheets audit log or Make.com Data Store for idempotency keys

Notes on Shopify API: Shopify models returns as a Return object in the Admin GraphQL API. The 2026-era API adds return reason definitions; use the Return mutation and include reason ids when your workflow requires it. See Shopify developer docs for the latest fields.

How It Works (The Logic)

Trigger: new Google Form response or new row in the response Google Sheet. Make.com parses the submission, validates required fields (order number or order id, email, at least one return line with quantity and SKU or line item id), then looks up the target Shopify order to match line items. If the submission passes validation and line-items are matched, Make.com calls Shopify's Return creation endpoint (GraphQL Admin API Return create/returnRequest mutation) to create the return request, then writes a row to an audit sheet and optionally notifies the customer via email. If anything is missing or a line cannot be matched, Make.com writes a detailed exception row and posts a Slack alert for manual review.

In short: Form → Make.com (validate, dedupe, enrich) → Shopify Return create → Audit row + optional notifications. Exceptions route to Slack.

Step-by-Step Setup

  1. Design your Google Form and Sheet

Collect the minimum data so the automation can act without manual lookup:

  • Order number (required) or Shopify Order ID
  • Customer email (optional but useful)
  • Return reason (picklist)
  • For each return line: SKU or product handle, quantity, and optional note
  • Whether refund or exchange is requested
  • Preferred resolution (refund, exchange, store credit)

Practical tip: keep line items as a repeatable block in the form if supported, otherwise accept a simple CSV-style field like SKU:QTY;SKU2:QTY2 and parse it in Make.com.

  1. Create the Make.com scenario and Google Sheets trigger

Module 1: Google Sheets, Watch Rows (or Google Forms Watch Responses if you prefer the direct connector)

  • Point at the Responses sheet. Use the specific view or tab Google Forms writes to.
  • Fetch the new row payload, including the raw line-items field.
  1. Idempotency and early dedupe

Module 2: Make.com Data Store or Google Sheets lookup

  • Use a deterministic key such as form_response_id or a composite order_number + timestamp from the row.
  • If an entry with that key exists and status equals processed, stop the scenario. This guards against retries and accidental re-submits.
  1. Normalize and validate inputs

Module 3: Tools / Set Variables

  • Trim and normalise order number, lower-case email, parse the line items into an array of objects {sku, quantity, note}.
  • Validate: order number present, at least one line with numeric quantity > 0, resolution chosen.
  • If validation fails, route to the exception path (see step 8).

Gotcha: customers sometimes enter the order number with or without the leading #. Normalise to the exact format your Shopify store uses.

  1. Lookup the Shopify order and match line items

Module 4: Shopify module or HTTP GraphQL call

  • Search orders by order number or order id. Use the Admin REST or GraphQL API to fetch order line items with their ids, SKUs, quantities and remaining refundable quantity.
  • For each requested return line, try to match by SKU first, fallback to product title or line item id if provided. Match conservatively: if requested quantity exceeds available quantity, cap at available and flag for manual review.

Mapping note: keep a mapping function that returns the Shopify order's line_item_id for each request row. If one or more lines cannot be matched exactly, send to exception path.

  1. Build the Shopify Return payload

Module 5: Tools / JSON builder

  • Build the Return input according to Shopify's API. For GraphQL, prepare the ReturnLineItems array that contains references to the order's line item ids and the return quantity, plus the return reasons (use the latest return reason ids if your process requires them).
  • Include refund or exchange intent as part of the return request payload.

Example return payload (conceptual): { "orderId": "gid://shopify/Order/12345", "returnLineItems": [ { "orderLineItemId": "gid://shopify/OrderLineItem/111", "quantity": 1, "reasonId": "gid://shopify/ReturnReasonDefinition/42" } ], "notifyCustomer": false }

  1. Create the Return in Shopify

Module 6: Shopify GraphQL (HTTP request) or Make Shopify connector

  • Call the appropriate mutation (ReturnCreate or similar). Use your Admin token in the Authorization header.
  • On success, capture the returned return id, status, and any refund id if Shopify processed a refund.
  • After success, write an audit row into Google Sheets or the Make.com Data Store with: form_response_id, shopify_order_id, return_id, action_taken, timestamp, and raw Shopify response.

Gotcha: Shopify return flows can be synchronous or require follow-up steps (for example issuing a refund). Decide whether your automation will call the refund mutation or leave refunds to finance.

  1. Exception path: handle mismatches and missing data

Module 7: Google Sheets append row + Slack alert

  • If you could not match lines, or validation failed, append a row to an exceptions sheet with full context (form row, parsed lines, reasons) and post a detailed Slack message to the returns ops channel including the sheet row link and the run id.
  • Keep the Slack message actionable: include the order search link in Shopify admin and the parsed lines so the operator can correct quickly.
  1. Optional: automated refund or label creation

If your business rules allow, add a conditional step after Return creation to call Shopify refund APIs or create a fulfillment return label via your shipping provider. Keep these behind a confirmation gate for higher-value returns.

  1. Post success notification and close the loop
  • If the return was created and any follow-up steps succeeded, optionally send a confirmation to the customer email (use your transactional email provider), update the Google Form response row with processed and the return id, and post a short success message to an internal Slack channel for visibility.
  1. Test thoroughly with edge cases

Test cases to run before you go live:

  • Valid return: single SKU, quantity within ordered quantity
  • Over-quantity request: customer asks for more than ordered quantity (cap and flag)
  • SKU mismatch: form SKU doesn't exist on order (should go to exception)
  • Multiple line items in one submission
  • Duplicate submission (idempotency check)

Real-World Business Scenario

A mid-volume Shopify store uses Google Forms to capture returns from a customer portal. Before automating, an ops person read each submission, looked up the order, and opened the admin to create the return. After automating with Make.com the store did Tier-1 automation for returns that matched perfectly (same SKU, quantity in range). These went straight into Shopify as Return objects and created a refund id where rules allowed. Edge cases were routed to a Slack returns queue with a link to the exception row and the Shopify order, which reduced manual triage time and kept the store within its refund SLA.

Common Variations

  • Trigger source: swap Google Forms for a return request page, a Shopify returns app, or a dedicated returns inbox parsed by Make.com.
  • Human approval gate: create the Return in draft and post a Slack approval with Approve/Reject buttons before issuing refunds.
  • Auto-generate shipping labels: after Return creation call your shipping provider API (or ShipStation) to create a prepaid label and include the label link in the customer notification.

Where this fits your stack

This pattern sits between simple form intake and a full RMA system. It gives you the reliability of programmatic returns (Shopify Return objects) while keeping human review for anything ambiguous. If you need deeper routing into ShipStation, Monday.com, or BigQuery for analytics, you can reuse the same Make.com approach we use in other flows like How to Automatically Sync Shopify Orders to Google Sheets and Slack Using Make.com or our ShipStation → Monday.com pattern.

If you want this implemented and hardened for your operation — including reason-id mapping for Shopify's 2026 Return Reason Definitions and sensible idempotency — Olmec Dynamics builds these automations for businesses and supports runbooks and monitoring. See what we do at https://olmecdynamics.com