Gravity Forms Agile CRM - WordPress Plugin

A Practical Guide to Configuring Gravity Forms Agile CRM for Leads and CRM Tasks

Gravity Forms Agile CRM is not just a way to pass a form submission into a third-party service. In real workflows, it solves a more specific problem: it turns a WordPress form submission into a contact, tag, note, or task in Agile CRM so the sales or support team does not have to move data manually or lose leads between the website, email, and CRM.

In this guide, we will walk through the full working setup: what to check before installation, where the Agile CRM account is connected, how a feed works in Gravity Forms, which fields you should map first, when to enable updates for existing contacts, how to use tags and conditional logic, how to verify the result, and where to look if the contact or task never appears.

This guide is written for a site owner, marketer, webmaster, or integrator who already understands why they need Gravity Forms and Agile CRM, but wants to configure the connection properly. It does not cover buying a license or bypassing activation. The focus here is practical setup of an add-on you already have access to, plus safe verification on a test form.

How the Form-to-CRM Connection Works After Submission

The core idea behind this plugin is built around the feed. In Gravity Forms terms, a feed is a separate form setting that tells the add-on what to do with a successful submission. For Agile CRM, that means taking values from the entry, mapping them to CRM fields, and performing the selected action. The official documentation describes two key actions: Create Contact and Create Task.

This is different from a standard email notification. A notification tells a person that a submission came in, but it does not create a structured record in the CRM. A feed, by contrast, sends data to an external service and becomes part of the actual workflow. That is why setup should not focus only on whether the lead "comes through," but also on which object should be created in Agile CRM and who is expected to work with it.

What Happens to the Form Data

After a successful submission, Gravity Forms saves the entry and runs active feeds if their conditions are met. The Agile CRM Add-On uses the global connection settings, then reads the settings of the specific feed: its name, action, field mapping, tags, contact update settings, task settings, and conditional logic. If the data matches the rules, the add-on sends it to Agile CRM through the API.

The practical takeaway is simple: if the form does not contain a valid email address, if the feed is disabled, if the conditional logic does not match, or if the API key is wrong, the CRM object will not be created. That is why it is better to configure everything on a short test form instead of a live form with a dozen conditions, where it is much harder to see both the input data and the final result.

When to Use a Contact and When to Use a Task

Create Contact works well for lead forms, consultation requests, demo signups, service interest forms, and any case where the main goal is to save a person in the CRM. In this mode, email, name, phone number, source, interest, and tags matter most. Tags help segment submissions, for example separating "demo," "support," "partnership," or "enterprise inquiry."

Create Task is useful when a form submission should immediately turn into action for the team: call back, send an email, review the request, schedule a meeting, or prepare a proposal. Task settings let you define the subject, due date based on a number of days after submission, priority, status, type, and note. If you assign the task to the created contact, the submission does not remain an abstract event with no connection to a real person.

Quick takeaway: before you configure anything, decide what matters most in your workflow: growing the contact database, creating a specific task, or splitting scenarios across different forms and conditions. That decision determines the feed structure and the required fields.

Who This Integration Fits and When Another Route Makes More Sense

Gravity Forms Agile CRM is a strong fit for sites where Gravity Forms is already the main form builder and Agile CRM is the working CRM used to process leads. In that setup, the add-on removes manual data transfer and helps keep the form, the CRM, and team tasks in a single chain.

The best use cases are not vague "contact forms," but forms tied to clear business logic. For example: a demo request, consultation booking, quote request, partnership form, support form for existing customers, or registration for a private webinar. In each case, you can define in advance which fields the CRM needs, which tag should be applied, and what the manager is expected to do next.

When the Product Will Be Convenient

• Your team already manages customers in Agile CRM and wants website leads to arrive there without manual copying.
• Your site already uses Gravity Forms, not the Agile CRM form builder or a different CRM platform.
• You need to create contacts, update existing records, apply tags, and trigger follow-up actions in the CRM.
• Your forms support different scenarios, and only some submissions should be sent to the CRM when certain conditions are met.
• Marketers need more than an email notification and want a CRM record they can segment and work with.

