Hi All,
Question 1:
All our web forms populate country, state, and postal upon a fill out. How do people handle or would handle a situation where someone is pre-existing in our database with full address information (country,state,postal,street) and they then end up filling out one of our web forms with different address information than we have on record? Country, state, and postal would update however street would be their old street address and then would represent inaccurate address information.
Question 2:
Some of our leads/contacts move from job site to job site but have one address or one place where they normally reside. We have a concern that someone may fill out a web form with address information of their current job site vs where they normally reside. How are people handling this or would handle such situations?
Most of our web forms are embedded and not on Marketo LPs
Also our CRM is salesforce...
Solved! Go to Solution.
Hey Nate,
The problem with partial updates is a classic one. As you noticed, blocking field updates, while an important step, doesn't prevent empty fields from being filled with data. Nor does an empty field get cleared on form submit.
To protect entire sections of data I recommend posting lead-supplied data only to staging fields (essentially, mirrors of your form fields). Then you can reconcile the data on the back end to make sure that fields are only updated section-by-section. I would do something like this in the 'Boost:
smartAssign( currentFields, stagingFields, {
sections: [
["First Name"],
["Last Name"],
["Email"],
["Address","Country","State","Zip"]
]
}
This would update the address block all-at-once instead of piecemeal.
We have a concern that someone may fill out a web form with address information of their current job site vs where they normally reside.
No way to prevent this other than strong-but-friendly encouragement on the form itself. It's another common problem (and it's not the case that either one is more correct than the other -- if someone's on a long-term contract overseas that may be a more important location than "HQ" for the time being). Having multiple fieldsets for "Job Site Address" and "Primary Corporate Address" could be useful (the second one can have a checkbox for Same as job site address -- like Billing same as shipping in a shopping cart).
1. You must do field blocking.
2. They certainly will do this. Field blocking will prevent a overwrite. This sounds complex though. If a lead also changes emails, then we're good. If you want to capture all such data and the lead expects this, then maybe you need something more complex with a custom object.
Hey Nate,
The problem with partial updates is a classic one. As you noticed, blocking field updates, while an important step, doesn't prevent empty fields from being filled with data. Nor does an empty field get cleared on form submit.
To protect entire sections of data I recommend posting lead-supplied data only to staging fields (essentially, mirrors of your form fields). Then you can reconcile the data on the back end to make sure that fields are only updated section-by-section. I would do something like this in the 'Boost:
smartAssign( currentFields, stagingFields, {
sections: [
["First Name"],
["Last Name"],
["Email"],
["Address","Country","State","Zip"]
]
}
This would update the address block all-at-once instead of piecemeal.
We have a concern that someone may fill out a web form with address information of their current job site vs where they normally reside.
No way to prevent this other than strong-but-friendly encouragement on the form itself. It's another common problem (and it's not the case that either one is more correct than the other -- if someone's on a long-term contract overseas that may be a more important location than "HQ" for the time being). Having multiple fieldsets for "Job Site Address" and "Primary Corporate Address" could be useful (the second one can have a checkbox for Same as job site address -- like Billing same as shipping in a shopping cart).
Thanks Sanford. I am not a developer. Could you explain a little more simply what you mean by posting data only to staging fields and the functionality of that?
Sanford,
Is this the type of logic you were referring to? If so, could you accomplish the same thing by the below steps?
Nate, that's exactly the logic I was talking about. Though I wouldn't implement this using "Member of Smart List" because of performance under load. Maybe try a segmentation instead.