Gravity Forms Batchbook - WordPress Plugin

A Guide to Safely Auditing and Configuring Gravity Forms Batchbook

Gravity Forms Batchbook is a rare case where a plugin guide should begin not with the promise of a quick integration, but with a reality check on the project itself. Gravity Forms official documentation confirms that the Batchbook service has been shut down and the official Batchbook Add-On is no longer supported. That makes this guide most useful for owners of older sites, webmasters, and agencies who have found an installed archive, been asked to restore a legacy form, or need to decide whether this integration still belongs in a live environment.

Below, we cover more than just installation and basic setup. We also address the details that usually get lost in short product summaries: where to find the feed, how to tell whether submissions were actually sent to the CRM, why old entries do not sync on their own, what to do with conditional logic, how to enable logging without exposing personal data, and when it makes more sense to move straight to a modern CRM integration.

If this is a new project, treat Gravity Forms Batchbook as a legacy integration. If you are dealing with an active older site, the approach is different: create a backup first, document the form, its fields, old feeds, and submission logic, then decide whether the plugin can be safely disabled or needs to remain temporarily until migration is complete. That order reduces the risk of losing leads, breaking the form, or sending personal data to a dead external service.

This guide is written for WordPress sites running Gravity Forms. It does not cover purchasing, license activation, or workarounds for restrictions. The focus is on practical auditing, configuring an existing integration, diagnosing old forms, and choosing a replacement if Batchbook no longer fits real-world use.

What the Batchbook Integration Does Alongside Gravity Forms

Originally, this plugin belonged to Gravity Forms' family of feed-based integrations. In Gravity Forms, a feed is a form-specific setting that tells the plugin what to do with a successfully created submission: send data to an external service, create a contact, update a record, make a web request, or process a payment. In the case of Batchbook, the purpose was narrow and easy to understand: take data from a WordPress form and send it to the CRM as a contact or a contact update.

This mechanism is different from notifications. A notification sends an email to an administrator or user, while a feed controls integration with an external service. That distinction matters on older forms: the submission may be saved in Entries, the administrator email may go out, and yet no CRM contact will be created if the feed is disabled, conditional logic does not match, the external service is unavailable, or the credentials no longer validate.

The official Batchbook Add-On announcement described four key capabilities: creating and updating contacts in Batchbook when a form is submitted, choosing specific forms for integration, using Gravity Forms conditional logic, and installing the add-on through the official add-on installer. The changelog also shows that the plugin later gained feed duplication support, delayed processing until a successful PayPal Standard payment, and the gform_batchbook_person filter for modifying contact data before submission.

From a practical standpoint, those facts give you an audit map. If you are reviewing an old form, do not just look at the fields. You need to determine whether the form has a Batchbook feed, which fields were mapped to the CRM, whether submission logic was in place, whether payment was required before sync, and whether the developer used a site-specific filter to modify the contact array. The main goal of the audit is not to revive a discontinued integration at any cost, but to preserve data and replace that outdated part of the workflow correctly.

If Batchbook no longer accepts data, a working form is still a valuable asset. Preserve the form structure and submissions first, then plan the new CRM connection.

Who Actually Needs to Work With This Plugin

Gravity Forms Batchbook should not be installed on a new site as a normal production integration. Today, its value is usually tied to maintaining older projects: auditing, migrating CRM logic, reconstructing configuration history, and safely removing unnecessary code. So the decision is not about whether Batchbook seems appealing in theory, but about the problem you need to solve right now.

A Good Fit for Auditing an Older WordPress Site

If a site has been running for years and an old Batchbook Add-On is still present in the admin panel, do not remove it blindly. The form may rely on conditional logic, hidden fields, custom merge tags, a payment step, or extra PHP filters. Removing the plugin without checking may not break the public form, but it can remove the settings tab that tells you where leads used to go and which fields were treated as required.

