Gravity Forms List Dropdown - WordPress Plugin

How to Configure Gravity Forms List Dropdown for Repeatable Form Rows

Gravity Forms List Dropdown is useful when a regular text cell in a repeatable List field starts producing messy data. Visitors enter the same service name in three different ways, abbreviate it, add an extra space, or select something your team does not offer at all. The plugin changes how that cell is filled in: the selected column becomes a dropdown with a predefined set of allowed options. Visitors can add as many rows as they need, but in each row they can only choose from the values you have defined.

This guide goes beyond the add-on listing. We’ll look at how to tell when you need repeatable rows instead of a regular one-time dropdown, prepare a form, install the add-on, design its columns, configure choices, labels, and stored values, and then check submissions in entries and notifications. We’ll also cover the enhanced selection interface. Its search feature can be useful, but the developer explicitly warns that it creates accessibility problems for screen reader users and people who do not use a mouse.

We’ll use a service inquiry form as a running example. In each row, a visitor selects a service type from an approved list, enters a quantity, and adds a short comment. This example highlights what Gravity Forms List Dropdown does well: it is not a replacement for an entire form or a catalog with complex dependencies. It lets you fine-tune one or more columns in a repeatable data table.

Keep one rule in mind as you work: first define the list of values and what will be stored in the entry, then decide how it should look. A dropdown reduces typos, but it won’t fix unclear names, duplicate choices, or a poorly designed data model.

When a Repeatable Row Needs a Controlled Choice

The List field in Gravity Forms is designed for repeatable data: visitors can add and remove rows. It can have one column or several. In a single-column field, each row contains one value. In a multi-column field, each row groups a few related values. For example, a row might represent one requested service, with a service type, quantity, preferred date, and notes. The List field itself does not require users to choose from a predefined list, so free-form text can be too open-ended for categories, statuses, and fixed types of work.

Gravity Forms List Dropdown adds a Dropdown select mode to the column you choose. Instead of adding another free-text field, each new row gets a cell with a list of approved options. This is especially useful when a value will later be used to sort entries, populate notifications, export data, or support manual processing. Staff won’t have to guess what similar spellings were meant to say because the available choices are defined in advance.

Where the Add-On Works Best

The most natural use case is a single submission with several items of the same kind. It could be a request for several agency services, a list of rooms to inspect, several participants with the same set of details, a list of training categories, or an order row where the item name comes from a short, controlled list. The key is that the number of rows can vary: a visitor may need one row or five, and the site editor doesn’t want to create five identical field groups.

• Service request. Choose an audit, setup, consultation, or ongoing support in the Service Type column, while neighboring columns capture the quantity and a comment.
• Group registration form. Choose each participant’s role from a fixed list, then add a name or internal identifier.
• Technical requirements form. Add several items, but choose a category for each one from an approved list.
• Internal department form. Enter several tasks and choose an allowed status or category for each one without creating new options on the fly.

The add-on preserves the meaning of a List Field. The buttons for adding and removing rows still belong to the core Gravity Forms field; the add-on changes how the selected cells are filled in. So don’t expect it to behave like a full catalog, calculate prices, or build a hierarchical taxonomy. Its purpose is narrower and more useful: to keep values consistent within a repeatable list.

Who It Suits, and When to Choose Another Tool

Gravity Forms List Dropdown is a good fit for a site editor who already uses Gravity Forms and wants to configure a form without building custom dropdown markup for every row. It works well with short and medium-sized lists that visitors can scan quickly and understand. It is especially useful when the available choices rarely change and accurate data matters more than allowing visitors to enter any answer they want.

It is not a good fit when users need to add a value that is not already in the list. An older compatible add-on included a feature for adding undefined choices, but that feature is not listed for the current List Dropdown. Don’t try to work around this with a hidden "Other" option and no process for handling it. That would simply move the free-form text to the end of the list. If visitors need to leave an open-ended comment, keep a separate text column for it.

Also, don’t confuse fixed choices within a row with cascading fields. If the second list must change after a visitor makes a choice in the first one, such as "make - model - year," the Chained Selects add-on is a closer fit. It builds a sequence of dependent lists, while List Dropdown provides independent predefined choices within a repeatable row. Finally, if a column needs to hold a long note, an email address, or a value that requires pattern validation, look at tools for a text column instead of turning text into an artificial list.

