Update Contact Type Lead and Contact records on a form submission | Community
Skip to main content
A
aashutosh1211
New Participant
January 18, 2023
Solved

Update Contact Type Lead and Contact records on a form submission

  • January 18, 2023
  • 2 replies
  • 2224 views

In case we have two different records; one marked as Lead and other marked as contact having the identical email. Can we update both the records using Submit Form API.

Currently it has been observed it is updating only the most recent record.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

A single form submission, either from the Forms JS API or the REST API Submit Form endpoint, will only ever update one person record. This cannot be changed.

 

As Darshil mentions, there are various heuristics that determine which record be updated, but again it's only ever one record.

 

In addition to the above, the default lookup key for a form post is the Email Address field in the absence of other information. It's possible to add an additional field as a lookup key, but you won't be able to use the system SFDC Type in this way. (People typically use fields like Company or a custom Account ID, although having a compound lookup key can itself be dangerous and/or confusing.)

 

When we need to "spread" the effects of a form submission across other people, we use a webhook-powered service. The service loops back using the REST API to get all people matching, most commonly, the Email Address of the person who fired the 'hook. Then it writes field values from that person onto other people in the set of matches, applying any other kind of logic along the way.

2 replies

SanfordWhiteman
SanfordWhitemanAccepted solution
New Participant
January 18, 2023

A single form submission, either from the Forms JS API or the REST API Submit Form endpoint, will only ever update one person record. This cannot be changed.

 

As Darshil mentions, there are various heuristics that determine which record be updated, but again it's only ever one record.

 

In addition to the above, the default lookup key for a form post is the Email Address field in the absence of other information. It's possible to add an additional field as a lookup key, but you won't be able to use the system SFDC Type in this way. (People typically use fields like Company or a custom Account ID, although having a compound lookup key can itself be dangerous and/or confusing.)

 

When we need to "spread" the effects of a form submission across other people, we use a webhook-powered service. The service loops back using the REST API to get all people matching, most commonly, the Email Address of the person who fired the 'hook. Then it writes field values from that person onto other people in the set of matches, applying any other kind of logic along the way.

A
aashutosh1211Author
New Participant
January 19, 2023

Thanks @sanfordwhiteman; it was in my mind to use webhook in case the requirement to update all records urges up. I raised this query to be sure that SubmitForm REST API will only update the single record; not all matching with email.

SanfordWhiteman
SanfordWhiteman
New Participant
January 19, 2023

There's no method that takes a single lead identifier as input (id, Email Address, custom field, whatever) and updates multiple records at once.

Darshil_Shah1
Darshil_Shah1
Community Manager
January 18, 2023

This isn’t possible OOTB. You’d need custom dev and setup to ensure the other record gets updated upon form-fill (both via API or a Marketo form fill) as well. By default, for duplicate records, the form filled will be attributed to whatever lead is associated with the cookie in case a they’re munchkin associated. if not, the form will be attributed to the lead that was updated most recently in marketo, and of course then the lead would be cookied (muchkin association). 

Do you have an apt business case where you couldn’t get away from working with duplicate records? I usually don’t prefer dupes, due to all the caveats associated with them and DB issues they could create when not managed properly. Let’s make sure that this isn’t an XY problem in the first place.

    Terms & ConditionsAccessibility statement

    Loading footer...