When You Should Think Twice

This integration may be unnecessary if the site gets only a couple of leads per month and the team is fine with email notifications. It also will not solve complex two-way sync scenarios, such as sending statuses back from Agile CRM into WordPress, showing a customer account area, or updating form fields from CRM data. Those cases usually require a separate integration layer, webhooks, automation through services like Zapier, or custom development.

You should also assess the state of your CRM process itself. If Agile CRM does not have agreed-upon fields, tags, owners, and handling rules, the plugin will only speed up the flow of messy data into the CRM. It is better to define which data is required and how the team distinguishes a hot lead from a standard contact before you automate anything.

What to Check Before Installing It on a WordPress Site

Before installation, do not just verify that you have the add-on ZIP file. This integration sits at the intersection of WordPress, Gravity Forms, Agile CRM, and server-side HTTP requests. A failure in any one of those layers can look exactly the same: the form submits successfully, but the CRM gets nothing.

Basic Compatibility and Access

Official Gravity Forms sources note that add-ons depend on Gravity Forms Core and its framework. So start by confirming that the main Gravity Forms plugin is installed, active, and updated normally. The Gravity Forms system requirements page also emphasizes the importance of an up-to-date WordPress, PHP, MySQL/MariaDB, and PHP extensions including curl and openssl. For a CRM integration, those extensions matter even more because requests to an external API often fail without them.

The second mandatory item is access to Agile CRM. To configure the integration, you need the account URL, user email, and REST API key. If you plan to enable Agile CRM analytics, you will also need the JavaScript API key. These values are taken from the Agile CRM admin area, in the developer and API section. Do not send keys to outside contractors in plain text, and do not place them in public notes, screenshots, or transcripts.

The Form, Its Fields, and User Consent

Prepare the form before connecting the CRM. The minimum set for most lead flows is: name, email, phone number or another contact method, request topic, consent to data processing, and either source of interest or request type. If your CRM already has required fields, add them to the form in advance. If a field is optional on the site but required in the CRM process, that has to be resolved before you build the feed, otherwise you will end up with a confusing error or an incomplete record.

Do not send everything to the CRM just because you can. Files, private messages, technical fields, anti-spam fields, and internal values should only go into Agile CRM if they serve a clear purpose. The cleaner your field map is, the easier it will be later to filter contacts, build segments, and trace failures.

Test Environment and Safe Launch

The ideal order is to configure the integration first on a staging site or on a separate test form. If you do not have staging, create a short form that is not linked from the main navigation and submit a few test entries. Make sure Agile CRM receives clearly identifiable test contacts rather than real customers, and make sure managers are not getting unnecessary live tasks.

If the site uses aggressive caching, bot protection, a firewall, or restrictions on loopback requests, verify in advance that Gravity Forms can still run background tasks and external HTTP requests. For add-ons that support background processing, working scheduled events, loopback requests, and access to admin-ajax.php for internal WordPress requests are especially important.

Connecting Agile CRM in Gravity Forms Settings

The global connection settings live in the WordPress admin panel. The official documentation points to Forms -> Settings -> the Agile CRM tab. This is where you enter the Agile CRM account details, not the settings for a specific form. That distinction matters: first the site gets permission to connect to the CRM, then individual forms get their own feeds.

Connection Fields

The Agile CRM settings normally use three basic values: Account URL, Email Address, and API Key. If Agile CRM analytics is enabled, a JavaScript API key field also appears. After saving, Gravity Forms shows a green check mark next to correctly completed fields. If you do not see that check mark, do not move on to feed creation yet. Fix the URL, email, or key first.

A common mistake is confusing the account domain, the Agile CRM marketing website, and a full URL with extra paths attached. The settings need the actual address of your CRM account in the format expected by the add-on. If you are not sure, verify it against the Agile CRM and Gravity Forms documentation, not notes left over from an older setup.

Do You Need to Enable Analytics?

The Enable Analytics Tracking option is not about creating a contact itself. It is tied to Agile CRM's ability to track contact activity on the site. You should enable it only if you actively use Agile CRM analytics to evaluate lead behavior and are prepared to reflect that correctly in the site's privacy policy.