A practical rule of thumb. List Dropdown is a good fit if you can define a clear set of allowed answers in advance and a visitor may choose several of them in separate rows. If the list depends on a previous choice or changes constantly through an external system, check other features and integrations first.

What to Check Before Installing or Changing a Live Form

Because the add-on works with a List field, the first check is about your data structure, not downloading a ZIP file. Open the existing form and write down what one row represents. If a row represents "one service in a request," every column should describe that service. If the first column contains a person’s name, the second contains a service name, and the third sometimes contains a date and sometimes a final price, adding a dropdown will only make the form look more organized. First separate the different entities into distinct fields or lists.

Make sure you are starting with a List field, not several copied Drop Down fields. Gravity Forms documentation describes List as an advanced field with rows that users can add or remove, and its multi-column mode supports column labels. The List Dropdown plugin configures those columns. If you need a single choice with no repeatable rows, use the standard Drop Down field. Adding a List would only make entries and notifications more complicated.

A Quick Planning Worksheet

Make a short working table in your team’s notes, not in WordPress. Answer four questions: what does the visitor see, what will be stored, who is responsible for updating the choices, and what happens when an option is no longer available? This preparation may seem slow, but it helps keep entries consistent when service names or statuses change.

Don’t change a live form immediately if it is already receiving submissions. Create a copy, open the preview, and submit several test entries. This matters not because the plugin itself poses a risk, but because changes to the available choices affect how data is interpreted. Older entries may contain text that is no longer among the new choices, and external processing may still expect the previous value.

Compatibility and the Limits of the Core Field

Keep a few List Field details in mind while designing the form. Gravity Forms stores its value as a serialized structure, not as a separate standard field for each column. Its documentation also says that the core List Field cannot be used in calculations and that conditional logic on other fields cannot be based on the List Field itself. So don’t build a critical workflow on the assumption that choosing a value in a row will automatically open another section of the form or recalculate a total without a separately confirmed solution.

Conditional logic can be useful alongside a List field, but you need to understand its limits. Fields hidden by conditional logic are not included in the submission and are not saved. If you use choice values in custom rules, settle those values before launch: changing a stored code means reviewing any rules that depend on it. For List Dropdown, this comes down to a simple rule: don’t tie critical processing to a polished human-readable label if you need a stable key.

Before installing, make a site backup using the method your project normally uses, confirm that you have administrator access, and test the form with the theme it will use on the live site. The plugin does not list a special integration with WooCommerce or the block editor. If the form is served through a cache, plan to test it in a private browsing window after clearing the cache. Visitors may not see the updated form interface right away even after the settings have been saved.

Install the Add-On and Check It in the Form Editor

Gravity Forms lists List Dropdown as a third-party GravityWP add-on and directs users to the developer for downloads and support. Start with a legitimate installation package from your account or the developer’s site. Don’t manually extract the ZIP before installing it through WordPress. The standard way to install a third-party add-on is to upload the original archive through Plugins > Add New > Upload Plugin, install it, and activate it.

If you use the built-in Gravity Forms add-on browser, note that the Forms > Add-Ons instructions apply to add-ons available through that browser and under the corresponding license. For a GravityWP product, the developer sets the process for purchase, updates, and support. You don’t need to include activation, license key, or payment details in a form setup guide. For the form editor, the important checks are that the add-on is active and that the new settings appear on the right field.

1. Create a backup of the form or a draft copy.
2. In the WordPress admin, open Plugins > Add New > Upload Plugin and select the ZIP archive you received.
3. Click Install Now, wait for the installation to finish, then choose Activate Plugin.
4. Open Forms, select the test form, and go to the form editor.
5. Add a List field or select an existing multi-column field.
6. Click the field and check that enable Dropdown select is available in the column settings.

Keep the first check local and limited: enable the dropdown for just one test column, add two or three choices, and open the preview. Don’t move a large list over or change every live field in one session. If the list appears in the preview, you can start designing the choices. If the setting is missing, first confirm that you selected a List Field and that the add-on is active, then check with GravityWP support.

Don’t judge success by how the WordPress admin panel looks. You need two observable results: the editor shows the allowed choices, and a new row on the public form gets the same dropdown. Add a row with the List Field button, choose the second option, remove the row, and add it again. This quick test checks both the initial display and whether the element initializes again after a user interacts with the form.

