How to Map Gravity Forms Fields to Table Columns

Updated July 2026 • 8 min read • By Fahad Murtaza

Gravity Forms supports dozens of field types, and each one serializes its data differently in the database. TableCrafter's field mapper translates every field type into a readable table cell, but the defaults are not always what you want. This guide explains exactly how each field type renders and how to override it. 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. PDF export is requested by users in 64% of data-heavy WordPress plugin reviews (WordPress.org plugin directory analysis, 2025).

How TableCrafter Reads Gravity Forms Data?

When you select a Gravity Forms data source, TableCrafter queries the wp_gf_entry and wp_gf_entry_meta tables (the exact table names may include your configured database prefix). Single-input fields store their value under a numeric key like 1 or 3.2. Multi-input fields, Name, Address, Time, store sub-values under decimal keys such as 1.3 (first name) and 1.6 (last name).

The column builder in TableCrafter exposes these sub-keys as separate draggable cards whenever a multi-input field is present. This is the correct way to display them, dragging the parent card adds all sub-values concatenated into one cell, while dragging an individual sub-key card adds only that sub-value.

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 Single-Value Field Types Work?

Text, Textarea, Number, Hidden

These are the simplest cases. The stored value is a plain string or number. TableCrafter renders it as-is in the cell.

Number fields store plain numeric strings. There are no per-column decimal places, thousands separator, or currency format options in the table builder admin UI. If you need a specific numeric format displayed, pre-format the value at submission time using Gravity Forms' own number field format settings, or build a computed column using a formula expression that applies the desired formatting. The column's Text Alignment setting (General tab) lets you right-align numeric columns to match conventional table layouts without affecting the stored value.

Textarea fields render their full stored content in the cell. Column width and the Word-wrap Mode setting (in the column's General tab) control how overflow is handled visually. Setting Word-wrap Mode to "No wrap" clips long text to a single line with an ellipsis. Setting it to "Default" lets the cell expand to fit the content. Either option is non-destructive; the underlying Gravity Forms entry value is never modified by a display preference. For multi-paragraph responses, the entry detail popup (opened via the eye icon on the row) renders the full text without any truncation, making it the right place to read lengthy textarea submissions.

Date Field

Gravity Forms stores dates in YYYY-MM-DD format regardless of what the form's date picker shows the user. TableCrafter detects this format automatically and converts it to your configured display format. The global setting lives at TableCrafter > Settings under the Date Format field; the default output is m/d/Y (MM/DD/YYYY). That single setting applies to every date column in every table on the site, so changing it affects all tables at once.

There is no per-column date format override in the table builder admin UI. If you need two tables to display dates differently, the most practical approach is to store the date in the format you want via the Gravity Forms field configuration, or to apply a custom transformation via the gravity_tables_column_value WordPress filter hook, which fires for every cell value before output.

The date_created system column, which captures when an entry was submitted, is formatted directly in the table template using PHP's m/d/Y g:i A pattern. This system column bypasses the global date format setting and always renders the full date-plus-time stamp.

Time Field

Gravity Forms stores time values as a composite: the hour, minute, and AM/PM are saved in separate sub-keys (N.1, N.2, N.3 for hour, minute, and AM/PM respectively). When you add the parent Time field as a column in TableCrafter, the plugin automatically combines those three sub-keys into a single readable time string. The default rendering is a 12-hour format with AM/PM, for example 9:30 am or 2:15 pm. If the Time field on your form is set to 24-hour mode, the sub-keys store numeric values and TableCrafter composes them as 14:30 without an AM/PM suffix. There is no per-column time format toggle in the table builder admin UI. The composed value appears in the column cell as a plain text string. If you need time displayed differently, use a computed column or the gravity_tables_column_value PHP filter hook to reformat the value server-side before it reaches the table output.

Email Field

Email field values are rendered as plain text strings in the table cell. The value passes through esc_html(), which means the stored email address appears as readable text but is not automatically converted into a mailto: hyperlink. There is no "Mailto Link" toggle in the column settings admin UI.

If you want email addresses to appear as clickable links, the most reliable option is to use a computed column and construct the anchor tag markup there, or to apply the gravity_tables_column_value filter hook to wrap the email in an anchor before it reaches the cell renderer. The entry detail popup, accessible via the eye icon on each row, uses Gravity Forms' own display layer which may render email values with a mailto link, but the main table cells use the plain escaped string.

Website / URL Field

Website and URL field values render as plain text strings in the table cell, not as clickable hyperlinks. The stored URL passes through esc_html() and displays as a visible but unlinked string. There is no "Mailto Link", "Link Label", or automatic hyperlink toggle in the column settings admin UI for this field type.

To display URLs as clickable links in the table, use a computed column to construct an anchor tag, or apply the gravity_tables_column_value filter hook to wrap the URL in <a href="..."> markup server-side before the value reaches the cell. If a human-readable label is important (such as "View Website" instead of the raw URL), the filter hook approach is the right place to build that transformation, as it has access to both the raw value and the full entry record.

Phone Field

Phone field values render as plain text strings in the table cell. The value passes through esc_html() and displays the stored phone number exactly as it was entered into the form, with no automatic wrapping in a tel: anchor tag. There is no "Tel Link" toggle in the column settings admin UI.

For mobile-friendly tap-to-call behavior, apply the gravity_tables_column_value filter hook to wrap the phone number in a <a href="tel:..."> anchor before the value reaches the table cell renderer. Phone numbers in Gravity Forms are stored as entered by the user, so the format (with or without country code, dashes, or spaces) depends on your form's phone field mask settings. If consistent formatting matters for the tel: link to work reliably, use a GF number mask on the field to enforce a predictable pattern at submission time.

Select, Radio Buttons

Gravity Forms stores the selected value (not the label, if they differ). TableCrafter displays the stored value as a plain text string. If you configured GF field choices with separate values and labels (for example, value us with label United States), the cell will show us, not United States. There is no "Resolve Choice Labels" toggle in the column settings admin UI that maps stored values back to display labels.

To display the human-readable label instead of the stored value, the practical option is to configure your Gravity Forms field so the choice value and the choice label are identical. If they must differ, use the gravity_tables_column_value filter hook to inspect the raw value and substitute the desired label. The column also supports the Badge cell type via column settings > Cell type > Badge, where you can configure a badge color map keyed on the stored value, which is useful for status columns where us or pending should appear as a colored label without needing to change the underlying form configuration.

Drop Down (Select)

Drop Down fields behave identically to Radio Buttons: the stored value is the choice value, not the choice label. TableCrafter renders it as plain text. The same Badge cell type is available for this field type if you want to display choices as colored badges rather than raw text strings. Column-level filtering for Select and Drop Down fields is configured under the column's Filtering tab in the table builder, where you can set a dropdown filter that lets visitors narrow rows by the stored choice value. The filter dropdown is populated automatically from the distinct values present in the entries, so it reflects what users have actually selected without any manual configuration of filter options. This makes Drop Down and Select fields among the most straightforward field types to add column-level filtering to: enable the filter in the column's Filtering tab and save; the filter UI appears automatically on the frontend table.

How Does Multi-Value Field Types Work?

Name Field

The Name field stores each component under a sub-key:

• 1.2, Prefix (Mr., Ms., Dr.)
• 1.3, First name
• 1.4, Middle name (if enabled)
• 1.6, Last name
• 1.8, Suffix

In the TableCrafter column builder, dragging the parent Name card adds a single concatenated column. TableCrafter uses TC_Name_Field_Renderer::render_text() to compose all non-empty sub-key values into a space-joined string such as "Mr. John Smith Jr.", omitting the prefix and suffix if they are empty. This is the recommended approach for most display tables where you need the full name in one searchable column. Drag individual sub-key cards only when you need to sort rows by last name independently or display first name and last name in separate adjacent columns. Note that the 1.5 sub-key (first name in simple Name fields) may or may not be present depending on the GF field's "simple" vs "extended" name format configuration.

Address Field

The Address field sub-keys follow this pattern (assuming field ID 3):

• 3.1, Street address line 1
• 3.2, Street address line 2
• 3.3, City
• 3.4, State/Province
• 3.5, ZIP/Postal code
• 3.6, Country

When you drag the parent Address field card into the column list, TC_Address_Field_Renderer::render_text() collects all non-empty sub-key values for each entry and concatenates them into a single-line address string in the cell. This composed value works well for quick-reference tables where you need the full address in one column without the complexity of six separate columns. For maps integration or data export, dragging individual sub-key cards (for example, just city 3.3 or state 3.4) gives you cleaner sortable columns. Adding a separate city column also enables column-level filtering by city, which is not possible when all sub-values are merged into a single parent column.

Checkbox Field

Checkboxes are Gravity Forms' most nuanced field type. Each choice stores under its own sub-key (5.1, 5.2, 5.3...), and the stored value is either the choice value (if checked) or an empty string (if unchecked).

When you drag the parent Checkbox field card into your table's column list, TableCrafter collects all non-empty sub-key values for each entry and joins them into a comma-separated string in that single cell. A user who checked "Email" and "SMS" sees Email, SMS. Unchecked choices are omitted from the output. There is no "Checkbox Display" mode selector and no "Badge list" option in the column settings admin UI.

If you want one column per choice, drag the individual sub-key cards (5.1, 5.2, 5.3) separately from the field list. Each sub-key column shows the stored choice value (such as "SMS") if that choice was selected, or an empty cell if it was not. This layout works well for comparison-style tables where you need to see at a glance which options each submitter chose. The Badge cell type is available for individual sub-key columns and can be used to show a colored badge for the selected value or an empty state for unchecked rows.

List Field

Gravity Forms stores List field data as serialized PHP arrays. In the main table view, the list field value passes through esc_html() and renders as the raw serialized string, which is human-unreadable. The useful rendering happens in the entry detail popup (the eye icon on each row), where TC_List_Field_Renderer::render_as_text() deserializes the array and displays each row as a line of readable text. Multi-column list fields are handled automatically by the renderer, which reconstructs the column structure from the stored array without any configuration needed on your part.

There is no "Cell Display > List Mode > Table" toggle in the column settings admin UI, and there is no per-column setting to switch between serialized and readable output in the main table cells. If you need list field data readable in the table column itself rather than behind the detail popup, use a computed column or the gravity_tables_column_value filter hook to deserialize and format the array server-side before the value reaches the cell.

Fileupload Field

Single file uploads store the full URL to the uploaded file. TableCrafter renders this through TC_Cell_Renderer::render(), which detects the file type and renders image files as an inline thumbnail and other file types as a download link with a file icon. Multi-file uploads store a JSON array of URLs; the renderer handles both single and multi-file values automatically, rendering each file as a thumbnail or download link stacked vertically within the cell.

The fileupload renderer is the only field type in the main table template that goes through TC_Cell_Renderer directly. All other field types use esc_html() on the cell value. The entry detail popup uses a separate rendering path that passes through Gravity Forms' own GFCommon::get_lead_field_display() for most field types, so the detail view may render some fields differently than the main table cell.

How Do Calculated and Special Fields Work?

Product and Total Fields

Gravity Forms e-commerce fields (Product, Quantity, Shipping, Total) store numeric values. When you add a Product field as a column, TableCrafter's TC_Product_Field_Renderer composes a human-readable composite string that assembles the product name, quantity, unit price, and total price into a single cell value formatted as "Widget x 3 @ $10.00 = $30.00". This composition happens automatically in the entries query response before the value reaches the table template, so no per-column setting is required to trigger it.

There is no per-column "Currency Format" toggle in the column settings admin UI. The currency symbol and format come from the value as composed by the renderer based on Gravity Forms' own product field data. Total fields store the numeric total directly and render as a plain numeric string. If you need currency-formatted output for a Total column, apply the gravity_tables_column_value filter hook to prepend the currency symbol and apply your desired decimal format server-side.

Section and HTML Fields

Section and HTML field types in Gravity Forms are structural or presentational elements that display static content on the form. They do not collect or store user-submitted data, so they have no entry values to display in a table. TableCrafter excludes both types from the column builder; neither will appear in the available fields panel when you are configuring your table columns.

If your form uses Section fields as dividers, they will be silently skipped and will not cause errors or empty columns. HTML fields used for instructional text or disclaimers are likewise absent from the column picker. If you need to display contextual information alongside entry data, use a computed column to output a static string, or add a plain text annotation column separate from the GF field list.

Signature Field (GP Signature add-on)

Signature fields store a URL to the signature image generated by the Gravity Perks Signature add-on. In the main table cell, the stored URL value passes through esc_html() and displays as a plain text URL string. The entry detail popup uses Gravity Forms' GFCommon::get_lead_field_display(), which renders the URL as an <img> tag so the actual drawn signature is visible in the popup view.

There is no "Image Height" setting in the column card admin UI for controlling signature rendering in the table cell. If you want the signature to render as an image directly in the table rather than just showing the URL, use the gravity_tables_column_value filter hook to convert the stored URL into an <img> tag server-side. The plugin exposes a PHP filter gt_signature_max_height that controls the rendered image height (default 40 pixels) in the detail popup; this is a developer-level hook, not an admin UI setting.

The configuration you set here applies to every visitor who loads a page containing this table, regardless of whether they are logged in. Role-specific overrides for columns and rows are a separate layer and do not replace these global display settings. Apply global settings first, then add role restrictions as needed for tables that serve multiple user types.

How Does Overriding Column Labels Work?

Every column card has a Label text field in its General tab, pre-filled with the Gravity Forms field label at the time the column was added. You can change this to anything without affecting the underlying form field. The label change is local to the table configuration; the GF form field name, admin entry view, and data exports are unaffected. Common overrides:

• Rename "Input 1" (a GF default) to a meaningful label like "Project Description"
• Shorten long GF labels for narrow columns ("Emergency Contact Phone Number" to "Emerg. Phone")
• Translate labels for multilingual table displays

If a Gravity Forms form field's label is updated after the table is configured, the column label in TableCrafter does not update automatically; it retains whatever label was set in the column configuration at save time. To sync it with the new GF label, open the column card in the table builder, clear the Label field, and save; TableCrafter will re-read the current GF field label on the next builder load.

What Are the Next Steps?

With accurate field mapping in place, your table renders every Gravity Forms field type using the correct rendering path for each type. The natural next step depends on what your table needs to do for visitors.

If your table is a public-facing display, consider configuring column-level filters under each column's Filtering tab in the table builder. Select, Radio Button, and Drop Down columns support dropdown filters that let visitors narrow rows without writing any code. Checkbox columns work with text search filters against the composed comma-separated value.

If the table is for registered users who should only see their own submitted data, the next step is enabling the "Show user only their own entries" checkbox in the Filter by User section of the table builder. This is covered in the guide on filtering by current user data.

If you need visitors to correct or update entries directly from the table without going to the Gravity Forms admin, the inline editing feature is the right tool. Inline edit behavior is governed by per-column validation rules set in the column's Advanced tab, and the same field type rules described above determine which fields support inline editing and how values are sanitized on save.