How to Set Up Email Alerts for WordPress Table Data Changes

Updated July 2026 • 6 min read • By Fahad Murtaza • By Fahad Murtaza

Staying on top of data changes in a busy WordPress operation is a real challenge when you rely on manual check-ins. TableCrafter's email alert system automatically notifies you or your team the moment a table entry is created, updated, or deleted through the inline editor. This guide walks through every configuration option so your team never misses a critical change. 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. 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 with a [tablecrafter] shortcode or the native Gutenberg block. REST APIs handle over 83% of all web API traffic as of 2025 (RapidAPI, 2025).

What the Email Alert Feature Does?

Email alerts in TableCrafter are a Pro feature that triggers outbound notifications whenever a record in a connected table is modified through the plugin's interface. Changes captured include:

• Inline cell edits saved through the frontend table (writes performed via GFAPI::update_entry_field())
• Row deletions via bulk actions
• New entries submitted through a linked Gravity Form and reflected in the table

The alerts are sent using WordPress's built-in wp_mail() function, so they respect whatever mail configuration you have in place, whether that is the default PHP mail handler or an SMTP plugin like WP Mail SMTP or Postmark.

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 Prerequisites Before You Configure Alerts Work?

Before diving into the alert settings, confirm the following are in place:

• Active Pro license: Email alerts are not available on the free tier. Verify your license under TableCrafter → Settings → License.
• At least one published table: You need an existing table to attach alert rules to. If you have not built one yet, go to TableCrafter → Tables → Add New and connect a Gravity Forms data source.
• Working WordPress mail: Send a test email from Settings → General or your SMTP plugin's test tool to confirm deliverability before blaming alert config.
• Inline editing enabled on the table: Alerts for edit events only fire when the table's inline editing toggle is on. Open the table in the builder and confirm the Enable Inline Editing option is active under the Behavior tab.

How Do I Enable Email Alerts on a Table?

Each table has its own alert configuration, so you can send different notifications to different recipients depending on which dataset changed.

1. In the WordPress admin, go to TableCrafter → Tables and click Edit on the table you want to monitor.
2. In the table builder, locate the Alerts tab in the left-hand panel.
3. Toggle Enable Email Alerts to on.
4. In the Recipient Email(s) field, enter one or more addresses separated by commas. You can use static addresses or the placeholder {admin_email} to dynamically pull the site admin address from WordPress settings.
5. Set the From Name and From Email fields. These default to your site name and admin email but can be overridden per table.
6. Choose which events should trigger an alert: On Edit, On Delete, or On New Entry. You can select any combination.
7. Customize the Subject Line using available placeholders (see the next section).
8. Optionally write a custom Message Body. If left blank, TableCrafter sends a default message that includes the table name, the event type, the modified field labels, and the old and new values.
9. Click Save Table. Alert configuration is stored alongside the rest of the table definition.

How Do I Use Placeholders in Subject Lines and Message Bodies?

TableCrafter supports a set of dynamic placeholders so your alert emails carry meaningful context without requiring a custom template for every table.

Available placeholders:

{table_name}    , The display name of the table as configured in the builder
{event_type}    , "edited", "deleted", or "new entry"
{entry_id}      , The Gravity Forms entry ID that was affected
{user_name}     , Display name of the logged-in user who made the change
{user_email}    , Email of the user who made the change
{site_name}     , Your WordPress site name (from Settings → General)
{date_time}     , Timestamp of the event in the site's configured timezone
{changed_fields}, A formatted list of field labels, old values, and new values

A well-structured subject line might look like this:

[{site_name}] {table_name}, {event_type} by {user_name} on {date_time}

And a message body that gives the operations team full context:

A record in the "{table_name}" table was {event_type}.

Entry ID: {entry_id}
Changed by: {user_name} ({user_email})
When: {date_time}

Changes:
{changed_fields}

Log in to review the entry directly in WordPress.

How Does Controlling Alerts with Role-Based Permissions Work?

TableCrafter Pro's role-based permission system interacts with email alerts in a useful way. Because you can restrict which WordPress user roles are allowed to edit a given table (or even specific columns), you can design a setup where:

• Only users with the editor or a custom role can trigger inline edits in the first place.
• Alerts fire only when those permitted users make changes, preventing noise from unauthorized access attempts (which are blocked at the AJAX capability-check layer anyway).
• The {user_name} and {user_email} placeholders in the alert body always reflect the specific person who acted, giving you a clean audit trail without building a separate logging system.

Column-level permissions can hide sensitive fields from certain roles. If a role cannot see a column, they cannot edit it, and changes to hidden columns will not appear in their session's {changed_fields} output, keeping alerts scoped to what each user type can actually interact with.

How Does Troubleshooting Email Alerts That Do Not Arrive Work?

If you have configured alerts but emails are not arriving, work through this checklist in order:

1. Confirm WordPress mail is working at all. Use your SMTP plugin's built-in test, or install a temporary plugin like Check Email (check-email.info) to send a test message from wp-admin.
2. Verify the Pro license is active. A lapsed or invalid license silently disables Pro features. Go to TableCrafter → Settings → License and check the status indicator.
3. Check spam and promotions folders. Alerts sent via PHP's default mail handler frequently land in spam. Switching to an authenticated SMTP service (Postmark, SendGrid, Mailgun) resolves deliverability issues permanently.
4. Confirm inline editing is on. If the table is in read-only mode, no edits are possible and the alert trigger never fires. Open the table builder and check the Behavior tab.
5. Look at the browser console during an inline edit. TableCrafter's AJAX calls go to wp-admin/admin-ajax.php. A failed nonce or capability check returns a non-200 or a JSON error, if the edit itself is failing, the alert has nothing to act on.
6. Inspect the WordPress debug log. Enable WP_DEBUG_LOG in wp-config.php and attempt an edit. TableCrafter logs alert dispatch attempts and any wp_mail errors to wp-content/debug.log.