If the page contains several forms, test the one visitors actually use. The add-on’s changelog mentions fixes to enhanced interface initialization when multiple forms appear on a page. That is not a reason to expect a problem, but it is a good reason to test beyond the preview if the live page template also displays a contact form, subscription form, or another Gravity Forms block.

Map Your Columns: Where to Use Dropdown Select and Where to Keep Text Input

After installation, the most important decision is not whether to check a box, but which columns need a dropdown. A common mistake is to see that a dropdown is available and enable it everywhere. The result is a cumbersome form where visitors have to choose from lists even when it would be easier to enter a number, a short detail, or an address. It is more useful to use a closed list only for fields with a defined set of choices.

In a multi-column List Field, each row represents a small record. Consider the columns Service Type, Quantity, and Comment. The first has a finite set of choices, so it gets Dropdown select. The second needs to accept a number, so use an appropriate numeric input or clear text input with validation. The third stays as free text. This is not a compromise. It is the right way to divide responsibility between controlled choices and manual input.

How to Configure a Column

Open the List Field in the editor. If it has multiple columns, name them so both visitors and the people processing requests can understand them. Then select the target column, enable enable Dropdown select, and add the choices. GravityWP’s official documentation confirms that this works for both single-column and multi-column fields. You can enable the setting for one, some, or all columns.

Start with a small set of choices that you actually need for the upcoming workflow. This is not a demo limitation; it is a way to catch unclear names. If you can’t tell two choices apart without someone explaining them, the problem is with the list, not the form. Rename them before publishing. A useful choice answers the question "What exactly will be selected?" instead of hiding an internal team process.

Example Column Map for a Service Request

• Service Type - enable Dropdown select, with these choices: "Audit," "Setup," "Consultation," and "Ongoing Support."
• Quantity - use an input suited to a numeric value. Don’t fill a dropdown with words like "one," "two," and "three" unless there is a good reason.
• Comment - keep it as text so visitors can describe the context.
• Priority - add a separate controlled column only if the team actually uses fixed priority levels.

This list is easy to read on a narrow mobile viewport and in a notification email. Don’t hide business rules in the labels. For example, "Standard Audit" and "Audit" may look like separate choices but mean the same thing to your team. If they describe the same process, keep one option and explain the distinction in the field description or next to the form. If they describe different processes, each should have its own stable stored code.

Keep the List a Manageable Size

A dropdown is useful only if visitors can scan the choices quickly. If the list has dozens or hundreds of items, first ask why the form needs that choice. You may need catalog search, cascading lists, an initial category selection, or dynamic choices. The add-on offers an enhanced interface with search, but its accessibility is limited, so don’t treat it as the automatic answer to every long list.

Keep each column focused on one kind of information. For example, don’t mix categories, urgency, and contact method in Service Type. An option like "Audit - urgent - remote" quickly creates a combinatorial mess and becomes hard to understand. Put urgency in a separate field, and include the work format in a comment or a separate column if it really needs to be recorded for every row.

After saving, return to the field a few minutes later and review it from a visitor’s perspective. Can you choose the right option without knowing your team’s internal terminology? Can you add a second row without having to guess what to do with the first? If not, fix the structure now. It is much easier than normalizing dozens of submitted entries later.

Labels, Values, and Placeholders: Keep Renaming from Breaking Your Data

One of the most useful Gravity Forms List Dropdown settings can go unnoticed because visitors only see the choice label. The developer’s documentation separates the label from the value: the label is shown to the user, while the value is saved in the entry. When Show Values is enabled, you can set them separately. That lets you give a service a clear name while storing a stable technical key.

Suppose your team first offers an "Express Audit" and later changes its positioning to "Quick Audit." If the new label is also the stored value, reports across the two periods will treat it as two different choices. If the visible label changes while the stored key remains quick_audit, processing and exports can continue to rely on a single code. This does not mean every project needs a complex list. But if entries are filtered, sent to a CRM, or processed by a script, separating the label from the value can avoid an unnecessary migration.

A Safer Naming Convention

Use clear labels, such as "Implementation Consultation," "Technical Audit," and "Monthly Support." For the value, choose a short, unique key that you won’t want to change every week: consulting, tech_audit, monthly_support. Don’t add temporary marketing language, prices, emoji, or punctuation to the value. Gravity Forms’ official documentation for choice-based fields recommends unique values and advises enabling them when labels contain special characters or are used in logic and integrations.

