//

Melvin Wong

When you rely on Gravity Forms, your site collects a lot of useful data. The problem is getting that data back out in a way people can actually use.

Most of the time, you do one of three things:

  • Open the Entries screen and scroll.
  • Export a CSV and filter it somewhere else.
  • Ask someone with admin access to “check the form.”

GravityOps Search exists to break that pattern.

It gives you a shortcode that can search your Gravity Forms entries and display the results on any page, post, or GravityView layout. You set the rules, and the shortcode pulls the right entries and shows only the fields you care about.

This guide will walk you through how to use GravityOps Search in a practical way, so you can stop digging in entries and start getting answers where you actually need them.

One Clear Question Per Shortcode

The easiest way to think about GravityOps Search is this:

Each shortcode should answer one clear question.

For example:

  • “What is this person’s latest submission status?”
  • “Which people have sent in a form today?”
  • “Who is still missing a required document?”

When you write a shortcode with one question in mind, three things happen:

  • It is easier to read and understand later.
  • It is simpler to test, because you know what “correct” looks like.
  • You can copy and reuse it for similar questions.

A simple rule of thumb:

  • If you are really asking two different questions, use two different shortcodes.

You will still put them on the same page if needed, but each one stays focused.

Start With the Right Use Cases

You do not have to solve everything at once. Pick a few places where you already feel the pain of checking entries by hand.

Good starting points:

  • You keep getting messages like “Can you check if my form went through?”
  • A staff member opens the Entries screen every day to see what came in.
  • A program lead wants a list of people who have not finished a step.

Choose three to five small wins, such as:

  • A page where people can check their own status.
  • A staff-only page that lists the latest submissions.
  • A “missing info” list that shows who still has an empty field you care about.

If you start here, you will see value quickly and learn how the plugin behaves without getting stuck in complexity.

The Three Core Pieces: Target, Search, Display

Every GravityOps Search shortcode has three basic parts:

  1. Target – where to look
  2. Search – which entries count
  3. Display – what you want to show

You do not need to memorize attribute names to understand this. Just keep the questions in mind.

1. Target: Which forms should it search?

You decide which forms the shortcode will read from. For example:

  • One specific form (for a single process)
  • A small set of forms (if a process spans more than one)
  • In some cases, all forms, if that makes sense for your use case

Think about it like this:

“When I answer this question, which form or forms do I normally open?”

Those are the ones you should target.

2. Search: Which entries should be included?

Next, you define the match rules:

  • You can match on field values (like email, ID, or status).
  • You can match on entry details (like date or payment status).
  • You can use basic conditions, like:
    • equals
    • does not equal
    • contains
    • greater than / less than (for numbers or dates)

GravityOps Search lets you combine more than one condition when needed, so you can be specific.

In plain language:

“Show me entries from Form X, where Field Y has this value, and Field Z is blank or set to that status.”

3. Display: What should the shortcode output?

Finally, you decide what gets shown on the page:

  • You pick which fields to include in the output.
  • You choose the order they appear in.
  • You can wrap them in simple HTML to make:
    • a bullet list,
    • a basic table, or
    • a short inline summary.

The result might be:

  • A clean list of names and dates.
  • A simple table with name, email, and status.
  • A one-line snippet like “Your current status is: Approved.”

Keep this mental checklist:

  • Target: where am I looking?
  • Search: which entries count?
  • Display: what do I want to show?

Example Pattern 1: A Simple “Lookup” Page

A common use case is letting someone check their own status without emailing you.

Basic idea:

  • You already collect some unique or near-unique value, like:
    • email address
    • student ID
    • application number

You can:

  1. Create a small form where they enter that value.
  2. Pass that value into a GravityOps Search shortcode on a results page, for example by using Gravity Forms merge tags or another shortcode that reads a URL parameter.
  3. Use the shortcode to:
    • target the right form,
    • search for entries that match that ID or email, and
    • display only the fields that make sense for the user to see.

For example, you might show:

  • “Submission date”
  • “Program applied for”
  • “Current status”

You do not need a big table of every field. Just show the details that answer the user’s question: “Did you get my submission, and where does it stand?”