In that scenario, the plugin matters as an audit target. You open the form, inspect its feeds, export the settings, document the fields, and determine whether the site still depends on Batchbook in any meaningful way. After that, you can decide whether to replace the CRM integration with Zoho CRM, Zapier, Webhooks, or another supported option, or simply disable the old feed if it has not been used in a long time.

Useful When Migrating the Sales Workflow

Some sites have collected leads through the same form for years: demo requests, consultations, dealer registrations, wholesale pricing requests, or service bookings. If those submissions used to flow into Batchbook, moving to a new CRM means preserving the meaning of the fields: name, email, company, phone number, lead source, product interest, comment, and consent to data processing. Gravity Forms Batchbook helps expose the old mapping logic so you can use it as a draft for the new integration.

Not the Right Choice for a New CRM Rollout

For a new site, it is better to choose a supported integration. The issue is not just that Batchbook is gone. Legacy CRM connections are risky because their documentation disappears, the API may stop responding, support no longer handles requests, and sync errors become hard to diagnose. On a new project, it is cheaper to set up a modern path from the start than to build a workflow around a plugin with no viable lifecycle.

Not Suitable as the Only Submission Store

Even when the integration was working, Gravity Forms Entries remained an important control layer. With a legacy plugin, that matters even more. If you are temporarily maintaining an old form, make sure submissions are saved locally, notifications still reach the right people, and the CRM transfer is treated as an additional step. The external service may be unavailable, but the local submission record still needs to be preserved and verifiable.

What to Check Before Installing or Restoring It

Before you install an old archive or restore the plugin from a backup, pause for a moment. This is not a normal active add-on, so the standard path of "upload the ZIP and click Activate" may not be enough. Start with the environment, backups, and a clear understanding of why the plugin is needed on the site at all.

The WordPress and Gravity Forms Environment

Gravity Forms official requirements change over time, and official add-ons depend on the core Gravity Forms version. For the old Batchbook Add-On, that is especially sensitive: the archive may have been built for an earlier Gravity Forms branch, while the current site may be running a different version of WordPress, PHP, and MySQL. Do not jump to "the plugin is broken" before checking the error log and system status.

The minimum safe checklist before testing:

• Create a full backup of files and the database before activating the old archive.
• Confirm that the main Gravity Forms plugin is installed and opens forms without errors.
• Make sure the user has permission to edit forms, view entries, and access settings.
• Check the PHP extensions Gravity Forms needs for full functionality, especially curl and openssl, because integrations with external services usually depend on HTTP requests and secure connections.
• Test on a site copy or staging environment first, not on a live form with active traffic.

A Real Business Need

If the goal is simply to "see what used to be there," an audit is enough. If the goal is to "restore lead delivery," first verify that the receiving service still exists and that the team has access to the current CRM. Official sources say Batchbook has shut down, so do not plan a new workflow around its API. In practice, it is more useful to treat the old feed as a field-mapping template, not as a future data channel.

Data You Cannot Afford to Lose

Before disabling or replacing anything, document which forms collect personal data and where that data is stored. Gravity Forms supports Personal Data settings, so you can control IP address retention, entry deletion policies, and whether the form participates in exporting or deleting personal data through WordPress tools. That matters for a CRM integration because the form may send not just a name and email, but also a sales request, phone number, address, comment, and attachments.

The safe order is this: export entries and form settings first, then disable the feed, then test the new integration with a sample submission.

Installation and the First Admin-Side Checks

Gravity Forms add-ons are usually installed through Forms > Add-Ons or by uploading a ZIP in Plugins > Add New. But Batchbook is different in one important way: the official add-on is no longer available through the Gravity Forms site or the add-on browser. So if you are working on an older project, the archive should come from an internal, trusted source: a client backup, a previous infrastructure archive, a project package, or another legitimate source you can tie back to the specific site.

How to Enable It with Minimal Risk

1. Create a staging copy of the site and make sure it does not send real notifications to customers.
2. Install the plugin archive using the standard WordPress uploader or restore the plugin folder from a backup.
3. Activate the plugin and immediately check the Plugins screen for PHP warnings.
4. Open Forms, select the relevant form, and see whether a Batchbook tab appears in the form settings or feed list.
5. Do not submit a real lead until you know where it will go and whether sending to the external service is enabled.

