Elementor forms and submissions: where entries go and who reads them

The Elementor Form widget is convenient in a way that is easy to underrate. The form is built in the same editor as the page it sits on, styled with the same controls as everything around it, and published without touching a second plugin. For a landing page with a short enquiry form, there is very little reason to reach for anything else.

Where it gets interesting is the word "submissions". Elementor stores entries in the WordPress database and gives them a screen, but the behaviour of that screen, and whether it is available at all, depends on which plan a site is on. That detail decides more than most feature comparisons do, so it is worth getting straight before deciding what to change.

The plan line runs straight through submissions

The Form widget is a Pro widget. It is not in the free Elementor plugin, so a site with the free build has no form at all from Elementor itself. Beyond that, the plans differ in a way that matters here.

On Essential, the Form Builder is included but form submissions are not. Elementor's own pricing page states it plainly: the Form Builder entry for Essential says forms submissions are not available in this plan, while the same entry on Advanced Solo and above adds that entries can be managed and analysed from one central dashboard in WordPress.

The practical effect is that the cheapest Elementor plan gives a form that emails you and stores nothing. If the email is lost, misfiled, or caught by a spam filter, the submission is gone. That is a meaningful difference for about two dollars a month, and it is the single most common surprise people hit with Elementor forms. Prices shown as billed annually may include a promotional first year, so the renewal figure is worth checking at the point of purchase.

Building the form inside the editor

The widget is worth describing accurately, because a fair share of complaints about Elementor forms are really complaints about not knowing where a control lives.

Dropped on the canvas, the widget creates a form with three fields: Name, Email and Message. Fields are added either by clicking the copy icon on an existing field, which duplicates it with its settings intact, or by clicking Add Item for a blank one. Each field has a Label, a Placeholder, and a Type, and the type does the validation work: setting a field to email means the browser will only accept a valid address rather than leaving that check to a plugin setting somewhere else.

Layout is handled per field rather than per row. Every field has a Column Width, so putting a first name and a last name side by side is two fields set to 50 per cent, not a row container. That is the control people hunt for longest, and it explains why forms built quickly tend to come out as one field per line.

Elementor's documentation describes the outcome in one sentence that is worth holding on to: submissions can either be sent to the website database or as an email. Those are two separate destinations configured as separate actions, and a form can do both, one, or neither. Collect Submissions writes to the database. Email sends the notification. Turning one off does not affect the other, which is why a site can quietly be emailing results without storing them, or storing results without telling anybody they arrived.

The Essential plan also carries 57 Editor Pro widgets against 85 on Advanced Solo and above, and Popup Builder, custom code and CSS, and the eCommerce widgets sit on the Advanced side. A form that is meant to appear in a popup, or to feed a checkout, is therefore an Advanced-tier decision for reasons that have nothing to do with the form itself.

Where entries actually live and how to get at them

On a plan that includes submissions, the mechanism is straightforward. Collect Submissions is an action in the Actions After Submit field on the widget, and Elementor's documentation states it is active by default. As long as it appears in that field, entries are written to the site's own database.

They are read at Elementor then Submissions in the WordPress admin. The screen lists every submission across every form on the site, and clicking one opens the detail of that entry. Two export routes exist: Export All to CSV, which downloads the whole list, and Export Selected to CSV, which downloads only the rows you have ticked.

There is also a switch that turns the whole thing off. Elementor then Settings then Advanced has a Form Submissions option that can be set to Disable, which stops collection site-wide. That is worth knowing in both directions. It is the setting to check when submissions have stopped appearing for no obvious reason, and it is the setting to use deliberately on a form that must not retain personal data after the notification has gone out.

Because entries are rows in your own database, they are covered by whatever backup regime the site already has, and they are not sitting on a third party's servers. For sites with a data residency requirement, that is often the deciding factor.

The notification email is the weak link

Elementor's own documentation is candid about this, and the warning appears on both the Form widget page and the submissions page. When a form is submitted, two notification emails are commonly sent, one to the respondent as confirmation and one to the site owner. Those emails may end up in a spam folder, and the documentation notes that providers such as Gmail have become increasingly strict about reputation and authentication. Elementor's recommended fix is to route site mail through a dedicated sending service rather than the hosting server.

That is the correct advice, and it is worth acting on before anything else on this list, because the failure mode is silent on both sides. The respondent does not receive an acknowledgement and assumes the form is broken. The site owner does not receive an alert and assumes nothing came in. The entry is sitting in the Submissions screen the whole time, unread.