Example Pattern 2: A Basic “Staff View” Page

Your internal team often needs a quick view of recent entries. Instead of sending them to the Entries screen, you can create a simple staff page.

Steps:

  1. Decide which form or forms matter most for daily work.
  2. Choose the fields they need at a glance:
    • name
    • contact info
    • date submitted
    • status or key choice field
  3. Use GravityOps Search to:
    • target those forms,
    • search for entries that match your criteria (for example, all entries, or only entries in a certain status), and
    • sort them in a useful order, such as the most recent submission first.
  4. Optionally filter by a date field so you only see recent entries, for example entries from the current day or week, based on the conditions you set.

Then place this view on a page that only logged-in staff can see.

This gives your team a live, focused view of what is happening, without training them on the full admin interface.

Example Pattern 3: “Missing Info” Lists

Another powerful pattern is finding entries where something important is missing.

For example:

  • A required upload was left blank.
  • A follow-up form has not been completed.
  • A certain checkbox or confirmation field is still empty.

With GravityOps Search, you can:

  1. Choose one key field that must not be empty.
  2. Use the plugin’s support for searching empty fields to return only entries where that field is blank.
  3. Display a short list with:
    • name
    • email or phone
    • any other detail that helps you follow up

This turns “hidden gaps” in your process into a clear list. You can then email or call the people on that list and close the loop.

Make Your Shortcodes Easy to Maintain

As you build more uses, you will have multiple shortcodes across different pages. It pays to keep them organized.

Some simple habits:

  • Give each shortcode a clear purpose in your notes, like:
    • “Lookup – scholarship status”
    • “Staff – daily support submissions”
    • “Cleanup – missing document upload list”
  • Store them somewhere central:
    • Create a “Shortcodes” reference page in WordPress that only admins can see, or
    • Keep them in your internal documentation with a short description.
  • Reuse working patterns:
    • When you need a similar view, copy a shortcode that already works and change only what you must:
      • the target form ID,
      • the field IDs,
      • and the labels in the display markup.
  • When you change form fields:
    • Remember that field IDs can change if you rebuild or replace fields.
    • Update any shortcodes that depend on those IDs as part of that work, so the output does not break.

These steps save you from guessing “where did we use that shortcode?” months later.

Common Mistakes to Avoid

A few problems show up again and again. You can avoid them with simple rules.

  1. One shortcode trying to do too much
    If the shortcode is trying to answer three questions at once, it becomes hard to read and maintain.
  • Fix: split it into separate shortcodes, each with one clear purpose.
  1. Showing too many fields

If your output looks like a full export, people will not read it.

  • Fix: start with the few fields that matter most. Add more only when someone asks for them.
  1. Ignoring privacy and access

Internal views should not be public.

  • Fix: put staff pages behind login or other access controls, just as you would for any other internal content.
  1. Overthinking sorting

You do not need complex sort logic for most cases.

  • Fix: pick a simple main sort key, like entry date or entry ID, and a clear direction (newest first, or alphabetical). Adjust further only when you have a real need.
  1. Not testing against real entries

It is easy to assume a shortcode is correct when it is not.

  • Fix: for each new view, compare the results against the Gravity Forms Entries screen at least once. Make sure the number of entries and key values match what you expect.

Keep Your Searches Useful Over Time

Once you have a few GravityOps Search views in place, do light maintenance from time to time.

Every month or quarter:

  • Check which pages people still use.
  • Remove or archive search pages that no longer match your current processes.
  • Update any views that point to old forms, retired fields, or outdated statuses.

When you launch a new form or workflow, ask a simple question early:

“Do we need a search or display view for this?”

If the answer is yes, reuse one of your standard patterns:

  • a lookup page,
  • a staff list, or
  • a “missing info” list.

Over time, you will build a small, stable set of search views that your team trusts and uses every day.

Conclusion: Make Your Gravity Forms Data Work for You

GravityOps Search does not replace Gravity Forms or GravityView.
Instead, it gives you a focused way to:

  • search entries based on clear rules, and
  • display just the information people need, right where they need it.