If the site throws a critical error after activation, do not try to fix it on production. Disable the plugin on staging, turn on logging, check the PHP version, Gravity Forms system status, and possible conflicts. With older add-ons, the root cause is not always the archive itself: sometimes the incompatibility comes from a newer PHP version, a changed API, or another plugin intercepting form processing.

Where to Find the Feed

In current Gravity Forms documentation, the path for feed-based add-ons is described as Forms > [Your Form] > Settings > [Add-On Name]. Older interfaces may phrase it differently, but the logic is the same: the feed belongs to a specific form, not to the whole site. If the site has multiple forms, do not stop at the main contact form. Check lead forms, registration forms, pricing request forms, partner applications, and old landing pages.

An Initial Test Without CRM Assumptions

Start by sending a test submission and checking only the local result: was an entry created, did validation run, did the admin email go out, was the record marked as spam, and are there any errors in the system log? Only after that should you assess the CRM side. That sequence helps you separate a broken form from a broken integration.

The short version after installation: the plugin is active, the form opens, entries are being created, the feed tab is available or its absence is explained, and logging is ready for testing. If even one of those items is missing, it is too early to move on to configuring the Batchbook feed.

The Feed Settings Map: Fields, Conditions, and Timing

Batchbook configuration revolves around three decisions: which forms send data, which form fields match the CRM fields, and under what conditions the feed should run. Even if Batchbook itself is no longer in use, this map helps you migrate the process into another tool. Do not treat it as a checklist of toggles. It is a description of business logic: which user counts as a lead, which data is required, what to do with a repeat contact, and when the record should enter the CRM.

Field Mapping

For a CRM integration, the email field is usually the central identifier. Without it, it is difficult to create a usable contact, update an existing record, or detect a duplicate. In the old Batchbook feed, check which form fields were mapped to first name, last name, email, company, phone number, and notes. If the form uses a single Name field but the new CRM expects separate first name and last name values, decide in advance how those data should be transferred.

It helps to create a mapping table before any migration:

Once you build that table, it becomes clear which fields can be migrated directly and which ones deserve a rethink. For example, an older form may have used a single field labeled "Your question," where users entered the request, budget, and urgency all at once. For a new CRM, it may be more useful to split that into more structured fields, but that should be done carefully so you do not hurt the form's familiar conversion pattern.

Conditional Logic

Gravity Forms lets you define the conditions under which a feed is processed. In the original Batchbook Add-On announcement, this was one of the key features: not every form submission has to create or update a contact. For example, you might want to send only "Request a consultation" submissions to the CRM while leaving general support questions in email notifications.

When auditing an old integration, check the following:

• Whether conditional logic is enabled in the feed.
• Which fields control the trigger: inquiry type, consent checkbox, selected service, order amount, or payment status.
• Whether the logic uses all or any, because one incorrect condition set can change the behavior of the entire form.
• Whether multiple feeds exist on the same form and whether they duplicate the same contact submission.

When the Submission Is Processed

Gravity Forms documentation emphasizes that feeds may be processed after a successful form submission and entry creation, and some add-ons use background processing. The Batchbook Add-On changelog specifically mentions support for delaying processing until a successful PayPal Standard payment. That matters for forms where the CRM contact should appear only after payment, not after any incomplete step.

If the old site collected paid submissions, review not only the Batchbook feed but also the payment feeds. A mistake in processing order can cause unpaid leads to enter the CRM or, on the other side, paid submissions to stop syncing after a payment plugin change. For migration, it is best to write the rule in plain language: "create the contact after a successful form submission" or "create the contact only after payment confirmation."

Customization Through a Filter

