Gravity Forms Emma - WordPress Plugin

Guide to Setting Up Gravity Forms Emma for WordPress Forms and Email Campaigns

Gravity Forms Emma is not about making a form look nicer on the page. Its real job is connecting an existing form to Emma email marketing. In this guide, we will walk through how to prepare a WordPress site, connect Emma API credentials, create a feed for a specific form, map fields, enable double opt-in, verify the result, and understand why a subscriber may not end up in the right group.

This guide is intended for a site owner, marketer, or WordPress administrator who already uses Gravity Forms and wants to send form data to Emma without manual exports. It does not cover license purchases or activation workarounds. The focus here is setup, feed logic, submission validation, and safe troubleshooting.

The core idea is simple: the form collects data on the site, Gravity Forms stores the entry, and the Emma feed decides whether that specific submission should be sent to the selected Emma group. When that chain is configured carefully, you can collect subscriptions, segment interests, send additional fields, and avoid adding people to your mailing list if they never gave consent.

What Problem the Form-to-Emma Connection Solves

Gravity Forms handles the form itself: fields, required field validation, notifications, user confirmation, and entry storage in WordPress. Emma handles audiences, groups, subscribers, campaigns, and ongoing work with email data. The add-on connects those two layers so that after a successful form submission, the data can be sent to the appropriate Emma group.

This is especially useful when the site already uses forms for inquiries, event registrations, content downloads, consultations, or general contact requests. Instead of building a separate signup form, you can add newsletter consent to an existing workflow. The user submits a request, checks the consent box, and the feed sends the email address and extra fields to Emma.

Where This Integration Delivers the Most Value

The best use case is a form that collects more than just an email address. For example, service type, topic of interest, city, user role, budget, attendance format, or lead source. You can map that data to Emma custom fields and then build more precise groups and campaigns later.

• Consultation lead form. The user selects a service of interest, and the feed sends their email, name, and selected topic to Emma.
• Event registration. The form collects a name, email, participation format, and newsletter consent, while Emma receives the subscriber in a separate event group.
• Content download form. The visitor gets access to a checklist or presentation, and the marketer can see what the subscriber was interested in.
• Segmented subscription. One general signup widget sends users to different groups based on the topic they choose.

A weak use case is a basic contact form with no newsletter consent and no broader email strategy behind it. In that case, the integration may create unnecessary risk: the user submitted a question but did not expect to be subscribed. It is better to think through the consent language first and only then enable the Emma connection.

Who Gravity Forms Emma Is a Good Fit For, and When Another Approach Makes More Sense

This add-on works well for sites where Gravity Forms is already the main form tool and Emma is the email platform in active use. The biggest strength of this setup is not "yet another signup form," but the ability to build subscriptions into real WordPress forms and send application context into Emma.

When the Plugin Is a Good Fit

Gravity Forms Emma fits naturally into workflows where marketing and the website need to work together. If the team already stores its audience in Emma and uses subscriber groups and fields, a Gravity Forms feed removes the need for manual imports after every campaign.

• The site has multiple forms, and each form may need to send subscribers to a separate Emma group.
• The marketer cares about custom fields, not just the email address.
• You need double opt-in so the subscriber confirms their address before being added to a group.
• You need conditional logic, for example, to send only users who checked the consent box to Emma.
• The administrator wants to stay inside the standard Gravity Forms interface without external automation builders.

When the Integration May Be Unnecessary

This plugin does not solve every email marketing problem. It does not replace your campaign strategy, clean your list, fix poor deliverability, or make your form legally compliant. It only sends data from a form to Emma according to the feed rules.

If the site uses another email platform, it is better to look for that platform's official add-on. If you need to send one form to dozens of different services at once, Zapier or Webhooks may be a more practical option. If you only need local lead collection without email marketing, standard Gravity Forms entries and notifications are enough.

Practical rule of thumb: install Gravity Forms Emma when the form has a clear marketing role: subscription, segmentation, registration, subscriber profile updates, or sending data to an Emma group. If that role is not clearly defined, design the form and consent flow first.

What to Check Before Installation and Connection

Before installing anything, it is worth doing a short prep pass. It saves more time than it seems: most integration problems do not come from the Add New button itself, but from an incorrect API key, an empty email field, an inactive feed, a condition that never matches, or the expectation that old entries will be sent to Emma retroactively.

Platform and Access