If you keep to a few simple habits:

  • one clear question per shortcode,
  • clear targets, filters, and displays, and
  • a handful of reusable patterns,

you can turn your forms data from something you dig through into something you actually use.

A good first step is to pick one process where you keep opening the Entries screen by hand. Replace that manual check with a GravityOps Search page. Once that is working, expand to staff views and missing-info lists.

From there, your Gravity Forms entries stop being a pile of data and start becoming answers.

[code_snippet id=23 name="GravityOps Search Download" format shortcodes]

Get GravityOps Search

GravityOps Search – Search and Display Gravity Forms Entries
GravityOps Search – Search and Display Gravity Forms Entries
Version 1.0.1 Requires WP 6.5 Requires PHP 8.0 135+ downloads Last updated November 26, 2025

Search Gravity Forms entries on the front end and display matching results anywhere. Filter by any field value. Output custom formatted data.

GravityOps Search is a free, powerful shortcode for searching Gravity Forms entries on the front end and displaying the matching results anywhere on your site. Instead of paging through the admin entries screen, you can drop a single shortcode into a page, post, GravityView, or custom template and surface exactly the data you need. It works like an Excel-style lookup for Gravity Forms entries: you define which forms and fields to search, how to compare the values, and what to output for each match.

The core [gravops_search] shortcode lets you target one form, several forms, or even all forms at once. You can filter by one field or many, pass in values directly in the shortcode content, and control whether entries must match all conditions or any of them. The same shortcode can handle simple lookups (showing a single field from the latest matching entry) or more complex reporting-style views that combine fields, entry properties, and custom HTML. Because everything is driven by attributes, you stay in full control of which entries are included and how their data appears on the front end.

Results are rendered through a flexible display attribute, which understands both simple comma-separated field lists and advanced custom display strings with placeholders. You can output raw values, mix multiple fields into labeled text, or construct HTML lists, tables, and cards with links, CSS classes, and nested shortcodes. This gives you a fully custom front-end listing of Gravity Forms entries that you can drop into any layout, theme, or builder, without building a custom query or touching PHP.

GravityOps Search fully supports Gravity Forms entry properties (such as entry ID, form ID, created-by, and more) alongside regular fields, and it includes options for sorting, limiting, and deduplicating results before they are rendered. You can sort by field values or entry properties, choose ascending, descending, or random ordering, add a secondary sort key, and request unique values only. When no entries match, you can show fallback text or per-field default values, so front-end visitors never see a broken layout or confusing blank output.

This plugin is built explicitly for front-end entry search and display. It does not add live search tools to the Gravity Forms admin area and does not replace the Entries screen. Instead, it focuses on one thing and does it well: querying Gravity Forms entries in the background and printing clean, formatted results on the pages your users actually see.

Features

  • Front-end search for Gravity Forms entries using a single, flexible shortcode.
  • Target all forms, a single form, or a comma-separated list of form IDs using the target attribute.
  • Filter entries by a comma-separated list of field IDs or entry properties via the search attribute.
  • Pass search values in the shortcode content, separated by a pipe (|) to match positions with the fields in search.
  • Choose whether entries must match all search conditions (default) or any condition by setting search_mode=\"any\".
  • Use the operators attribute to control how each value is compared to its field, with support for equals, not-equals, partial matches, SQL-style LIKE, “in” / “not in” arrays, and numeric comparisons (greater than / less than / greater-or-equal / less-or-equal).
  • Display one or many fields and properties for each result using the display attribute, which supports both simple lists and rich custom templates.
  • Include entry properties and field values in your output using placeholder formats like {13}, {id}, {form_id}, and {gos:id} where appropriate.
  • Build fully custom HTML output (lists, tables, cards, badges, buttons, links) directly inside the display string.
  • Insert CSS classes and inline markup into the output so results adopt your theme’s design and layout patterns.
  • Use the separator attribute to control how multiple entry results are separated (including HTML separators or no separator at all using __none__).
  • Sort entries using sort_key, sort_direction, and sort_is_num, with optional secondary_sort_key and secondary_sort_direction for tie-breaking.
  • Limit the number of results returned with limit, including support for limit=\"all\" when you need to show every matching entry.
  • Turn on unique to return only unique result values, great for building deduplicated lists such as unique email addresses, user IDs, or other fields.
  • Search for empty or blank values with the search_empty attribute and an empty shortcode content, to find incomplete or missing data.
  • Provide fallback values when no entries match—or when individual fields are empty—using the default attribute.
  • Add an admin link to each result with the link attribute so power users can jump directly from the front end to the entry in the Gravity Forms admin.
  • Designed to work smoothly alongside GravityView, GravityMath, and other shortcodes that can be nested inside the output.
  • Compatible with the legacy gfsearch snippet approach while offering ongoing updates and a more robust, plugin-based implementation.

