This sounds like it should be super simple; and I can't believe I can't find documentation to support my assumption. I have a field, MDID (managed department ID) on the contact level, and I'd like that same value ported over to the same named field on the account level. I thought I'd be able to do something simple like a workflow rule and field update, but doesn't look like it. Should I be looking at the Process Builder or is there perhaps a simpler option.

  • And what behavior do you want for multiple child records? Save the most recent value? Concatenate all of them together? – Adrian Larson Dec 4 '17 at 18:54
  • In theory, that MDID value is going to be the same for any contact on an account. That value is being passed from our user chat application, to a custom field on the lead, and mapped to a custom field on the contact, when said lead is converted to a contact. Does that make sense? The number, the MDID, is essentially an "account number". – Devin Pearman Dec 4 '17 at 19:04

Workflow rules can only affect the currently processed record. However, the Process Builder can indeed update a related record. When you create the Process Builder, start with "When a record is modified", choose "Contact" as the primary object, and choose to perform an immediate update on the related Account.


If Managed Department ID is the same for all contacts in an account, then you should use a cross-object formula field in Contact to reference the account's MD ID. That's the point of using a relational database; the child can inherit the parent's values.

To get a value into the Account MD ID field, you can make a conversion mapping of the Lead MD ID field to the Account MD ID field.

  • Hey David- Thanks for the reply! If I understand your suggestion, you're saying I can have the child inherit the parent's value. Isn't the "contact" the child and account is the parent? If so, I need it to go the other way; the contact has the value and I need that value to be copied up to the account level. – Devin Pearman Dec 4 '17 at 21:54
  • If MD ID acts like "account number" then it should be managed at the account level, not the contact level. Think of it like the account name field -- would you fill in the account name field on the contact record and then update the account, and then update all the other contacts with the account name? – David Cheng Dec 5 '17 at 1:14
  • Oh I totally agree! I just don't have a way to get this value, the MDID, automatically to the account level. I only have Intercom (our client chat app that grabs certain attributes,) to SFDC contact/lead level syncing. So Intercom can grab that value, the MDID, and map it to a field on the contact/lead object. That's why I need to surface it from the contact to the account level. Intercom, where this MDID is being grabbed from, doesn't populate to the account level. – Devin Pearman Dec 5 '17 at 19:10
  • Are you converting all leads to contacts? Or is the chat integration updating contacts directly as well? – David Cheng Dec 6 '17 at 5:23
  • Not all leads become contacts; the chat application will only create leads I believe, as opposed to creating contacts. – Devin Pearman Dec 6 '17 at 21:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.