The site must have Gravity Forms installed, along with the Emma add-on itself. The person configuring the integration needs permission to access Gravity Forms settings and the form settings. Gravity Forms documentation for Emma specifically references the gravityforms_emma capability, so on sites with custom roles it is worth verifying administrator or marketing access ahead of time.

On the Emma side, you need the Account ID, Public API Key, and Private API Key. One important detail: the private key is usually shown only when it is created, so it should be stored in a secure secrets manager. Do not paste those keys into public tasks, comments, screenshots, or emails unless there is a real need.

Form Structure

The form must include an email field because the feed needs to know which field should be used as the subscriber's email address. If you want to send name, city, interest, or customer status, add those fields before configuring the feed. That makes it much easier to map them to Emma custom fields and verify that the data arrives in the expected format.

Groups and Fields in Emma

In Emma, prepare the target group and any profile fields you want to populate ahead of time. The feed can create a custom field directly from the settings, but for a working team it is usually safer to agree on the structure inside Emma first. That reduces the chance of ending up with several nearly identical fields such as City, city, and Town.

Consent and Double Opt-In

If the subscription is tied to marketing emails, add a separate consent checkbox to the form. The feed can be limited with a condition so data is sent to Emma only when that checkbox is selected. Double opt-in adds another layer of address verification: the user receives an email from Emma and joins the group only after confirming.

Installation and Initial Authorization in WordPress

After the add-on is installed in WordPress, setup does not begin inside a specific form. It starts on the general Emma settings page within Gravity Forms. That makes sense: the API credentials belong to the Emma account, while the feed is what connects an individual form to a group, email field, custom fields, and conditions.

Where the Emma Connection Settings Are Located

Open the WordPress admin panel and go to Forms -> Settings. You should see an Emma tab in the list of settings tabs. If the tab is missing, check whether the add-on is activated, whether the current user has the right permissions, and whether Gravity Forms recognizes the official add-on in the installed extensions list.

1. Open Forms -> Settings.
2. Go to the Emma tab.
3. Enter the Public API Key, Private API Key, and Account ID.
4. Click Update Settings.
5. Check whether green check marks appear next to the fields.

Those green check marks mean the keys were accepted and the site is ready for feed creation. If they do not appear, do not create a feed and hope for the best. First recheck the account ID, confirm the keys are current, make sure there are no extra spaces, and verify that the keys belong to the correct Emma account or subaccount.

What to Do If the Tab or Settings Are Not Visible

If the site has multiple administrators and custom roles, the problem may be access-related rather than installation-related. To confirm, log in as the main administrator or ask the site owner to enable the Emma capability. If the tab disappeared after an update, check the list of active plugins and the Gravity Forms system status.

Quick summary: before you configure a feed, three things should already be true: the add-on is active, the Emma API keys are saved without errors, and the user has access to Emma settings.

Emma Feed: Group, Email, Fields, and Send Conditions

A feed is the working rule that tells Gravity Forms what to do with an entry after a successful form submission. For Emma, the feed defines the group, email field, custom field mapping, optional double opt-in, and conditional logic. This is where you decide who joins the mailing list and who remains only as a WordPress entry.

Creating a Feed for a Specific Form

Open the target form under Forms, then in the form settings go to Settings -> Emma. Click Add New. Do not create one generic feed "for every situation" if the form supports different workflows. For different groups and conditions, it is usually much easier to create several clearly named feeds.

1. Name the feed so its purpose is still obvious a month from now, for example Newsletter - Product Updates or Event Leads - Webinar.
2. Select the Emma group that subscribers should be added to.
3. Specify the form field that contains the email address.
4. Map custom fields such as name, interest, city, request type, or other useful context.
5. Enable double opt-in if the subscriber must confirm the email address before being added to the group.
6. Enable conditional logic if data should be sent only for a specific answer.

How to Choose the Right Emma Group

The group should reflect the meaning of the subscription, not the technical name of the form. If a "Consultation Request" form includes a checkbox for "Receive updates," the group might be named after the marketing segment, such as "Product updates" or "Webinar leads." If the user is registering for an event, a dedicated event group helps avoid mixing those subscribers into a general newsletter list.

Do not create dozens of groups if the difference can be stored in a custom field instead. The group is for organizing the audience, while fields capture profile details. For example, one "Newsletter" group can use an "Interest" field with values like "Design," "Support," or "Pricing." That is much easier to maintain than creating a separate group for every minor topic.