How It Works

At its core, GravityOps Search evaluates your shortcode attributes and content to determine which entries to fetch, then formats each matching entry according to the display string you provide. The target attribute defines which forms to query: pass 0 to search all forms, a single form ID to target one form, or a comma-separated list of IDs for multi-form searches. The search attribute specifies the field IDs and entry properties to filter on, and the shortcode content supplies the corresponding values, separated by the pipe (|) character in the same order.

You can configure the search_mode attribute to determine matching logic. The default mode (all) requires each entry to satisfy all conditions, while search_mode=\"any\" returns entries that meet at least one of the conditions listed. This gives you the flexibility to build both strict, multi-field filters and more permissive, keyword-style searches. If you need to perform a global search across all fields for a given value, you can leave the relevant search ID blank, and the plugin will look for that value anywhere in the entry.

Sorting, limiting, and uniqueness are handled after the search conditions are applied. You can specify a sort_key (field ID, entry property, or meta key) with sort_direction set to ASC, DESC, or RAND. If you are sorting by numeric data, sort_is_num ensures values are compared correctly rather than as plain strings. When you need a consistent secondary ordering—such as sorting first by date and then by name—you can use secondary_sort_key and secondary_sort_direction. Once ordered, the plugin applies the limit attribute to control how many entries are actually returned and optionally filters down to unique results based on the full rendered output when unique is enabled.

Defaults and fallbacks keep your front-end output robust. The default attribute can define text to display when no entries are found or when specific fields are empty, and the plugin can handle multiple default values mapped to multiple display fields. The separator attribute governs how multiple entries are joined, making it easy to build line-separated lists, HTML elements, or table rows. Because each [gravops_search] shortcode runs its own live database query, you can place different instances around your site to build different views of the same underlying Gravity Forms data.

Display and Formatting

The display attribute is the heart of how results are shown. In its simplest form, you can pass a comma-separated list of field IDs or entry properties, such as display=\"13,14,15\". For each matching entry, GravityOps Search outputs those values in order, using sensible default separators between fields and entries. This mode is ideal when you simply need to surface raw values: a quick list of email addresses, a set of IDs, or basic single-column output.

For more control, display supports custom display strings with placeholders. Instead of a list of IDs, you can provide a template like display=\"Name: {13}, Email: {14}\", which will be rendered for each matching entry. Placeholders like {13} insert the value of field 13, while placeholders such as {id} and {form_id} work with entry properties. When you need to reference non-numeric properties or use merge tags in contexts that parse standard tags (such as GravityView content fields, confirmations, or notifications), you can use the special {gos:id} syntax. This gives you a consistent way to assemble complex messages, labels, and markup that incorporate both field data and meta data.

The display attribute also accepts full HTML, including tags, attributes, and CSS classes. You can wrap values in ,, ,, “, or any other markup to build lists, tables, cards, or media objects. Because the separator attribute supports HTML as well, you can structure your markup so that each entry becomes one list item, table row, or card component. This makes it straightforward to integrate entry results into existing sections of your design, matching your theme and layout without a custom PHP query.

Nesting Shortcodes and Advanced Templates

GravityOps Search supports nesting other shortcodes inside the display attribute via a double-curly-brace syntax: {{ ... }}. This means you can embed tools like GravityMath, another gravops_search, or any other shortcode directly inside the output template for each entry. The outer [gravops_search] processes its own placeholders first and then hands the rendered string to the nested shortcodes, allowing you to feed entry values into calculations, secondary lookups, or formatting helpers.