If your need is simpler, such as passing a lead to a manager and creating a contact, start without analytics. First make sure contact and task creation works reliably, then test tracking separately. That order makes troubleshooting much easier: if something breaks, you can tell whether the issue is in the basic API connection, the feed, or the additional tracking layer.

Post-save check: green check marks next to the credential fields confirm that basic authentication appears to be valid. That still does not prove that a specific form will send data to the CRM, but without those check marks it is too early to configure a feed.

Configuring the Feed: Contact, Fields, Tags, and Record Updates

A feed is created inside a specific form: Forms -> the form you need -> Settings -> Agile CRM -> Add New. The feed name is visible only in the admin area, so name it by function: "Demo request - contact," "Support form - task," "Partnership inquiry - CRM." A month later, names like that save more time than you expect.

Choosing the Action

The Action field determines what happens when the feed runs: create a contact or create a task. For a contact-based scenario, you get the Contact Details block where Gravity Forms fields are mapped to Agile CRM fields. For a task-based scenario, you get the Task Details block with subject, due date, priority, status, type, note, and the option to link the task to the created contact.

Do not try to cover every possible variation on the first pass. Start with one action and one test scenario. For example, a demo request form creates a contact with the tag demo-request. Once that works reliably, then add a manager task or a separate form for another request type.

Mapping Fields Without Unnecessary Noise

In the mapping block, the left side shows the fields Agile CRM accepts, and the right side lets you choose the form fields. Map only the values a manager or marketer actually needs. If the form has a "Comment" field, you can pass it into a description, note, or an appropriate custom field if your CRM has one. If there is no suitable field in the CRM, do not force the text into a random field just to make sure it gets sent.

Tags and Updating an Existing Contact

Tags in Agile CRM are especially useful for segmentation. The official documentation notes that the tags field can use both static values and merge tags. That is helpful when the tag depends on the user's selection in the form. For example, choosing "Integration," "Support," or "Demo" can become a segmentation signal inside the CRM.

The Update Contact if already exists option requires caution. If you leave it off, an existing contact may be skipped. If you turn it on, you can choose whether to replace existing information or append new data. For a typical site, it is safer to start with append logic where that option is available and appropriate, because manager notes and previously collected information should not disappear just because someone submitted a short new form.

Rule for the first setup: use email as the main contact identifier, keep tags short and predictable, and enable existing-contact updates only after testing against a record that already exists.

Tasks in Agile CRM: Turning a Submission Into Team Action

A CRM contact is useful, but by itself it does not guarantee a team response. If your process requires immediate follow-up, use the Create Task action. In that mode, the submission becomes a task with a subject, due date, priority, status, type, and note. This is especially useful for forms where every submission requires action: calling back, scheduling a meeting, checking technical details, or preparing a proposal.

How to Write the Subject and Description

The task subject should be short but recognizable. A good format is "Demo request: {Name}" or "Call back about request: {Company}." In Gravity Forms, values like these are easy to build with merge tags if they are available in the setting field. Do not make the subject too long. Put the details in the description or note instead, where the manager can see the comment, selected product, budget, timeline, and a link to the WordPress entry if that link is available in your setup.

Due Date, Priority, and Type

Days Until Due sets the due date as a number of days from the moment of submission. For high-intent leads, a short deadline usually makes sense, but do not set every form to "today" without thinking it through. If the team cannot keep up with the volume, tasks will immediately start turning red and the deadline will stop meaning anything. Priority values such as High, Normal, or Low are best tied to the request type or form field through separate scenarios, instead of assigning the same high level to everything.

The task type, such as Call, Email, Follow Up, Meeting, and other options, helps the manager understand the next step without reading the full comment. For a demo request, Call or Meeting usually makes sense; for a documentation request, Email; for a follow-up touchpoint, Follow Up.

When to Assign the Task to the Created Contact

The Assign Task to Created Contact option is helpful when the feed is supposed to create a contact and immediately attach a task to it. That reduces the chance that a manager sees a task without context. But before enabling it, verify which fields are required for contact creation. If the email is empty or invalid, the task may not be linked the way you expect.

