Elementor 4.2 adds Email 2 to Atomic Forms with independent recipient, subject, and message settings. A second message is useful for submitter confirmation and internal routing, but duplicate hooks, shared actions, retries, CRM connectors, and conversion scripts can turn one submission into two leads or two ad conversions.
Use this for Elementor Pro sites, agencies, email operators, CRM teams, paid media owners, and support teams deploying Atomic Forms Email 2.
Quick answer
Assign one stable submission ID before any action runs. Give Email 1 and Email 2 distinct action IDs, recipient classes, Message-IDs, templates, attachments, retry state, and provider IDs. Create CRM and conversion events once from the submission outcome, not once per email action. Test success, one action failing, provider defer, retry, invalid recipient, attachment error, redirect, consent denied, and duplicate browser submit.
What to check first
- Record Elementor, Elementor Pro, Atomic Forms, mailer, provider, CRM, webhook, consent, analytics, and conversion integration versions.
- Document Email 1 and Email 2 recipients, subject, message, reply-to, attachments, conditions, and expected business purpose.
- Generate stable submission, action, Message-ID, provider, CRM record, and conversion event identifiers for one synthetic fixture.
- Test both actions successful, primary failure, secondary failure, defer, bounce, retry, attachment failure, invalid recipient, double click, and redirect.
- Reconcile form result, entry, two email state machines, provider delivery, one CRM row, one lead or conversion event, and visible success or error feedback.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create stable submission identity before Atomic Forms actions run. | Record Elementor, Elementor Pro, Atomic Forms, mailer, provider, CRM, webhook, consent, analytics, and conversion integration versions. | Email 1 and Email 2 have distinct configuration, identifiers, delivery evidence, and owners. |
| Assign distinct email-action and provider identities to Email 1 and Email 2. | Document Email 1 and Email 2 recipients, subject, message, reply-to, attachments, conditions, and expected business purpose. | Each failure and retry branch stays inside its own action state machine. |
| Create CRM and conversion outcomes once from the accepted submission. | Generate stable submission, action, Message-ID, provider, CRM record, and conversion event identifiers for one synthetic fixture. | One accepted submission creates one CRM row and one conversion outcome. |
| Make each email retry idempotent without replaying downstream business events. | Test both actions successful, primary failure, secondary failure, defer, bounce, retry, attachment failure, invalid recipient, double click, and redirect. | Success, error, accessibility feedback, consent, and redirect behavior remain correct. |
Why this usually happens
- Plugins and integrations can attach downstream work to every email action instead of the submission.
- Independent actions may retry on different schedules.
- A redirect can occur before the slower action records its final status.
- Provider and WordPress identifiers are often missing from the same evidence bundle.
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_class,message_id,provider_id,delivery,crm_id,conversion_id,result
AF-91,email_1,internal,msg-1,prv-1,delivered,CRM-44,CV-91,pass
AF-91,email_2,submitter,msg-2,prv-2,delivered,CRM-44,CV-91,pass
AF-92,email_2,submitter,msg-4,prv-4,deferred,CRM-45,CV-92,observe
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 actions pass | Internal alert and submitter receipt | Two messages, one CRM lead, one conversion |
| Email 2 fails | Invalid confirmation recipient | Internal alert remains traceable and failure is visible |
| Provider retry | One action deferred | Stable Message-ID and no duplicate CRM |
| Double submit | Browser repeats request | One accepted submission identity |
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.
- Create stable submission identity before Atomic Forms actions run.
- Assign distinct email-action and provider identities to Email 1 and Email 2.
- Create CRM and conversion outcomes once from the accepted submission.
- Make each email retry idempotent without replaying downstream business events.
- Expose partial failure to operations and retest the exact action branch.
Decision rule
Release only when one accepted submission produces the intended two email outcomes, one CRM record, one conversion event, clear partial-failure evidence, and no duplicate result during retries or browser repeats.
Production verification checklist
- Email 1 and Email 2 have distinct configuration, identifiers, delivery evidence, and owners.
- Each failure and retry branch stays inside its own action state machine.
- One accepted submission creates one CRM row and one conversion outcome.
- Success, error, accessibility feedback, consent, and redirect behavior remain correct.
Field notes
- Use synthetic inboxes and no real lead data.
- Keep email action IDs separate from the submission and conversion IDs.
- Do not report overall success when one required recipient path failed silently.
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 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 preserving exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, providers, caches, 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, audit Elementor Atomic Forms email delivery.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Separate attachment and delivery failures by action
Extend Email 2 testing with the Elementor 4.2 secondary-email attachment partial-failure test so one failed branch can retry without duplicating entries, CRM records, conversions, or successful messages.
Lease attachments across both email actions
Add the Elementor 4.2 Email 2 attachment queue-lease test so temporary files survive delayed consumers and retries cannot duplicate recipients that already succeeded.
Helpful references