Don’t change stored values after the form goes live without a transition plan. Conditional logic rules, external mappings, and custom code may compare the value itself. The documentation warns that if you change a choice value after setting up conditional logic, the rule will no longer match the old value. Even if your List Field is not used as a source for conditional logic on other fields, this is a good data management practice.

The New Placeholder Option and Required Choices

The List Dropdown changelog lists Placeholder support for the current branch. This is useful when the first item should prompt an action rather than look like an answer that has already been selected. Treat the Placeholder as an instruction such as "Select a service," not as an actual service. It should not be a value that users can submit as a meaningful choice. Check the field’s required setting and how the form behaves: users shouldn’t be able to submit a row without making a real choice just because something appeared in the list.

Keep the Placeholder short and clear. A poor example would be: "Choose the option that best matches what you need, or contact us." A good example is: "Select a service." Put details about unusual requests in the field description or a separate Comment column. That keeps the interface clear and prevents visitors from mistaking the prompt for one of the choices.

A Checklist for Each Choice

1. Check that the label makes sense to someone who does not know the team’s internal terminology.
2. Confirm that the value is unique and does not match the code for another service.
3. Create a test row, choose the option, and submit the form.
4. Open the entry and compare what the operator sees with what the processing workflow expects.
5. If the entry is used in a notification or integration, test that path before publishing too.

Don’t use a fake "Not selected" option as the default value if the form requires a real choice. That produces worse data than an empty field because the entry looks complete. Use a neutral Placeholder and make validation clear so visitors can see which cell they need to fix.

The Enhanced Selection Interface: When Search Helps and When It Hurts

The add-on settings include an enhanced interface for dropdowns. It resembles a familiar upgraded selection control and may add search. At first, it can seem like an obvious improvement: visitors can find an option in a long list by typing the first few letters, and the control looks more modern. However, GravityWP’s documentation includes an important caveat: the enhanced interface is not accessible to screen reader users or people who do not use a mouse. The developer has kept this option mainly for backward compatibility.

That leads to a practical choice. For a public form with visitors whose preferred ways of interacting with forms are unknown to you, the native dropdown is safer. It behaves predictably in the browser, supports keyboard use, and adds no extra layer of behavior. Consider the enhanced mode only after checking your specific audience and the size of the list. A form for a small internal team with a long, familiar list may benefit from search, but that does not make the setting a universal recommendation.

Three Questions to Ask Before Enabling Enhanced UI

• Is the list actually too long? If there are eight choices, search will usually add interface complexity without much benefit.
• Have you tested keyboard use? Go through the form with Tab, the arrow keys, selection, and row removal without using a mouse.
• Will users know they can search? A brief instruction may work in an internal interface. A public form should not require training for a basic choice.

If you enable the enhanced interface, test it in the same context where the form is published. Some themes change field widths, spacing, and contrast. Add two rows, open one list, select a choice, add a third row, and select again. Then submit the form and confirm that the value you chose is stored. Testing after adding a row matters because dynamically created elements may behave differently from the first row.

Don’t use the enhanced interface to cover up a poorly designed list. If the list contains dozens of similar names, first separate the different entities or revisit the workflow. Search won’t explain the difference between "Technical Audit," "Audit of the Technical Setup," and "Comprehensive Technical Audit" if the editor hasn’t decided what distinguishes them.

Accessibility matters more than appearance. A native select may look simpler, but predictable controls are more valuable than a decorative wrapper on a form that accepts important requests. If your team cannot perform its own accessibility review, leave the enhanced interface off and improve the clarity of the labels, the form’s grouping, and the field description.

Practical Example: Accept Multiple Service Requests Without Messy Entries

Now let’s build a repeatable example that shows how to use Gravity Forms List Dropdown in a real form. A studio’s website accepts one request that may include several services. The team wants to avoid text entries like "maybe an audit," "urgent setup," or "please advise" because they are difficult to route quickly. At the same time, the quantity and notes are specific to each item.

Goal and Preparation

Our goal is to collect several rows in one entry, with each row containing an allowed service type, a quantity, and an optional comment. Before you start, the test form should have core Gravity Forms, the active List Dropdown add-on, and a List field with three columns. Don’t enable the enhanced interface on the first pass. First confirm that the underlying data works as expected.

Name the field something like "Request Details." Use these column labels: Service Type, Quantity, and Comment. In the field description, you can briefly tell visitors to add a row for each service they need. Don’t put a long instruction in the column label. The form should make sense from its structure, without requiring visitors to decipher the text.