Mapping Custom Fields Without Creating Chaos

The most common field mapping mistake is sending too much data without a plan. Before configuring the feed, decide which fields will actually be useful in Emma. Name and topic of interest are often valuable. An internal manager note, a technical lead ID, or a long message body usually does not belong in a mailing database.

After saving the feed, submit a test entry. Check more than just whether the subscriber exists. Verify the accuracy of each field. If the value "Marketing" in the form becomes an empty Emma field, the issue is usually the mapping, the custom field name, or the field type.

Segmentation, Consent, and Double Opt-In in a Real Form

In email marketing, technical delivery of the address is only part of the story. Audience quality matters just as much. Gravity Forms Emma gives you three practical controls: group selection, custom fields, and conditional logic. Double opt-in adds user-side address confirmation. Together, they help keep a lead form from turning into a source of accidental or unwanted subscriptions.

The "Subscribe Only with Consent" Condition

Add a checkbox to the form with clear wording. In the feed settings, enable conditional logic and create a rule so the feed runs only when the consent checkbox is selected. That way, the user can submit a request without subscribing, while WordPress still stores the entry and sends the standard notifications.

Do not precheck the consent box if your legal policy requires explicit user action. Do not hide the consent wording in tiny text. The integration should support clear communication, not work around visitor expectations.

When to Enable Double Opt-In

Double opt-in is useful when address confirmation matters and you want to reduce accidental signups. When it is enabled, the user receives an email from Emma and is added to the group only after clicking the confirmation link. That means you may not see an active subscriber in the group immediately after the form is submitted, and that is normal if the confirmation email has not been completed yet.

For forms with high commercial value, double opt-in may reduce some fast signups but improve list quality. For lead forms, it is important to explain in advance that the confirmation email may arrive separately. Otherwise, the marketer may start looking for "missing" subscribers who simply never confirmed their address.

Multiple Feeds for Different Interests

If one form collects different interests, you can create multiple feeds and limit each one with its own condition. For example, one feed sends to the "News" group, another to "Events," and a third to "Product updates." But do not create overlapping conditions without testing them. If the user selects one option, it should be clear which feed runs and why.

For multi-feed setups, keep a simple test table: user response, expected group, expected custom fields, and whether double opt-in is enabled. It is an easy way to catch mistakes before the form goes live.

How to Stay Organized with Groups, Fields, and Multiple Feeds

At launch, it is tempting to build one simple connection: the form sends an email address to a single Emma group. A few weeks later, new scenarios appear: a separate group for a webinar, an interest field for segmentation, a second checkbox for updates, different notifications for managers. If you do not keep things structured from the start, the administrator eventually stops understanding why a specific subscriber ended up in that particular group.

The best way to stay in control is to separate three levels. The Emma group represents the audience or campaign, the custom field stores profile data, and the feed defines the transfer rule from a specific form. Groups should not become a substitute for every small data point. If a user chooses one of ten topics, it is usually more practical to send that topic into a custom field than to create ten nearly identical groups.

Clear Feed Names

A feed name should explain when it runs. A weak name like Emma Feed 1 tells you nothing a month later. It is better to use a format any administrator can read at a glance: form, purpose, condition. For example, Consultation - newsletter consent or Webinar - confirmed interest. It does not affect the API, but it helps a lot during troubleshooting.

If a form has multiple feeds, arrange them according to the workflow: general newsletter first, then the event feed, then a special group if needed. Before publishing, open each rule and check for overlap. A condition like "Interest is not empty" may accidentally send a user to a broader group than intended.

When a Group Is Better Than a Field, and When a Field Is Better Than a Group

A group makes sense when the marketer will actually send a separate campaign to that audience or build campaign logic around that event. A custom field is more useful when the value is meant for personalization and filtering: city, topic of interest, role, participation format, or lead source. That distinction helps keep Emma from turning into a mess.

Before making any change to a live form, run a quick control submission. If you added a new custom field, make sure it is populated for the new subscriber. If you changed the group, confirm that the old feed is not still sending data to the previous audience. That kind of discipline matters more than complex automation.

Practical Example: Lead Form with Newsletter Signup

Let us walk through a typical scenario: the site has a consultation request form. The user enters a name and email, chooses a topic of interest, and can optionally agree to receive updates. We need to store the request in Gravity Forms, send a notification to the manager, and add the subscriber to Emma only when explicit consent is given.

Goal of the Scenario

After form submission, the user should see the standard request confirmation on the site. The manager should receive a Gravity Forms notification. Emma should receive the email address, name, and topic of interest only if the consent checkbox is selected. If the user does not consent, the entry stays in WordPress, but the Emma feed does not run.

Preparing the Form

The form should include these fields: Name, Email, a topic selection field, and a consent checkbox. It is best to make the topic a dropdown or radio buttons with clean, consistent options. For the email address, use the dedicated Email field rather than a plain text field so the basic address validation happens before the feed even runs.

1. Create or open the request form.
2. Make sure the email field is required.
3. Add a topic selection field if segmentation in Emma is needed.
4. Add the newsletter consent checkbox.
5. Save the form and go to Settings -> Emma.

Configuring the Feed for This Scenario

Create a feed with a clear name, such as Consultation newsletter opt-in. Select the Emma group for subscribers coming from the consultation form. Set the email field to the Email field. In custom fields, map the name and topic of interest. Enable double opt-in if your email policy requires address confirmation.

Then enable conditional logic and create a rule so the consent checkbox must equal the selected value. If the field contains multiple options, verify the exact value Gravity Forms stores. Sometimes an administrator changes the checkbox label after the feed is created, while the condition is still tied to the old value. After changes like that, it is best to reopen the feed and save the rule again.

Testing with Two Submissions

Create two test submissions. In the first one, select consent. In the second one, leave it unchecked. The first entry should move into feed processing and then into Emma, or into a double opt-in waiting state. The second entry should be saved in Gravity Forms but must not create a subscriber in Emma.

Expected Result for the First Submission

The Gravity Forms entry should contain the email, name, selected topic, and confirmed consent. In Emma, check the selected group and the subscriber profile. If double opt-in is enabled, the expected result may be a pending confirmation email rather than an immediate active subscription.

Expected Result for the Second Submission

In the second entry, the consent checkbox should be empty, and the feed should not send any data to Emma. This is just as important to verify as a successful subscription because it shows that the integration respects the condition and does not turn every request into a marketing contact.

Check the contrast specifically: one submission with consent and one without it. If both go to Emma, the feed condition is too broad. If neither goes to Emma, check the email mapping, feed status, and API settings.

How to Verify the Result After Publishing the Form

Publishing the form does not complete the setup. Integrations with external services need to be verified through actual submissions because only a real entry triggers the feed, async processing, conditions, mapping, and Emma's response. The form may look perfect on the front end, but the data still may not reach the group if the feed is disabled or the condition does not match.

Checking in WordPress

First, open the Gravity Forms entries for that form. Make sure the test entry was created, the email address was saved, the consent checkbox contains the expected value, and the topic of interest is filled in. If the entry does not exist, the problem is not Emma. It is the form itself, validation, a page conflict, or a JavaScript error.

Checking in Emma

Next, check the Emma group. If double opt-in is disabled, the subscriber should usually appear after feed processing completes. If double opt-in is enabled, check the confirmation email and the subscriber status. Do not treat the lack of an active subscriber as an error until you have checked the confirmation flow.

Checking Feed Logic

If the entry exists but the subscriber does not, go back to the feed. Check whether the feed is active, which group is selected, which email field is mapped, which custom fields are mapped, and how the condition is set. If the site uses multiple feeds, make sure you are looking at the exact feed that should handle the test entry.

Also keep in mind that a feed created after older entries already existed is not required to send those entries to Emma retroactively. This matters in production: if the site collected leads before the setup was in place, plan a separate safe export or another confirmed method for handling older data rather than expecting automatic synchronization.

A Safe Way to Improve the Consent Field Without Editing the Plugin

For a subscription form, it is important that the consent checkbox does not disappear visually among the other fields. The safest approach is to use a standard custom CSS class on that specific field and add a small CSS adjustment in the theme or wherever you normally keep site-specific styles. This does not change Gravity Forms Emma code and is easy to roll back.

How to Apply a Class to the Consent Field

Open the checkbox field in the form editor, go to the Appearance tab, and add the class emma-consent-note under Custom CSS Class. After that, you can style only that field without affecting the other checkboxes across the site.

The CSS below makes the consent field slightly more noticeable and adds a subtle background. Add it to a child theme, the theme's custom CSS area, or another standard styling mechanism on the site. Before publishing, test the form on a mobile screen.

