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
    Commented Dec 4, 2017 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". Commented Dec 4, 2017 at 19:04

2 Answers 2


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. Commented Dec 4, 2017 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? Commented Dec 5, 2017 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. Commented Dec 5, 2017 at 19:10
  • Are you converting all leads to contacts? Or is the chat integration updating contacts directly as well? Commented Dec 6, 2017 at 5:23
  • Not all leads become contacts; the chat application will only create leads I believe, as opposed to creating contacts. Commented Dec 6, 2017 at 21:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .