I'm exploring the option of adding a search bar within a SFMC email.

I've used the following script (that I can't seem to render properly here, but I'll give it a shot):

First line:

form action="https:URL[?search=" search-string-parameter-here="]"

Second line:

input aria-label="Search Website" aria-owns="awesomplete_list_2" autocomplete="off" class="input input-text header-search-input" id="searchText" name="SearchText" placeholder="keywords like:'Fridge'" role="combobox" style="background-color: #ffff; border: 1; border-color: #7d96a4; font-size: 16px; line-height: 22px; padding-left: 4px; color: #2d2d2d;" type="text" value=""

Third line:

button aria-label="Submit Search" class="button button-search header-search-button" id="SubmitSearch" name="SubmitSearch" style="background-color: #eeeeee; border: 1; font-size: 16px; line-height: 22px; padding-left: 4px; margin: 5px; color: #2d2d2d;" type="submit" value="submit">Search

This is what it renders. This is what it renders.

But I have two questions:

  1. Issue 1: When someone enters a keyword and hits 'Search' CTA, it leads them to the Search landing page instead of retrieving the Search results. Any recommendations on how to go about it?
  2. Question: Is there a way to add some code to this HTML, so we can potentially analyse what's being searched? Maybe add some query to record searched keywords in a data extension?

Thanks for the help! :)

1 Answer 1


This is likely not gonna go far.

A search bar is basically a form, you just don't store any data. The first problem you will face with both your question is:

you'll need some client side script to capture the user's form input from the search field once he clicks the search button, to create a search URL with parameters, or something similar.

On a webpage, you'd do this with something like an on-click javascript function. As this function should process input by the client, this is by necessity client-side script, and cannot be performed on server-side using SSJS or AMPScript (the server is out of the picture once the email leaves the system), which would be before the user has a chance for making any inputs.

Here's the catch: Client-side script is blocked or stripped by pretty much any email recipient system, for good reason (bad actors could use this as well as legitimate ones).

In general, forms in emails aren't exactly a match made in heaven - I'll stop short of saying they don't work, because there are some very, very limited applications like "interactive email" that turn into basic webpage fallbacks outside of some supported clients.

you can google "forms in emails" and you will find a lot of red flags, even if you get it to work somehow.




You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .