There are a few ways to accomplish this. From custom JavaScript to something simpler though maybe less user friendly.
Above, the custom field "ChrisTestField" is compared to a defined Event Code "EventCode".
In the flow, you can then email alert if they have successfully registered or not and add them to event registration or not.
This isn't the prettiest implementation, but it would work without needing any coding skills.
We generally do this at the form level. It's a variation of the Confirmation Code pattern.
Check this example (live at MktoForms2 :: Confirmation Code😞
You control valid submission of this form by checking the Download Passcode when determining the Thank You/Follow Up URL. The user can't look at the form HTML to grab a correct passcode, because it is only stored on the server (not on the client):
You can have more than one valid download code, which can be a great assist in attribution (give out one download code at each tradeshow, for example).
In the above example, we're redirecting the browser to the asset URL immediately. You can easily switch this up to sending an email w/the URL instead: trigger on a visit to one of the valid Thank You URLs (obvs. you don't want to make those URLs easy to guess -- add a random query string and nobody is going to end up on the Thank You page by accident).
But it needs to be made clear that neither this approach nor the Flow-based approach Chris outlines are truly stopping the form from submitting as in your initial specification. It's not possible to stop a malicious person from submitting a form without JavaScript validation, nor is it possible for Marketo to kick back an error before accepting the form data into the system.
While you might think about including the passcode(s) in the form itself or in some supporting JavaScript served to the browser in order to pop up an interactive error, that's substantially less secure. (It's also one of my pet peeves, as a lead, to see "passwords" in HTML source... even if the password is just to a white paper it aggravates my security side.) Sure, a totally amateur user wouldn't be able to submit the form. But an even mildly inquisitive person would just read the passcode out of their own browser and submit a valid form! Your final level of protection is much, much lower than you get with one of the server-side methods.
In the end, web form security is up to the server, not the client. And while it would be great if Marketo could recheck validation rules on the server before even allowing the form to post, that's not the way the forms endpoint works. So the next best thing is to use server-side stuff (form-level rules or flow-level rules) to detect and discard invalid post data.
.png)