.gform-theme--framework .gfield.emma-consent-note {
  padding: 14px 16px;
  border: 1px solid #d8e2ef;
  border-radius: 8px;
  background: #f7fbff;
}

.gform-theme--framework .gfield.emma-consent-note .gfield_label,
.gform-theme--framework .gfield.emma-consent-note .gchoice label {
  font-weight: 600;
}

The verification is simple: open the page with the form on the public site, confirm that only the consent field is highlighted, then submit one test entry with consent and one without it. If the style conflicts with the theme, remove the class from the field or remove the CSS. Do not edit the add-on files directly: those changes will be lost when the plugin is updated.

Why a Subscriber May Not Reach Emma and How to Diagnose It

The best way to troubleshoot is to follow the chain: the form created an entry, the feed should have run, the API settings are available, Emma accepted the request, and double opt-in is not delaying the addition. If you jump straight into logs, it is easy to miss a simple cause such as a disabled feed or an incorrect condition.

The Form Submits, but the Subscriber Does Not Appear in the Group

Symptom: the user sees the confirmation on the site, the entry exists in Gravity Forms, but there is no new subscriber in Emma.

What to check: whether the feed is active, whether a group is selected, whether the correct email field is mapped, whether the conditional logic matches the test submission, and whether double opt-in is enabled. If double opt-in is enabled, check whether the confirmation email was delivered and whether the user completed the confirmation.

How to fix it: create a test entry with minimal data, temporarily simplify the feed condition, review the mapping, and save the feed again. If everything works after simplification, add the condition back gradually.

The Green API Check Marks Do Not Appear in Emma Settings

Symptom: after saving the Public API Key, Private API Key, and Account ID, the settings are not validated.

What to check: whether the account ID is correct, whether extra spaces were copied accidentally, whether the public and private keys were swapped, and whether the credentials came from the right Emma account. For agency accounts, make sure you are using the correct subaccount if that applies to your Emma structure.

How to fix it: create a new API key in Emma, save the private key in a secure place immediately, update the settings in Gravity Forms, and test again. Old keys should not be spread around tasks and chat threads.

The User Submitted the Form Without Errors, but No Confirmation Appeared on the Page

Symptom: the entry exists in the admin panel, but the visitor did not see the confirmation, or the page hung after submission.

What to check: whether there is a theme or plugin conflict, whether the form works on a plain test page, whether there are JavaScript errors, and whether the site supports background processing. In recent Gravity Forms versions, feed processing may run in the background, and logs can help confirm whether the task reached the processor.

How to fix it: enable Gravity Forms logging and Emma logging only for the duration of testing, submit a test entry, and inspect the latest log lines. After troubleshooting, disable logging and delete the logs because they may contain personal data.

Custom Fields Stay Empty in Emma

Symptom: the subscriber is created, but the name, interest, or other fields are not populated.

What to check: the custom field mapping in the feed, field types, exact shortcut names in Emma, and whether the Gravity Forms entry actually contains the data. If a form field is conditional and was not shown to the user, it may be empty as part of the form's normal logic.

How to fix it: send a test submission with every required field filled out, check the Gravity Forms entry, and remap each field one by one. Do not create new Emma fields with similar names until you are sure the existing field truly does not fit.

The Feed Runs for the Wrong Users

Symptom: Emma receives users who did not check the consent box, or a subscriber is sent to the wrong group.

What to check: the condition for each feed, the order and overlap of multiple feeds, and the actual values stored for the checkbox or radio field in the entry. If conditions overlap, one user may be added to several groups.

How to fix it: write down the expected scenario for each feed and test it separately. If the logic has become too complex, simplify the form: split interests into clear options or use one feed with a custom field instead of multiple overlapping groups.

When Gravity Forms Emma Is the Right Choice

Gravity Forms Emma is worth using when your WordPress form already collects important data and Emma is the working platform for email campaigns and segmentation. A strong setup is not just about pasting in API keys. It is about defining the right group, email field, custom fields, consent condition, and result verification.

If your tests show the entry in Gravity Forms, correct fields in Emma, clear double opt-in behavior, and predictable conditional logic, the integration is ready for a public page. Before that, document the feed setup, disable temporary logging, and make sure the team knows which form responses go to which groups.

When you are ready to repeat the setup on your own site, you can download Gravity Forms Emma and run the validation on a test form before connecting it to a live page. That approach reduces the risk of accidental subscriptions and helps you catch issues before real visitors start submitting the form.