Practical rule of thumb: a task should answer the question "what needs to happen next," while a contact should answer "who are we working with." If the CRM creates only one of those two, the process often remains incomplete.

Conditional Logic: Send Only the Right Submissions to the CRM

Gravity Forms Agile CRM supports feed conditional logic. This is one of the most valuable features, because not every form submission should become a CRM object. For example, one form may collect demo requests, documentation questions, and partnership messages. If all of those go into the same pipeline, the CRM will quickly become noisy.

Which Conditions to Build First

Start with simple conditions that are easy to verify through a test submission. For example, run the feed only if the "Request Type" field equals "Demo," or if the user checked consent to be contacted by a manager. For complex multi-page forms, do not build a huge chain of conditions on day one. Configure one feed first, then add variations.

• Send the submission to the CRM only if the user selected a commercial interest.
• Create a high-priority task if the "Launch Timeline" field contains a near-term timeframe.
• Apply a separate tag if a specific product or service was selected.
• Do not send technical tests, internal submissions, or requests without contact consent to the CRM.

How Not to Get Lost With Multiple Feeds

If the form uses multiple integrations, put the condition directly in the feed name: "CRM - demo only," "CRM - support task," "CRM - partner contact." After every change, submit a test entry with predictable values and check not only the result in Agile CRM, but also the Gravity Forms logs if logging is enabled.

The most common logic mistake is expecting a feed to run even though the condition does not match the test submission. In that case, everything looks successful on the form side: the confirmation appears, the email is sent, and the entry is saved. But there is no CRM object because the condition is working exactly as configured. That is why it helps to keep a sample set of test values next to every conditional feed so you know exactly which submission should trigger it.

Practical Scenario: A Demo Request Form With a Contact and a Task

Let us walk through a scenario that shows the real value of Gravity Forms Agile CRM. Imagine the site offers a consultation for implementing a service. You want the site form to create a contact in Agile CRM, add the tag demo-request, and create a task for a manager to reach out to the person. If your specific setup uses separate contact and task feeds, test each feed on its own. If you are using a task action that also creates a contact and links the task, verify both results from a single submission.

Goal

After the form is submitted, Agile CRM should contain a contact with the email, name, phone number, company, and interest. The contact should have a tag that the marketing team can use for segmentation. There should also be a task for the manager with a clear subject and a reasonable deadline.

Preparing the Form

Create or open a form with these fields: name, email, phone number, company, request type, comment, and consent to be contacted. Make email required. It is better to make the "Request Type" field a dropdown with a limited set of values instead of free text. That makes both conditional logic and tags much easier to manage.

Setup Steps

1. Open the form in the WordPress admin area and go to Settings -> Agile CRM.
2. Create a new feed through Add New and name it for the scenario, for example "Demo request - Agile CRM."
3. Select the Create Contact action if the contact is the primary outcome, or Create Task if the task should be the main result.
4. Map the email, name, phone number, company, and interest to the corresponding Agile CRM fields.
5. Add the demo-request tag or a dynamic tag based on the "Request Type" field if that matches your CRM segmentation model.
6. If you are using task settings, define the subject with merge tags, the due date in days, the priority, the status, and the task type.
7. Enable conditional logic so the feed runs only when "Demo" or another target value is selected.
8. Save the feed and submit a test request using a unique email address that will be easy to find in Agile CRM.

Checking the Result

Open the entry in Gravity Forms and make sure all fields were saved correctly. Then search for the test email in Agile CRM. The contact should contain the expected fields and tag. If a task was created, check its subject, status, due date, link to the contact, and note. After that, submit a second test request with the same email and a different comment so you can see how updates to an existing contact behave.

A Detail That Often Gets Overlooked

If the form uses conditional logic, the test submission has to match the condition. For example, if the feed sends only requests with the type "Demo," then a test with the type "Support" will not create a contact. That is not a failure. It is expected behavior. For verification, use two tests: one that should reach the CRM and one that should remain only as a WordPress entry.