When you nest a second gravops_search inside the display attribute, each shortcode runs its own search and display logic in sequence. The outer shortcode resolves placeholders such as {13} and {gos:id} in its display string, while the nested shortcode uses its own display template and attributes. In nested scenarios where you need to reference placeholder values as input to another shortcode or formula, you can use the gos:id pattern without braces (for example, gos:21) to avoid conflicts with merge-tag parsing. This lets you do things like passing a field value into a GravityMath filter or dynamically controlling filters and IDs inside the nested shortcode configuration.

Because nested shortcodes are fully supported and the plugin respects all standard shortcode attributes, you can construct sophisticated, layered outputs without custom PHP. For example, you can build a front-end summary that uses one [gravops_search] to list matching entries, another to pull related entries, and a GravityMath shortcode to compute totals—all wrapped in your own HTML structure. GravityOps Search handles placeholder substitution and nested processing order so that each piece of your template receives the data it needs at the right time.

Search Operators and Multi-Input Fields

The operators attribute lets you tell GravityOps Search exactly how to compare each search value against its corresponding field or property. You define a comma-separated list of operators that line up with the IDs in the search attribute. Supported operators include equality (= or is), inequality (!=, isnot, is not), partial matches (contains), SQL-style wildcard matches (like), membership tests (in, not in), and numeric comparisons (gt, lt, gt=, lt=). If you provide fewer operators than search fields, remaining fields default to exact matches; extra operators beyond the number of fields are ignored. When you omit operators entirely, all fields use exact matching by default.

For more advanced scenarios, certain operators expect specific value formats. When using in or not in, for example, you can pass a PHP-style array in the shortcode content—such as array(\'item one\',\'item two\',\'item three\')—to test whether the field value appears in that list. This makes it easy to filter entries against multiple acceptable values for a single field without duplicating field IDs. Combined with search_mode, you can express a wide range of conditions: from strict multi-field comparisons to flexible multi-value lists and keyword-style filters.

Multi-input Gravity Forms fields (like Name, Address, and Checkbox fields) are fully supported, but they behave differently for display versus search. When displaying, using the base field ID in a placeholder (e.g., {13}) automatically combines all sub-inputs (such as first name and last name) into a single string separated by spaces. If you need to display a specific sub-input—like first name only—you can use its input ID directly, for example {13.3}. When searching, checkboxes are best handled by searching the base field ID so that changes to individual options or dynamic checkboxes do not break the search. Other multi-input fields (like Name and Address) should be searched using their individual input IDs (e.g., 13.3, 13.6), as searching by the base ID will not work for those types.

Performance and Access Control

Every [gravops_search] shortcode runs a live database query against Gravity Forms entries, so thoughtful usage is important for both performance and privacy. On the performance side, heavy use of limit=\"all\", many nested shortcodes, and large forms with complex conditions can slow down page loads. To keep pages responsive, it is recommended to set a reasonable limit where possible, minimize unnecessary nesting, and consider caching the rendered page output using your preferred caching plugin or server-level caching tools. These simple steps help ensure that even data-heavy views remain fast and reliable.

On the access-control side, the shortcode does not enforce any special permission checks by itself. Anyone who can view the page where the shortcode is placed will be able to see whatever Gravity Forms entry data you choose to display, including potentially sensitive information. To protect private or restricted data, you should place the shortcode inside pages or templates that are protected by membership plugins, password protection, role-based visibility, or other gating mechanisms. This keeps the plugin flexible and focused on data retrieval and formatting, while allowing you to decide how and where to expose entry data based on your site’s security model.

GravityOps Search is designed to be both powerful and predictable: you define the forms, fields, filters, and display template, and the plugin takes care of querying and rendering. Used thoughtfully, it becomes a core tool for building dynamic, entry-driven front-end experiences on top of Gravity Forms, without custom development or complex integrations.

  • Search across Gravity Forms
  • Display results any way you like