There is a second-order point here too. If the notification email is the thing people actually work from, and the Submissions screen is only a backup, then the reliability of the whole process rests on mail delivery. Turning that around, so the screen is where work happens and email is the notification, is a change in habit more than a change in software, and it is usually the cheapest improvement available.

What the Submissions screen does not carry

The screen is a well-made record of what arrived. It is not a place to run work, and the gap is specific rather than vague.

There is no owner on a submission. Nothing in the row says which member of staff picked it up, so on a team of three that fact lives in a chat message. There is no status beyond read and unread. A submission answered yesterday and one that has been sitting for a week look the same in the list, which means the question "what is still outstanding" cannot be answered from the screen.

Most of all, there is no record of the reply. The acknowledgement is an automated email configured on the widget. The actual answer, written to a particular person about a particular detail, is composed in a mail client, and once it is sent the only copy is in one person's sent folder. The submission in WordPress has no idea the conversation happened. Six weeks later, when that person replies asking about what they were told, the history has to be reassembled from two systems by someone who may not have been party to either.

None of this is a flaw in the widget. A page builder that also collects form entries and lets you export them has done more than it strictly needed to. It is a boundary, and naming it is more useful than looking for a setting that does not exist.

The CSV workaround and when it stops working

The usual response is to export to a spreadsheet and add owner and status columns there. For a short campaign with a fixed close date this is a perfectly reasonable answer, and pretending otherwise is not helpful.

It comes apart in two predictable ways. The export is a snapshot, so the sheet and the Submissions screen drift the moment anything new arrives, and within a fortnight there are two versions of the truth with no rule about which wins. And the person who owns the row still writes the reply elsewhere, so the sheet records that something was handled without holding what was said. When the sheet starts generating questions instead of answering them, that is the signal to change the shape of the process rather than the columns.

Counting the cost on the axis that decides it

Elementor's pricing grows with the number of sites. Essential and Advanced Solo cover one site, Advanced covers three, Expert covers twenty-five. Nothing on the pricing page counts submissions, and nothing counts people.

For a single site with a team reading the entries, the first row is close to ideal, and the licence you are already paying for a page builder covers the form as well. That is a genuine argument for staying put.

The case for moving is not about cost. It is that a submissions table inside a page builder is the wrong shape for a queue, and that mismatch gets worse as the proportion of submissions requiring a written reply goes up. Which shape is right depends on the intake, so it is worth reading the use cases that match yours and watching a demo rather than comparing feature lists, because the difference shows up in how a response is handled, not in how a form is built.

What to change first

Two things, in order. Put site mail through an authenticated sending service today, because a lost acknowledgement costs more than anything else on this page and the fix takes an afternoon. Then count last month's submissions against the number of replies a person typed by hand. If those numbers are close, the form is fine and the handling is the bottleneck, so keep the owner, the status and the reply on the response itself rather than in three places, and judge candidates on how they price access against the number of people who genuinely need it, which is the axis Halict is built around.

Q1. Where are Elementor form submissions stored?

They are written to the WordPress site's own database when the Collect Submissions action is present in the Actions After Submit field, which is the default. They are read at Elementor then Submissions in the WordPress admin, and they can be exported with Export All to CSV or Export Selected to CSV.

Q2. Why can I not see a Submissions screen on my plan?

The Essential plan includes the Form Builder but not form submissions, so on that plan a form emails the result and retains nothing. Advanced Solo and above add the central dashboard in WordPress where entries are listed and exported. It is also worth checking Elementor then Settings then Advanced, where Form Submissions can be set to Disable site-wide.

Q3. Do Elementor forms work on the free plugin?

No. The Form widget is a Pro widget, so a site running only the free Elementor plugin has no Elementor form to build. Sites in that position either upgrade or use a separate form plugin alongside Elementor.

Q4. Why do Elementor form notification emails go to spam?

Elementor's own documentation raises this and points at authentication and sender reputation, noting that providers such as Gmail have become stricter. Mail sent directly from a hosting server without a properly authenticated sending path is the usual cause, and routing site mail through a dedicated sending service is the recommended fix.

Q5. Can two people handle Elementor submissions without duplicating work?

Not from the screen itself. A submission has no owner field and no status beyond read and unread, so nothing in the record says who took it or whether it has been answered. Teams coordinate in chat instead, which holds at low volume and breaks once entries arrive faster than someone is watching.