The changelog mentions the gform_batchbook_person filter. For a developer, that is a signal: the old site may include extra customizations that changed contact data before submission. There is no reason to add new code for a legacy integration, but before disabling the plugin, it is worth searching for that hook in the theme, child theme, mu-plugins, and any snippets plugin. If you find the filter, preserve its purpose in your technical notes: which fields were combined, which tags were added, and which values were cleaned up or transformed.

Do not automatically carry an old PHP snippet into a new CRM integration. First understand the business logic it implemented, then reproduce it with the new add-on's built-in settings or a separate, safe snippet.

Practical Scenario: Preserve the Old Form and Prepare a CRM Replacement

Let us walk through a realistic task. The site has a "Consultation Request" form that used to send contacts to Batchbook. The sales team is moving to another CRM, but they do not want to lose current submissions or redesign the public form in a single day. The goal is to preserve the old logic, verify local submissions, and prepare a new feed without sudden lead loss.

Goal

You want the form to keep accepting submissions, the administrator to keep seeing them in Gravity Forms Entries, and the new CRM to receive only qualified leads. The old Batchbook feed is used as a reference: it shows which data used to matter, but it does not remain the primary channel.

Preparation

First, create a staging copy. Export the form using Gravity Forms tools, save the field list, and capture a few screenshots of the old feed settings if the interface is still available. Then export the latest entries from that form so you can compare real values with what you plan to send into the new CRM. If the sales team has internal process documents, confirm which fields they actually use.

What to Check Before Making Changes

• The form saves entries and does not mark legitimate submissions as spam.
• The admin notification works independently of the CRM feed.
• The required fields and conditional logic in the old Batchbook feed are clear.
• The new CRM add-on is installed only on staging, or disabled on production until testing is complete.
• There is a rollback plan: restore the previous set of active plugins and feeds from backup.

Steps

1. Open the form in the admin panel and list every field tied to the CRM: name, email, phone number, company, interest, comment, and source.
2. Open the old Batchbook feed and document which fields were mapped where. If the feed is unavailable, use the form export and old entries as your structural source.
3. Create a new feed for the chosen CRM integration or the Webhooks Add-On. Do not enable it for all submissions right away.
4. Recreate only the conditions that still make sense, for example sending to the CRM only when a specific service is selected and the email field is filled out.
5. Submit a test entry with realistic data. It should pass validation, appear in Entries, and satisfy the conditional logic.
6. Check logging and the result in the new CRM. If the record did not appear, inspect the feed logs instead of changing the form blindly.
7. After a successful test, disable the old Batchbook feed, but keep the exported settings and notes about the old logic.

Expected Result

In the best-case outcome, the public form does not change visually for the user. Inside the site, a new and understandable chain appears: form submission, entry creation, conditional logic check, new feed processing, and then a contact or lead in the current CRM. Batchbook remains only in the project's archival documentation or as a temporarily disabled plugin on staging.

A Common Detail That Gets in the Way

The most common mistake is testing only the "perfect" submission. If the feed runs based on a condition, you need at least three test cases: one submission that should go to the CRM, one that should not, and one with an error in a required field. That way you test not only the success path, but also the boundaries of the logic. For a CRM integration, a misconfigured condition is often more dangerous than a feed that is completely disabled.

How to Verify the Result After Configuration

Result verification should answer one specific question: what exactly changed after configuration, and where can you see it? For Gravity Forms Batchbook and any replacement, there are three levels of outcome: the user sees a successful form submission, the administrator sees an entry and internal notification, and the CRM or new integration receives correctly mapped data. If you verify only one level, you can miss a failure somewhere else.

Check Entries

Open the form's entries list and find the test submission. Review the entry status, field values, IP address, submission date, spam note, attachment presence, and internal notes. If the entry was not created, the issue is not the Batchbook feed. It is the form itself, validation, caching, JavaScript, the anti-spam filter, or a theme conflict.

Check the Log

Gravity Forms lets you enable logging for both core and installed add-ons. When diagnosing an old Batchbook feed or a new CRM connection, enable the log only for the duration of the test. Then submit the form, open Forms > Settings > Logging, find the relevant add-on log, and review the lines tied to the specific entry. When the investigation is complete, disable logging and delete the logs because they may contain personal data.