How to Verify the Result Without Missing a Silent Failure

After saving the feed, do not stop at the message saying the form was submitted successfully. That confirms only the public-facing part of the form. A CRM integration needs separate verification: the entry was created, the feed processed, the external API accepted the data, the CRM object appeared, and the team can see the task.

Verification Chain After a Test Submission

1. Open Forms -> Entries and confirm that the test entry was saved and not flagged as spam.
2. Open the feed settings and make sure the feed is active, saved, and its conditional logic matches the test values.
3. Find the test email in Agile CRM and compare the fields to the entry.
4. Check the tags, task status, due date, and description if the feed creates a task.
5. If the result does not appear, enable logging in Gravity Forms and repeat the test using a new unique email address.

The official logging documentation recommends enabling logs through Forms -> Settings, then turning on the relevant add-ons in the Logging tab. Do this only while diagnosing the issue. After the problem is resolved, disable logging and remove unnecessary logs, since they may contain technical details and fragments of submitted data.

Background Processing and Delays

The Agile CRM Add-On changelog confirms support for background feed processing. That is good for form performance because the request to an external service should not keep the user waiting longer than necessary. But that architecture changes how you troubleshoot: sometimes the form has already shown a confirmation while the feed is still running in the background.

If the contact does not appear immediately, wait a short time and check the logs. If background tasks on the site are not working, Gravity Forms recommends checking Tools -> Site Health, the Gravity Forms system status, and signs of issues with loopback requests, scheduled events, and HTTP requests. On hosting with strict limits, that is often the real cause of "silent" delays.

Limitations, Privacy, and Careful Day-to-Day Use

A CRM integration deals with personal data, so it should not be configured like a decorative form feature. Email addresses, phone numbers, names, companies, interests, and user comments leave WordPress and are sent to a third-party service. That means the site should have clear consent mechanisms, a privacy policy, and a sensible limit on how much data is transferred.

Do Not Send Unnecessary Fields

Technically, it is easy to map many fields, but the CRM should receive only what actually helps process the lead. If a comment contains private information, it may be better to keep it in the entry and send only a short category or a link to an internal record, if that process is safe and available to your team. The less unnecessary data flows into the external system, the easier it is to control access properly.

Contact Updates Need Clear Rules

The existing-contact update option is useful, but it can also wipe out context if old data is replaced with new incomplete values. Before you enable it, decide which fields may be overwritten and which should instead be appended or left for manual review by a manager. For example, a new phone number may be added, but an older deal comment should not disappear just because someone submitted a short contact form.

Caching, Anti-Spam, and Site Protection

Page caching normally should not interfere with server-side Gravity Forms submission processing, but aggressive optimization tools, anti-bot filters, and firewalls can affect AJAX, background requests, or external HTTP calls. If CRM records stop appearing after site protection is enabled, temporarily stop looking at the visual form behavior and instead trace the full chain: entry -> feed -> log -> Agile CRM.

Safe practice: do not edit the code of Gravity Forms, the Agile CRM Add-On, or WordPress core. For diagnostics, use built-in logs, system status, test forms, and feed condition checks. If you need a custom data exchange flow, it is better to build a separate integration using documented APIs and a test environment.

When Gravity Forms Agile CRM Is the Right Choice

Gravity Forms Agile CRM is worth using when a WordPress form needs to become part of a sales or support workflow instead of simply emailing an admin. The add-on's strength is its clear connection between feed settings and CRM actions: contact creation, record updates, tags, tasks, and conditional triggers. If those elements align with your process, the integration quickly pays off by bringing order to incoming leads.

Before going live, run through a short checklist: global credentials are verified, the test form creates an entry, the feed is active, email is mapped correctly, tags are not chaotic, conditional logic has been tested with two different submissions, logging has been turned off after diagnostics, and the team knows where to find new contacts and tasks in Agile CRM.

If the product fits your scenario after that review, you can get the Gravity Forms Agile CRM file and configure it on a test form first. That approach is safer than connecting all live forms immediately and then trying to figure out why some submissions ended up in the wrong CRM segment.