Step 1: Configure the Controlled Column

Select the Service Type column, enable enable Dropdown select, and add four labels: "Technical Audit," "Setup," "Consultation," and "Ongoing Support." For a workflow that processes the entries later, enable Show Values and set these keys: tech_audit, setup, consulting, and support. Visitors won’t see the codes, but they make the data more stable if you edit the labels later.

Check that each key is unique. Don’t use both support and Support as separate values on the assumption that capitalization will distinguish them. That is easy for a person to confuse and can lead to different processing paths in an external system. Pick one format, such as lowercase Latin words separated by underscores. If your project needs values in another language, the same rule applies: keep them short, unique, and stable.

Step 2: Keep the Other Columns Focused on Their Own Jobs

In Quantity, the visitor enters the number they need. Don’t replace this input with a dropdown unless the range is small enough that the list would actually make things faster. You can set an appropriate limit for common quantities, but don’t add one just to make the interface look consistent. Keep Comment as a short free-text field, with examples like "Check before launch," "Two websites," or "Contact after 3:00 p.m." This text adds context to the controlled choice instead of competing with it.

If quantity affects price or a calculation, don’t assume that List Dropdown will calculate the total. The core List Field documentation says it does not support calculations. You’ll need a purpose-built, tested tool for numeric logic, such as an add-on designed for lists or another form model. In this example, we are collecting a request, not building a calculator.

Step 3: Test How Rows Behave

Open the preview. In the first row, choose "Technical Audit," enter 1, and add a comment. Click the button to add a row, choose "Ongoing Support," enter 2, and add a separate note. Then remove the second row and create it again. This checks that the list appears not only when the form first loads, but also in rows visitors add.

Now choose two different values in two rows. The same choice may appear more than once unless you add a separate rule to prevent duplicates. Don’t promise a client that List Dropdown automatically prevents users from choosing the same option in multiple rows. That feature is not listed for the plugin. If the business rule requires unique choices, design and test it separately instead of assuming the dropdown enforces it.

Step 4: Submit a Controlled Test Request

Fill in the required contact fields with test data and submit the form. Go to Forms > Entries, open the new entry, and confirm that the list displays all rows in the expected order. Then check the notification email or other workflow that uses the form. Don’t settle for the confirmation page: it only shows that the submission was accepted, not that the operator will see the right rows.

Finally, repeat the test with an empty row if your form allows one. Check what happens when the Placeholder is selected, the comment is blank, or a quantity is entered. Decide which fields need to be required for an individual request item. Sometimes it makes sense to require only the service type and follow up for details later. Sometimes the quantity must be filled in. Those decisions belong to the handling workflow, not the form’s appearance.

Verify the Full Path: Input, Add-On Behavior, and Entry

Check the workflow at each step, not with a single checkbox. The input is the visitor’s action: they add a row and choose a clear label. The add-on turns the selected column into a select control with predefined choices. The state change is visible on the form: a new row has the same list instead of a regular text field. The output is an entry containing the selected values. The proof is that an operator can open the entry and understand which items the client requested without decoding them.

If any part of the path fails, don’t jump straight to styling. If the editor has the setting but the live form shows a text input, check whether the page is serving a cached version, whether the plugin is active, and whether you are testing the right form. If the form has the dropdown but the email omits the rows, check the notification template and the field merge tag you inserted. If the operator sees the choice but an external workflow doesn’t recognize it, check the difference between the label and the value.

Entries, Notifications, and Checks After Publishing

The plugin helps you collect consistent values, but they are useful only if people and workflows can read them correctly after submission. In Gravity Forms, notifications are configured under Forms > [Your Form] > Form Settings > Notifications. The documentation confirms that notification messages can include merge tags. So after setting up the list, don’t just submit a test. Compare the same data in three places: the public form, the entry in the admin panel, and the recipient’s email.

Use choices that are easy to tell apart in your test. For example, submit two rows with "Technical Audit" and "Ongoing Support" instead of two identical rows. This makes it easier to notice if the email omits part of the repeatable field, changes the column order, or displays the wrong part of the entry. If your team uses exports, test an export with one row and another with several. A List Field has its own storage structure, so don’t expect it to look as flat as a separate Drop Down field.

A Reliable Check After Updating the List

Whenever you add or rename a choice, run a short regression test. It takes a few minutes: open the form in a private window, add two rows, select an old and a new choice, submit an entry, and check the notification. Don’t change the stored value for an existing choice without a reason. If a service is no longer available, it is usually safer to remove it from the choices offered to new visitors and keep clear notes about historical entries in your process documentation.