Check the External CRM

In the new CRM, do not look only for whether a contact was created. Check the quality of the data as well. The email should land in the email field, the phone number in the phone field, the message in a note or description, and the source in the correct attribute. If the contact exists but the fields are mixed up, that is worse than a hidden error: the manager sees a record but cannot process the submission properly.

Check the Reverse Scenario

Submit a case that should not go to the CRM, for example one with the inquiry type set to "Technical question" if the CRM feed is intended only for new sales. If that record still appears in the CRM, fix the conditional logic. If it does not appear, but it is saved in Entries and sends an email to the correct department, the logic is working as intended.

Good result verification includes a successful test, a negative test, and a log review. One click through the form does not prove that the CRM workflow is configured correctly.

Security, Personal Data, and Submission Retention

A CRM integration almost always handles personal data. Names, email addresses, phone numbers, company details, comments, and attachments may be sensitive for both the user and the business. So when working with the outdated Batchbook Add-On, it is not enough to ask whether data is being transmitted. You also need to know where it is stored, who has access to it, how long it remains in WordPress, and what to do with logs.

Local Entries as a Control Point

Gravity Forms entries are useful for verification and recovery, but they should not become an endless data warehouse with no rules. In Personal Data settings, you can define whether IP addresses are stored, how long entries are retained, and whether the form participates in exporting and deleting data through WordPress tools. That is especially useful for an old CRM integration because you can keep only the minimum retention period you really need and reduce the risk of accumulating unnecessary information.

Logging Only During Diagnostics

Logs help explain why a feed did not process, which fields were not mapped, and what response came back from the external service. But they may also contain email addresses, names, tokens, parts of the request, or user message text. Enable logging before the test, submit one or two controlled entries, preserve the technical output in a restricted project ticket, and turn logging off after the check.

Caching and Forms That Handle Personal Data

Gravity Forms official guidance specifically warns about pages where forms collect personal data. If the form requires a logged-in user or relies on dynamic population, those pages should not be cached carelessly. That matters for CRM forms because caching can expose an outdated token, stale values, or break nonce validation. If submissions start failing intermittently after migration, review the cache exclusions for the form page.

Files and Attachments

If the old form accepted file uploads, do not send them to the new CRM without a separate decision. Every CRM has its own limits on file size, file types, and storage. In Gravity Forms, keep allowed extensions as narrow as possible, do not use the form for sensitive documents, and verify who can download the attachment. If the sales team does not need attachments, it is better not to send them to an external service at all.

Practical Ways to Reuse the Logic of the Old Batchbook Feed

Even if Batchbook itself is no longer the live destination, the old integration can still suggest useful patterns for a new CRM architecture. The key is not to copy it blindly, but to turn it into clear rules: which form creates a lead, which one updates a contact, when a submission should not go to sales, and which fields the manager needs for the first response.

Consultation Request for a B2B Site

Use the old mapping for name, company, email, and comment as the basis for the new CRM feed. The trigger condition can depend on the selected service or a checkbox such as "I want someone to contact me." Verify the result both in the new CRM record and in the Gravity Forms entry. If the manager still lacks context, consider adding a "Company size" or "Project type" field, but align that with the sales team first.

Separating Sales from Support

One form may collect several types of inquiries. The old Batchbook feed probably sent only part of them to the CRM. Preserve that principle: sales goes to the CRM, support goes to a help desk or email notification, and partner inquiries go to a separate owner. Use conditional logic and multiple feeds for that, but always test negative scenarios as well.

Updating an Existing Contact

The official Batchbook announcement mentioned both contact creation and contact updates. During migration, check whether the new CRM supports updating an existing record by email. If it does, decide which fields can be updated automatically and which ones should remain under manual control. For example, phone number and comment may be safe to update automatically, while customer status or deal owner may depend on internal sales rules.

A Lead After Payment or Confirmation

If the form is tied to payment, do not create the CRM lead too early. The old Batchbook changelog mentions delaying processing until a successful PayPal Standard payment, and the idea still holds: the CRM should receive a qualified signal, not every attempted submission. In the new integration, look for built-in payment events or a feed delay setting if the chosen add-on supports it.

Archival Audit Before a Redesign

Before a site redesign, old feeds can reveal which forms actually mattered to the business process. You may discover a forgotten landing page that still collects leads, or a form that stopped sending data to the CRM long ago. That kind of audit helps you avoid carrying junk into the new site and prevents you from losing working lead sources.

Why the Integration Fails and How to Diagnose It

Diagnosing Gravity Forms Batchbook starts with accepting reality: if the receiving service no longer works, restoring full synchronization may be impossible. Even so, you still need to identify exactly where the chain breaks. That makes it easier to disable the old feed correctly, configure a replacement, and explain to the business why some older submissions never appeared in the CRM.

The Batchbook or Feeds Tab Does Not Appear

Symptom: the plugin seems to be activated, but the expected feed or menu item is missing from the form settings. Possible causes include the add-on not actually being active, missing user permissions, the form not supporting that add-on, a conflict with the theme or another plugin, or the old Batchbook Add-On being incompatible with the current environment.

Check the Plugins page, the user's role, Gravity Forms system status, and any PHP errors. On staging, temporarily disable other plugins and switch to a default theme. If the menu item appears, restore the extensions one by one. If it still does not appear, treat the old plugin as unsupported and migrate the logic based on form exports.

An Entry Is Created, but No CRM Contact Appears

Symptom: the user sees a confirmation, the entry exists, the email was sent, but there is no external record. In a feed-based workflow, that usually means the problem happens after the submission is saved: the feed is disabled, conditional logic did not pass, the entry was marked as spam, the credentials are invalid, or the external service is not accepting the request.

Open the feed and confirm that it is active. Then submit a test entry that definitely matches the condition and review the logs. If the logs show an error from the external service, do not randomly change form fields. With Batchbook, the correct conclusion may simply be that the old service is unavailable, which means the channel must be replaced rather than endlessly troubleshooting credentials.

Conditional Logic Filters Out the Wrong Submissions

Symptom: some tests go to the CRM and others do not, even though the form looks identical on the front end. The cause is often a choice field, a hidden field, outdated select values, or incorrect any/all logic. In some cases, the form was edited and a field label changed, while the feed still expects the old value.

Check the raw value in the submitted entry and compare it to the feed condition. Do not rely only on the field label shown on the public form. If the user sees "Consultation" but the stored value is consulting, the condition must test the actual value Gravity Forms uses. After fixing it, run both a positive and a negative test.

CRM Fields Are Mixed Up or Incomplete

Symptom: the contact is created, but the phone number ends up in a note, the company is missing, the name is blank, or the comment is truncated. Possible causes include incorrect field mapping, an incompatible field type, or a new CRM that requires a format the old Batchbook feed never used.

Compare the Gravity Forms entry with the CRM record. If the value exists in the entry but is missing in the CRM, the problem is in the mapping or the receiving service's limits. If the value is missing from the entry itself, the problem is in the form. For migration, it is safer to create a separate test form or a form copy than to disrupt the live workflow.

The Submission Goes to Spam and the Feed Never Runs

Symptom: the user submits the form, but no record reaches the CRM and the entry is sitting in the spam filter. Gravity Forms documentation states that configured feeds and notifications are not processed for spam submissions. That protects external services from junk data, but it can also make testing confusing.

Open the entry detail and review the spam note. It may identify the cause: honeypot, token, reCAPTCHA, an overly fast submission, or a third-party anti-spam tool. If it is a false positive, fix the anti-spam configuration, clear the form page cache, and test again. Do not fully disable protection on a live form that accepts public submissions.

The Form Became Slow After the Integration

Symptom: form submission noticeably waits for the external service to respond. In modern add-ons, background processing can move the feed into a separate request so the user sees the confirmation faster. But an older add-on may behave differently, and a discontinued external service may respond slowly or not respond at all.

