Introducing Virtual Fields: Keep Sensitive Data Off the Page

Formidable Forms now has a Virtual Field type that lives entirely on your server. Why is this valuable? because the field value is never output to the page in any way, not as a hidden input, not in the source, not anywhere a user could find or modify it. Set a price, a score, or an internal code once in the field settings, and that exact value is what gets saved to the entry and passed to your payment action on submission. No custom PHP, no extra validation, no workarounds.

Approximate read time: 6 minutes

When You Need the Highest Level of Security

Most form data belongs in the browser. Users fill it in, see it, interact with it. That's how forms work.

But some values are different. A product price that should never change. A quiz answer that should never be visible. An internal routing code that has nothing to do with the person submitting the form. For these, you want the value to exist in your entry data without ever touching the page HTML.

Until now, the closest options involved extra validation on your server or custom PHP to ensure a value arrived exactly as expected. That works, but it's additional code to write and maintain. Virtual Fields handle this at the field level, no extra code required.

What's New: A Field That Lives Entirely on your Server

The new Virtual Field type changes the approach entirely. Here's what you can do now:

Set a value that never appears in the page HTML. Virtual Fields produce zero HTML output. No input element, no hidden field, nothing in the source. There is nothing for a user to inspect, modify, or intercept.

Lock prices for payment forms. Set the Virtual Field's value to your product price. Point your Stripe or Square payment action at that field. The value gets saved to the entry on the server on submission, and the payment action picks it up from there. What you set is exactly what gets charged.

Keep quiz answers and internal codes completely private. Correct answers, internal flags, routing codes, scores you assign: any value that should never be visible to the person filling out the form belongs in a Virtual Field.

Run server-side calculations. Use the built-in Calculate Value option or [frm-math] shortcodes to compute totals, scores, or derived values on the server. The formula and result stay completely hidden from the browser.

Pull values from other forms with Lookup. Use the Lookup option to retrieve a value from entries in another form at submission time. Look up a customer's account balance, a student's grade level, or a product's cost from a separate data form, all without exposing anything to the front end.

Use it in form action conditions. Virtual Field values are available in form action conditional logic, since conditions on actions are processed on the server. No browser presence required.

Access it everywhere admins need it. The value is saved to the database like any other field. It shows up in entry views, exports, notification emails, Views, and the API. It's just never shown to the person who submitted the form.

Stays completely off the page in multi-step forms. Formidable normally converts fields from previous pages into hidden inputs so their values carry through to submission. Virtual Fields are excluded from this entirely. The value never converts to a hidden input on any page, at any step.

Ready to set one up? The Virtual Fields documentation walks through adding the field, configuring a value, and connecting it to a payment action.

Real-World Use Cases

Virtual Fields work for any situation where a value needs to exist in your entry data without being visible or accessible to the person submitting the form.

Payment forms with locked pricing. Set your product price in a Virtual Field. Point Stripe or Square at it. Every submission charges the exact amount you configured. Works for one-time payments, deposits, and service fees.

Quiz and exam forms. Store correct answers or scoring formulas in Virtual Fields. Students never see the answer key in the page source, no matter how carefully they look.

Internal status and routing fields. Tag submissions with internal codes on arrival: routing flags, department assignments, priority levels. The person submitting the form has no idea the field exists.

Server-side calculated pricing. Use the Calculate Value option or a [frm-math] shortcode to apply a tax rate or markup on the server. The formula stays hidden, and the result gets passed directly to your payment action.

Affiliate and referral tracking. Pull a referral code from a URL parameter using [get param=ref], store it in a Virtual Field, and know it will arrive in the entry exactly as captured.

Admin-assigned scores and flags. Set a default score or flag on submission that only admins see. Useful for applications, assessments, and intake forms where an initial value needs to be set before any manual review.

Auto-populated account data via Lookup. Use the Lookup option to pull related records from another form. A school enrollment form could look up a student's advisor, or an order form could retrieve a customer's shipping address from a contacts form.

Multi-step onboarding and checkout. Carry a plan ID, pricing tier, or configuration value through every page of a multi-step form. The value stays server-side through all steps and arrives at submission exactly as set.

The pattern? If a value should exist in your entry data but not in your page HTML, it belongs in a Virtual Field.

Entry Editing and Admin Access

When a user edits their own entry from the front end, the Virtual Field value stays hidden and unchanged. It doesn't reset to the original value setting, and it doesn't appear anywhere in the edit form HTML.

Admins can view the value from the entry edit screen, where it appears as a disabled textbox. The value is read-only there as well, so if you need to update it after submission, that would require custom code or a re-submission.

Virtual Field values appear everywhere else admins need them: the entries list, email notifications via [default-message] or the field shortcode, Views, CSV exports, and the Formidable Forms API.

Form Action Conditions

Virtual Field values are available in form action conditional logic. You can trigger different notification emails, confirmation messages, or integrations based on what a Virtual Field contains.

Because action conditions are processed on the server, Virtual Fields work here without any limitations. Field-level conditional logic (which requires the field to appear in the page HTML) is not supported, but for controlling what happens after submission, Virtual Fields work just like any other field.

Get Started with Virtual Fields

Virtual Fields are available on all Formidable Forms paid plans: Basic, Plus, Business, and Elite.

Add the field in the form builder, set a value, and you're done. There's no configuration needed to keep it off the front end, that's just how the field works. Sensitive values in your forms can now live entirely on the server, with nothing exposed to the browser and nothing for users to manipulate.