If the page is cached, check it in two stages. First confirm that the form editor saves the new choices. Then clear the site’s managed cache according to its usual process and open the public page in a new session. Don’t treat your logged-in browser as definitive proof: you may see the latest version while visitors still get an older page. This is a common reason someone reports, "The editor shows the new list, but the site still shows the old one."

Don’t show full internal codes on the page just to make debugging easier. Visitors should see the label they need to make a choice. If operators need the code, make it available in the entry, export, or integration according to your workflow. This keeps the interface clear and prevents visible text from becoming tied to an internal technical name.

Quick post-launch check. A successful test is more than a thank-you message. The choice on the form, the entry, the notification email, and the expected downstream processing should all match.

Dynamic Choices with a Filter: When Code Owns the List

Most forms can use choices entered in the editor. This approach is simpler, transparent to editors, and easier to test. However, Gravity Forms List Dropdown has a documented filter, gravitywp_list_dropdown_choices, that lets you adjust or define list choices programmatically. GravityWP’s documentation describes parameters for the current choices, field object, column name, current value, and form ID. This can help when a controlled, site-managed source supplies the choices, but it is not a reason to move every short service list into code.

Use programmatic choices only when the data has a clear owner. For example, an organization may keep its approved services in a custom site module, and the form needs to use the same keys. Or the same column may appear in several forms, and maintaining a separate copy of the list in each one has led to inconsistencies. If a marketer updates four choices once a quarter, it is simpler and safer to keep them in the form editor.

A Safe, Limited Example

The snippet below is not universal code for every form. It shows the structure of the documented GravityWP filter. Its job is to replace choices only in the form with ID 514, in the field with ID 1, and in the column with the exact name Select Product. Put it in a small custom plugin, a trusted snippets plugin, or a child theme if your project allows that location. Don’t put it in WordPress core or the add-on’s files.

add_filter( 'gravitywp_list_dropdown_choices', 'site_list_dropdown_choices', 10, 6 );

function site_list_dropdown_choices( $drop_down_choices, $field, $column, $value, $form_id ) {
    if ( 514 !== (int) $form_id || 1 !== (int) $field->id || 'Select Product' !== $column ) {
        return $drop_down_choices;
    }

    return array(
        array( 'value' => 'product_1', 'text' => 'Product 1' ),
        array( 'value' => 'product_2', 'text' => 'Product 2' ),
        array( 'value' => 'product_3', 'text' => 'Product 3' ),
    );
}

The snippet uses the array format shown in the add-on documentation: each choice has a stored value and a visible text. The conditions for the form ID, field ID, and column name are essential. Without them, the filter could affect similar lists elsewhere on the site. Test on a copy of the form before making the change, and record the selected IDs in a team note rather than relying on memory.

How to Test and Roll Back the Snippet

After saving the code, open only the target form, add a row, and confirm that the list contains the three specified choices. Then, if there is another form with a List Field, check that its choices have not changed. Submit a test entry and verify the visible label and the expected value in your processing workflow. If the result is not what you expected, deactivate the entire snippet or temporarily comment out the add_filter line. Don’t edit Gravity Forms or List Dropdown files.

Don’t connect this filter to unverified external requests on every form load. If the source of choices becomes unavailable, visitors may get an empty list at the worst possible time. Live data requires a separate, resilient integration with error handling, caching managed by the data owner, and a clear fallback. For a regular editorial form, use static choices or a reliable data source the site already uses.

The Row Lifecycle: Adding, Editing, and Maintaining the Choice List

A repeatable field seems simple as long as you only consider the first submission. In a working form, visitors add rows, operators open entries, editors change service names, and sometimes entries are edited later. So a Gravity Forms List Dropdown setup should account for what happens after someone makes a choice, not just the moment they make it. A single List field stores several rows as one structure, so don’t treat them as a set of independent, one-time dropdown fields.

The first useful principle is not to change the meaning of an existing value after the fact. If tech_audit has historically meant "Technical Audit," don’t assign it to a different service just because the original one is no longer offered. That key remains evidence of an older request in existing entries. Create a new key for the new service and stop offering the old one to visitors. This keeps reports, exports, and manual reviews from turning into an archaeology project of renamed choices.

How to Retire a Choice Without Losing Older Entries

Suppose you no longer accept requests for "One-Time Setup." The simplest approach is to remove it from the new choices after your team has agreed on the replacement. Existing entries should still make sense because they retain the original data. Don’t rewrite historical records in bulk just to make the interface look tidy. That may be appropriate if your organization has a separate, controlled data migration process and you fully understand the impact on notifications, reports, and integrations.

If a new choice replaces an old one in business terms, handle that in your workflow rather than reusing the same value. For example, a new label, "Comprehensive Audit," could have a new code, complex_audit. The team can deliberately combine both values in a report while preserving the original entries. This is especially useful for forms that have been in use for months and are maintained by staff who were not involved in the initial setup.

Test Editing an Entry

If editors change submitted requests in the admin panel, run a separate test. Create an entry with two rows, save it, open it for editing, and confirm that the selected options display correctly. The goal is simple: the label should be recognizable to the operator, and the stored value should not be replaced with another label just because the list was recently edited. This matters more than it might seem when Show Values is enabled.

Don’t draw conclusions from a single row. Add a second one, choose a different option, and then return to the first. This can reveal whether values from different columns get mixed up or the row order is lost. If the form has multiple List Fields, create a test entry that fills in both. Gravity Forms documentation describes a List Field as a separate object with its own data structure, so a one-row test may not reveal everything about a more complex form.

What to Include in the Team’s Working Notes

• The form name and what each List Field row represents.
• The visible labels and their corresponding stable values.
• When and why a choice was retired from new submissions, if applicable.
• Who is responsible for changing choices and checking notifications afterward.
• The test steps: new row, two rows, entry, notification, and published page.

These notes do not replace the developer’s documentation, but they preserve context that is not visible in the form settings. Six months later, another administrator can understand why a value is shorter than its label and why they should not replace one code with another without checking first. That is what it means to maintain a form well: no more bureaucracy than necessary, but enough context to make safe changes.

Practical Uses: From Service Requests to Internal Task Lists

List Dropdown is easier to understand when you follow a single value through the form instead of thinking about an abstract "usability improvement." In each example, the mechanics are the same: a visitor or staff member adds a row, chooses an allowed category, fills in neighboring cells, and gives the operator a clear, repeatable entry. Only the list and validation rules change.

Several Services in One Request

This is the basic use case from the practical example. An agency form accepts requests for several types of work. Only Service Type is controlled in the row; the other columns provide context about the scope. The list prevents one client from writing "site setup," another "config," and a third "tech support" when they each mean one of the same four predefined services.

Expected outcome: Operators can sort requests by known categories without renaming them manually. Check: Submit two rows for different services and confirm that both appear separately in the entry and email. Watch out for: Don’t add "Urgent" to the same list. Urgency is a different data point and should be captured in another field or handled by a clear communication rule.

A Form for Multiple Sites or Rooms

Consider a request to inspect several locations. Each row represents one room or site. In the Location Type column, visitors could choose "Apartment," "Office," "Warehouse," or "Retail Location." In the next column, they enter the area, then describe access details in a comment. The list is not a property catalog. It simply prevents the team from receiving different versions of the same location type, such as "office," "business office," and "workroom."

Expected outcome: The processing team can see how many locations are included and what types they are. Check: Add three rows, remove the middle one, and make sure the remaining values stay in the correct columns. Watch out for: If users need to select an address from a huge database, don’t turn List Dropdown into an address list. Use a specialized address field or another agreed-upon tool.

Registering Multiple Participants

One event registration may include several participants. A List Field row describes one person: their role, name, and any dietary or accessibility notes. A Dropdown select works well for the role, with choices such as "Attendee," "Speaker," and "Guest." A name should not be in the list because it is unique to each person. This is a good example of a mixed row where only one cell needs controlled choices.

Expected outcome: Organizers receive consistent role values and can quickly count each type of attendee. Check: Submit an entry with two participants in different roles and make sure the email does not merge them into one paragraph. Watch out for: If the role affects pricing or access to different pages, don’t assume the List Field will calculate prices or open conditional sections on its own. Design that behavior separately and test it against confirmed capabilities.

An Internal Task List for a Department

In an internal form, a staff member can add several tasks and choose a category for each one: "Content," "Design," "Development," or "Analytics." This is more useful than free text when requests are routed to different teams. Nearby, you could keep a Summary or Task Link column. The list sets a category, but it does not replace the task description.

