Multi-Step Elementor Forms in Google Sheets

Elementor Pro multi-step forms only trigger one server-side action by default: elementor_pro/forms/new_record. That action fires once, on the final step, after the user clicks the submit button on the last page of the form. Every interim step before that is purely client-side. Elementor stores the values in a JS object and only POSTs the full payload when the user reaches the end.

This matters because most plugins that claim to capture multi-step data are really just hooking new_record and writing the final payload to a sheet. That works fine if the user finishes. It does nothing for the 40-60% of users who drop off mid-flow.

To capture partial submissions you need a second mechanism: a client-side hook on elementor_pro/forms/next-step that fires every time the user advances. We will wire that up later in the post. First, get the happy path working through SheetLink's Elementor Pro form integration guide so you have a known-good baseline before adding complexity.

Elementor lets you set both a Label and a Field ID for every input. The Label is what users see. The Field ID is what gets posted to $_POST when the form submits. Most users leave the Field ID blank, in which case Elementor auto-generates something like field_a1b2c3.

That auto-generated ID is fragile. Delete the field and re-add it, you get a new random ID. Duplicate the form, same problem. SheetLink maps on Field ID by default because labels are not unique (you can have two fields both labeled "Email" in different steps).

The fix is to set explicit, semantic Field IDs the moment you build the form: email, company_name, step1_role. Treat them like database column names. Once mapped in SheetLink, you can rename the user-facing label freely without breaking the sync. We have seen teams lose two weeks of data because someone duplicated a form for a campaign and forgot the IDs reset, so this is not theoretical.

Once you are capturing both new_record (completed) and next-step (partial) events, you need somewhere to put them. Dumping both into one sheet creates noise. The cleaner pattern is two tabs in the same spreadsheet, or two separate sheets entirely.

SheetLink's conditional routing handles this without code. Create one rule for completed submissions targeting Sheet1!Completed, and a second rule for partials targeting Sheet1!Abandoned. Add a condition like event_type == "partial" to the second rule and the router does the rest.

The Apps Script receiver should also be aware of the difference. A minimal handler:

function doPost(e) {
  var body = JSON.parse(e.postData.contents);
  var sheetName = body.event_type === 'partial'
    ? 'Abandoned'
    : 'Completed';
  var sheet = SpreadsheetApp
    .getActive()
    .getSheetByName(sheetName);
  sheet.appendRow([
    new Date(),
    body.session,
    body.step || 'final',
    JSON.stringify(body.fields)
  ]);
  return ContentService.createTextOutput('ok');
}

For teams running follow-up campaigns, the Integrations Bundle can fan the same payload to Mailchimp, HubSpot, or Slack in parallel. That removes the need for Zapier sitting in the middle.

Three issues account for roughly 80% of Elementor-to-Sheets support tickets we have seen. Walk through them in order before opening a deeper investigation.

• Empty fields in the sheet: almost always a Field ID mismatch. Open the form in Elementor, click each field, and confirm the Field ID matches what SheetLink shows in the mapper. If you renamed a field, re-run "Detect Fields" in the sync rule.
• Submissions reach WordPress but not the sheet: the Apps Script web app deployment is wrong. It must be deployed as a Web App (not just saved), with execution as "Me" and access as "Anyone". Re-deploy after every code change, the URL stays the same but the version increments.
• Conditional fields never appear in the sheet: they are likely hidden by Elementor conditional logic AND have "Submit empty values" disabled. Either flip that toggle or add the column on the SheetLink side with a static default.

Turn on SheetLink's debug log under Settings, then Logs, to see the exact JSON payload Elementor posted. That single screen resolves more issues than any documentation page.

Here is the setup we use internally for a four-step demo request form. Step 1 collects email and company. Step 2 asks team size and use case. Step 3 shows pricing-tier-relevant questions (conditional on step 2 answer). Step 4 confirms and submits.

The sheet has three tabs:

1. Demo Requests: populated by new_record. One row per completed submission, all 12 fields mapped explicitly.
2. In Progress: populated by next-step. One row per step advance, keyed on session ID. Sales reviews this daily for warm leads who started but did not finish.
3. Audit: raw JSON dump of every payload, useful for debugging schema changes.

A Google Sheets formula in the Demo Requests tab reconciles against the In Progress tab and marks abandoned sessions as "recovered" once a matching email shows up as completed. That gives the team a single dashboard for completion rate by step, average time per step, and which step loses the most users. None of it requires Zapier, none of it leaks PII outside Google's infrastructure, and the whole stack runs on a one-time SheetLink license.