Measure the form submission time on staging without the CRM feed. If the form is fast without the feed but hangs with it enabled, disable the old integration and replace it with a supported channel. For the new solution, confirm whether the add-on supports background feed processing and whether there are any constraints for your use case.

When It Is Better to Roll Back the Change

Roll back the change if enabling the Batchbook Add-On breaks the public form, triggers fatal PHP errors, stops entries from being saved, or prevents users from receiving confirmations. If the only failure is the connection to the external Batchbook service, do not roll back the entire form. Disable that specific feed, keep local storage enabled, and move on to the migration plan.

How to Choose a Replacement for an Outdated CRM Connection

Replacing Gravity Forms Batchbook should begin not with picking the most famous service, but with describing the actual workflow. Do you need a simple CRM contact, a lead with source tracking, a task for a manager, flexible automation across hundreds of services, or a direct webhook into your own system? The answer changes both the add-on choice and the support burden.

Create a short matrix:

• Which CRM the team is using now.
• Whether you need to create a contact, lead, deal, task, or several objects.
• Whether an existing contact should be updated by email.
• Whether you need attachments, custom fields, owner assignment, lead source, and status.
• Who will maintain the integration: a webmaster, marketer, developer, or the sales team.

If you need a native integration and Gravity Forms supports that CRM, an official add-on is usually the easiest option. If the CRM is uncommon or the workflow changes often, Zapier may be faster to configure. If the team has a developer and an API endpoint ready to receive data, Webhooks provides more control, but it also requires careful error handling and security.

On an older site that used Batchbook, do not try to recreate everything at once. Start with the minimum viable workflow: the submission is saved in Entries, a contact or lead is created in the new CRM, the source and comment are included, and the manager receives a notification. After that, you can add owner assignment, tasks, statuses, attachments, and segmentation.

When Gravity Forms Batchbook Is Still Worth Keeping on the Site

You should keep the old plugin in a live environment only for a clear reason and for a limited period. For example, you may be auditing the site, have not yet migrated the CRM workflow, but still need access to the feed settings. Or the client may have an archival site where the public form is closed and the plugin is needed only to review the old configuration. In cases like that, document the plugin's status in the project's technical records.

Do not keep the plugin active "just in case" if it serves no useful purpose. Any extra plugin increases the maintenance surface: updates, PHP compatibility, conflicts, access permissions, and possible logging errors. That argument is even stronger for an old add-on because official support has already been dropped.

A safe interim strategy:

1. Export the form and entries.
2. Save screenshots or a written description of the old feed.
3. Check whether there are any custom Batchbook snippets.
4. Set up the new CRM channel on staging.
5. Disable the Batchbook feed on the live site after successful testing of the new connection.
6. Remove the plugin only after taking a backup and getting approval from the process owner.

If you need the archive to analyze the old integration or restore a test environment, you can download the ZIP archive near the download section, but test it only on an isolated site copy and do not build a new CRM workflow around a discontinued service.

When to Use Gravity Forms Batchbook in Project Work

Today, Gravity Forms Batchbook should be treated as a tool for understanding an old architecture, not as the foundation of a new automation flow. It helps you see which forms used to send data into the CRM, which fields mattered, which conditions separated leads from ordinary messages, and where failures may have occurred. That is useful during audits, redesigns, sales process migrations, and old-site recovery.

For practical work, keep one short rule in mind: if you need a live CRM workflow, choose a supported integration; if you need to understand the old logic, inspect the Batchbook feed carefully on a site copy. That approach is more honest to the site owner and safer for user data.

Before making the final decision, verify three things: are entries being saved, is there a clear plan for the new CRM connection, and have the old feed settings been documented? If the answer is yes to all three, you can disable the outdated piece without rushing and move the workflow into a modern tool. If the answer is no, finish the audit first. Only then should you decide whether you still need the Gravity Forms Batchbook archive for a test environment or whether the project is ready to move on without it.