Expected outcome: Requests arrive with predictable categories, and managers can route tasks to the right people faster. Check: Submit repeated rows with the same category and confirm that the workflow allows duplicates. Watch out for: If routing automatically creates tasks in an external system, first document each value and its mapping to an external queue. Changing a label should not accidentally change the technical mapping.

In all of these examples, the list does not guarantee that a request will be complete or accurate. It controls only one part of the data. Quality depends on clear choice names, neighboring columns that describe the same entity, and a team that actually uses the submitted values in its work.

Maintain the Form with Less Risk: Accessibility, Styling, and Updates

After a successful launch, it is easy to forget about the form until someone reports a problem. A short maintenance routine is more reliable: one assigned person changes the list, a quick test follows each change, and the public form is checked after updates to Gravity Forms, the theme, or the add-on. This does not require a complex system, but it helps prevent unnoticed problems with repeatable data.

Base Styling on the Field’s Actual Markup

Don’t start with random CSS selectors from old articles. Current Gravity Forms documentation describes the List Field markup for the Orbital theme: the field container uses classes such as .gfield--type-list, each row uses .gfield_list_group, and cells use .gfield_list_group_item along with a column-specific class such as .gfield_list_{field_id}_cell{col}. This makes it possible to adjust the spacing or width of a single column without affecting every form on the site.

But CSS is only needed to fix a real readability issue. If the theme already displays the rows neatly, don’t add code just to make a change. If you need a small adjustment, apply it where the project keeps custom styles and scope it to a specific form. For example, a documented form wrapper has an ID like gform_wrapper_112. First replace it with the actual ID of the test form, then check the form at both wide and narrow viewport widths.

/* Example: add a little vertical spacing to the List Field in one form only. */
.gform-theme--framework#gform_wrapper_112 .gfield--type-list .gfield_list_group {
    margin-block-end: 0.75rem;
}

This example uses the documented List Field markup and does not change the plugin’s behavior. Before adding it, confirm that the site uses the corresponding Gravity Forms markup theme. Check: Open the form, add and remove rows, and confirm that the buttons are not covered and other forms have not changed. Undo: Remove only the CSS rule. Never edit WordPress core, Gravity Forms, or List Dropdown files to change spacing.

Accessibility and Clear Labels

You can improve form accessibility through choices in the editor, even without adding styles. Label columns clearly, don’t rely on a Placeholder as the only instruction, and don’t use color as the only way to indicate an error. If the List field has many rows, explain next to it that the button adds another item. Check that column labels remain visible at narrow widths and that short labels do not look too similar.

Pay special attention to Enhanced UI. The List Dropdown documentation openly states that it is not accessible to screen reader users and people who do not use a mouse. The safer approach is not to try to patch this mode with a little CSS, but to choose the native dropdown for public forms. Use Enhanced UI only after testing the keyboard workflow and understanding why search is necessary.

Update Without Guesswork

The List Dropdown changelog includes both new features and fixes: Placeholder support, bulk editing choices, translation support, fixes for preview update conflicts, and improvements to the enhanced interface. That is a good reason to assess updates by more than their version number. Before updating a live form, save a backup, update in a controlled environment first, and repeat a short test: editor, first row, added row, submission, entry, notification.

If the project has several forms with List Fields, choose at least one with a simple column and one with a multi-column list. Don’t consider an update verified just because the admin panel opens. You need to check the public form. If something unexpected happens, first disable the latest custom change or restore the known-good backup according to the site’s procedures, then collect the details you need to contact support. Changing several plugins at once almost always makes troubleshooting take longer.

In practice, maintenance comes down to three habits: keep values stable, limit changes to the forms that need them, and check the full path from visitor to entry to notification after every change. That is enough to keep a small add-on useful instead of turning it into a confusing form dependency.

When Gravity Forms List Dropdown Is a Good Fit

Gravity Forms List Dropdown is worth installing when your form already uses repeatable rows and one or more columns should accept only approved choices. Its value is not in a decorative select control, but in keeping data consistent: visitors add as many items as they need, the team receives consistently named categories, and downstream processing can rely on stable values.

Start with one test form, a simple column map, and a few clear choices. Test adding a row, the entry, the notification, and the published page. Leave the enhanced interface off until you have confirmed that it is necessary and accessible. If this matches your needs, you can download Gravity Forms List Dropdown and roll it out step by step instead of turning a live form into an experiment.