Elementor 4.2 adds Email 2 as an independently configured Atomic Forms action. A submission can save successfully while the primary email, secondary email, attachment handling, CRM action, or conversion event fails. Treating the form as one boolean result can hide the branch that needs repair or trigger duplicate retries.
Use this for Elementor Pro sites sending a submitter confirmation plus an internal alert, especially when attachments, CRM actions, and paid-media conversions share the workflow.
Quick answer
Create one synthetic submission ID and track each action separately. Record recipient class, subject, attachment path and size, MIME type, generated message ID, WordPress mail result, provider event, CRM record, conversion ID, retry action, and customer-visible outcome. Retry only the failed branch with the same submission identity. Do not resubmit the form or repeat CRM and conversion actions merely because Email 2 failed.
What to check first
- Record Elementor and Pro versions, form ID, action order, Email 1, Email 2, attachment generation, mailer, provider, CRM, conversion, and owners.
- Create valid, missing, unreadable, oversized, disallowed MIME, temporary-path, provider-rejected, and duplicate-retry attachment fixtures.
- Capture one submission ID across entry storage, each email action, message ID, attachment result, provider event, CRM row, and conversion event.
- Test primary success with secondary failure, secondary success with primary failure, attachment-only failure, and provider partial acceptance.
- Define whether each branch retries, alerts, compensates, or closes without repeating successful downstream actions.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the submission and per-action outcome graph. | Record Elementor and Pro versions, form ID, action order, Email 1, Email 2, attachment generation, mailer, provider, CRM, conversion, and owners. | Each form submission produces one stable entry identity. |
| Repair attachment generation, timing, MIME, size, permissions, or provider policy at the failing branch. | Create valid, missing, unreadable, oversized, disallowed MIME, temporary-path, provider-rejected, and duplicate-retry attachment fixtures. | Email 1 and Email 2 have distinct message and provider evidence. |
| Retry only the failed email action with the original submission identity. | Capture one submission ID across entry storage, each email action, message ID, attachment result, provider event, CRM row, and conversion event. | Attachment failures are visible without exposing file contents or personal data. |
| Prevent successful CRM, conversion, and email actions from repeating. | Test primary success with secondary failure, secondary success with primary failure, attachment-only failure, and provider partial acceptance. | Branch retries do not duplicate CRM rows, conversions, or successful messages. |
Why this usually happens
- Form entry, email actions, attachment generation, providers, CRM, and tracking have separate success states.
- Temporary files can disappear before a queued email reads them.
- A generic form retry can repeat actions that already succeeded.
- Provider acceptance and WordPress mail return values are not the same as final delivery.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
submission,action,recipient,attachment,message_id,wp_mail,provider,crm,conversion,retry,result
EF-22,email-1,internal,none,M-101,true,delivered,C-88,E-88,none,pass
EF-22,email-2,submitter,missing,none,false,none,C-88,E-88,branch-only,fail
EF-22,email-2-retry,submitter,valid,M-102,true,delivered,C-88,E-88,closed,pass
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Both emails pass | Small valid PDF | Two distinct message IDs |
| Email 2 attachment fails | Unreadable temporary file | Entry and Email 1 stay successful |
| Provider rejects Email 1 | Valid Email 2 | Retry primary branch only |
| Duplicate retry | Same submission ID | No duplicate CRM or conversion |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze the submission and per-action outcome graph.
- Repair attachment generation, timing, MIME, size, permissions, or provider policy at the failing branch.
- Retry only the failed email action with the original submission identity.
- Prevent successful CRM, conversion, and email actions from repeating.
- Retest both emails, provider delivery, CRM, conversion, and customer outcome.
Decision rule
Close the submission only when every required action has an explicit final state. Retry a failed email branch without recreating the entry, CRM record, conversion event, or email that already succeeded.
Production verification checklist
- Each form submission produces one stable entry identity.
- Email 1 and Email 2 have distinct message and provider evidence.
- Attachment failures are visible without exposing file contents or personal data.
- Branch retries do not duplicate CRM rows, conversions, or successful messages.
Field notes
- Use synthetic recipients and harmless attachment content.
- Do not store attachment content in shared logs.
- Keep one stable submission and conversion identity through branch retries.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, caches, providers, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix Elementor form email delivery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references