- Munchkin is domain specific, so would it even work in our other development environments? |
Munchkin isn't domain-specific. A single Munchkin ID can be used on any number of domains. It's the ID (and, optionally, workspace ID) that determine which Marketo database is updated.
You can also send Munchkin activities to multiple Marketo instances at the same time (each with its own Munchkin ID). This is not exactly resource-efficient, but it is supported (the Munchkin init option altIds allows this).
- If Munchkin is not on our dev server, how do we test forms that will submit to Marketo via the API? |
Well, first of all, you should not use any API -- besides the client-side Forms 2.0 API, of course, which is used by native Marketo Forms -- to submit forms. To do anything else creates a Denial of Service vulnerability.
Second, Marketo Forms and Munchkin are complementary but they a re not actually interdependent. A form post works fine without Munchkin and will upsert the corresponding Marketo lead. Where Munchkin comes in (and it is an important feature, just not critical to the operation of the form itself, and actually a different testable unit) is in associating past and future web activities with the now-identified lead, as well as in related features like Progressive Profiling and Known Lead HTML (both of which imply access to the associated lead's activity history).
So if you do not run Munchkin on your dev server, but you do (as you should in a professional context) use standard Marketo Forms to submit to Marketo, you'll get leads, but not a complete activity trail.
What is your approach to Munchkin integration and form testing? |
You're going to need test leads or else you won't be able to test. You can segment test leads, making sure that people use a consistent naming pattern (like plus addressing: test+099@example.com) that can be predictably found using Smart Lists.
