How to Trigger Email Alerts When Gravity Forms Table Data Changes

Updated July 2026 • 7 min read • By Fahad Murtaza

Gravity Forms is excellent at sending notifications on initial form submission. But what about when an entry is updated after the fact, when a status changes from Pending to Approved, or a score field is edited above a threshold? That requires a different approach. This guide covers how to wire Gravity Forms notifications together with TableCrafter's inline editing alerts to build a complete change-notification system. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on any page. WordPress plugin activation rates are highest in the first 48 hours after a feature update (WP Engine Developer Survey, 2024).

How Does Two Alert Systems, One Workflow Work?

Before configuring any alerts, clarify which system handles which type of event. Each system has a different trigger point and a different configuration location:

• Gravity Forms Notifications: Configured under Forms → [Your Form] → Settings → Notifications. Designed primarily for new-submission events. GF 2.5 and later includes an "Entry is Updated" event that fires on any entry update, including updates made through TableCrafter's inline editor, since TC writes to entries through the GF API. If you need a blanket notification on every edit regardless of what changed, a GF notification on "Entry is Updated" covers it. The downside is notification flooding if your table receives frequent small edits.
• TableCrafter Cell Change Alerts: Pro Configured under TableCrafter → Tables → [Your Table] → Edit → Alerts. Purpose-built for conditional post-submission notifications. Each alert rule specifies a field ID, an operator (greater than, less than, equals, contains, and others), a threshold value, and a recipient email. The alert fires only when an inline edit causes the value to cross the threshold for the first time, not on subsequent edits where the threshold is already met.

The strongest setup uses both systems for complementary purposes: GF handles the initial submission notification, TableCrafter handles conditional post-submission change alerts based on specific field values and thresholds. The two systems do not overlap because they serve different trigger moments in the data lifecycle.

After completing this step, verify the result by viewing the page as a logged-out visitor in an incognito window. This confirms the table behaves correctly for public visitors rather than reflecting admin-level permissions that may hide configuration issues during initial setup. Check both the rendered output and the browser console for any JavaScript errors.

How Do I Set Up Gravity Forms Entry Updated Notifications?

Gravity Forms 2.5 and later includes an "Entry Updated" event that can trigger a notification. Here is how to configure it:

1. Go to Forms > [Your Form] > Settings > Notifications.
2. Click Add New to create a new notification (do not modify your existing submission notification).
3. Set the Event dropdown to Entry Updated (in GF 2.5+, this event is labeled "Entry is Updated").
4. Set the Send To field to the email address or merge tag for the recipient. For an approval workflow, this might be the submitter's email: {entry:3} where field 3 is their email.
5. Write the notification subject and body. Use GF merge tags to include the updated values: {entry:status_field_id} pulls the current value of your status field.
6. Save the notification.

This notification fires on any entry update event, whether triggered from wp-admin, via GF API, or via TableCrafter's inline editor (since TC uses the GF API to save changes). That is intentional: the GF notification does not care what triggered the update, only that an update happened.

What Is TableCrafter Cell Change Alerts: Targeted Notifications?

TableCrafter's alert system is more surgical than a blanket GF notification. Instead of firing on every entry update, you define rules that fire only when a specific condition is met on a specific field. For example: "send an alert when the Status field equals Approved" or "send an alert when the Score field is greater than 90."

Each alert rule consists of four required fields: a field ID (the Gravity Forms field to watch), an operator (the comparison type: greater than, less than, equals, greater-than-or-equal, less-than-or-equal, or contains), a threshold (the comparison value, such as "Approved" or "90"), and a recipient email address. An optional attach_csv flag attaches a CSV export of the full table to the alert email when enabled.

The alert fires only at the crossing moment: when an inline edit causes the field value to satisfy the rule for the first time. If the value already satisfied the rule before the edit, no alert fires, preventing repeated notifications on unchanged crossings. Navigate to TableCrafter → Tables → [Your Table] → Edit → Alerts and click Add Alert Rule to configure each rule.

How Does Alert Trigger Types Work?

Value Match Trigger

Use the equals operator (=) to fire an alert when a specific column's value changes to a specific text or number after an inline edit. The alert fires only when the new value satisfies the equals condition AND the previous value did not already satisfy it.

Configuration example:

• Field ID: the Gravity Forms field ID for your Status field
• Operator: = (equals)
• Threshold: Approved
• Recipient: the notification email address

This alert fires when an editor changes any entry's Status cell to "Approved." It does not fire when Status changes to "Pending" or "Rejected" (different values), and it does not fire again if the Status is already "Approved" and an editor saves without changing it. The threshold match is case-sensitive: "approved" (lowercase) will not match a threshold of "Approved." If your Status column uses a Gravity Forms dropdown field, the values are constrained to the dropdown choices, which reduces the risk of case mismatches during inline editing.

Value Change Trigger (Any Change)

To fire an alert when a field changes to any value different from its current one, use the contains operator with a threshold that all possible new values share. There is no separate "any change" rule type; the closest approximation uses the available operators against the expected data format.

Configuration example using contains for an email-address field:

• Field ID: the Gravity Forms field ID for your Assigned To field
• Operator: contains
• Threshold: @company.com (a string present in all valid assignee email addresses)
• Recipient: the team notification inbox

This fires when the Assigned To field is changed to any value containing the threshold string. If you need a true "any change" alert regardless of the new value, the most reliable approach is to create a GF "Entry is Updated" notification scoped to the specific field using GF conditional logic, since TC alert rules require a threshold value to evaluate against and cannot match an arbitrary change without a common string to match on.

Numeric Threshold Trigger

Use a numeric comparison operator to fire an alert when a numeric column's value crosses a threshold after an inline edit. The alert fires only at the crossing moment: when the new value satisfies the condition AND the previous value did not. If a field already has a value above the threshold and an editor saves a new value that is also above the threshold, no alert fires because the crossing happened on a previous edit.

Configuration example:

• Field ID: the Gravity Forms field ID for your Score field
• Operator: > (greater than)
• Threshold: 90
• Recipient: senior-reviewer@company.com

This alert fires when an editor saves a score above 90 for the first time on that entry, but not for scores of 90 or below, and not on subsequent edits where the score remains above 90. Supported operators are: >, <, =, >=, <=, contains. Practical use cases include SLA breach alerts when a response time field exceeds an agreed limit, budget overrun notifications when a cost field exceeds a project cap, and quality score flags when a review score falls below an acceptable minimum threshold.

How Does Alert Recipients Work?

Each alert rule has a recipient field that accepts a single email address per rule. The address is validated when the rule is saved; invalid email addresses are silently dropped from the saved rules array. To notify multiple people for the same alert condition, create one alert rule per recipient with identical field ID, operator, and threshold settings. You can also add a CC or BCC by configuring a second rule with the same trigger but a different recipient address.

The column mapping you define here is stored as a JSON configuration in the WordPress database. You can export this configuration using the TableCrafter export tool and import it to another table or another site. This is useful when replicating a table layout across multiple pages or when migrating a table to a staging environment for testing before going live.

• Static email: A hardcoded email address. Use for team-wide alerts (e.g., team@company.com for approval notifications).
• Entry field value: Pull the recipient email from a field in the entry being updated. Use {field_id:3} syntax. This sends the alert to the specific person who submitted the entry being updated, ideal for applicant notifications.
• WordPress user: Select a specific WordPress user account by name. Useful for single-point-of-contact alerts.
• User who made the edit: Sends the alert back to the TableCrafter user who triggered the cell change. Useful as a confirmation receipt.

How Does Alert Message Templates Work?

Each alert rule has a subject and body template. TableCrafter provides merge tags specific to the alert context:

• {tc:field_label}, The label of the column that changed
• {tc:old_value}, The previous value before the edit
• {tc:new_value}, The value after the edit
• {tc:editor_name}, Display name of the WordPress user who made the edit
• {tc:entry_url}, A direct link to the GF entry in wp-admin
• {tc:table_url}, A link to the frontend table page

Standard GF merge tags ({entry:field_id}) are also available to pull other field values from the entry, so your alert email can include the applicant's name, their original submission data, and the new status, all in one message.

An example alert subject: Application {entry:1} status updated to {tc:new_value}. An example body:

Hi {entry:first_name},

Your application status has been updated.

Previous status: {tc:old_value}
New status: {tc:new_value}
Updated by: {tc:editor_name}

View your application: {tc:table_url}

How Do Combining GF Notifications and TC Alerts Work?

A complete workflow for an application review system:

1. GF Submission Notification: Sends a "We received your application" email to the applicant on initial submission.
2. TC Alert, Status = Under Review: Sends "Your application is being reviewed" to the applicant's email field when a reviewer changes Status to "Under Review."
3. TC Alert, Status = Approved: Sends "Congratulations, you are approved" to the applicant and a CC to the account manager.
4. TC Alert, Status = Rejected: Sends a rejection email to the applicant with a link to reapply.
5. TC Alert, Score > 95: Sends an internal alert to a senior reviewer flagging a high-scoring application for expedited review.

Each of these is a separate alert rule in TableCrafter's Alerts configuration panel. GF handles step 1 via its native notification. TC handles steps 2 through 5.

TableCrafter re-fetches this data on each page load by default. If your data source updates infrequently and your site has significant traffic, enable the built-in caching option in the table's Performance tab. This stores the fetched data for a configurable number of minutes and serves it from WordPress transients, reducing API calls to the source and improving page load time for visitors.

How Does Testing Alert Rules Work?

To verify an alert rule is configured correctly, make a real inline edit in the frontend table that satisfies the trigger condition. Edit a cell so its value crosses the configured threshold: change a Status cell from "Pending" to "Approved" for an equals-Approved rule, or change a Score cell from 85 to 95 for a greater-than-90 rule. Check the recipient inbox within a few seconds. The email subject follows the format: [TableCrafter Alert] Field "{label}" crossed threshold on table "{title}", which confirms the field label and table name resolved correctly.

If the alert email does not arrive after a confirmed threshold crossing, verify these three areas: first, confirm the Gravity Forms field ID in the alert rule matches the actual field ID of the column you edited (check under Forms → [Your Form] → Form Editor and hover over the field to see its ID badge); second, confirm the WordPress site can send email at all by sending a test email via WP Mail SMTP or a similar diagnostics plugin; third, check whether the old value was already above the threshold before the edit, which would prevent the alert from firing since it only triggers at the crossing moment and not on repeated crossings of an already-satisfied condition.

What Are the Next Steps?

With a notification pipeline in place, your Gravity Forms data table is a complete operational system: users submit via the form, reviewers update records via inline editing in the frontend table, and the right people are notified automatically at each status transition, all without writing a line of custom PHP or JavaScript.

Consider these extensions to the notification system:

• Add a scheduled export using the attach_csv option on an alert rule. This sends a CSV of the full table to a recipient on a recurring schedule, giving stakeholders a regular data snapshot without needing to log into the site.
• Configure additional alert rules for each stage of your workflow. An application review pipeline might have separate rules for "Under Review," "Approved," and "Rejected" status transitions, each with a different recipient and message body.
• Combine TC alerts with GF's "Entry is Updated" notification for a belt-and-suspenders approach: TC handles conditional targeted alerts, while GF provides a blanket audit trail notification to administrators who need to track every change regardless of field or value.