Мне сказали, что слишком сложно связать «Встречу» с «Аккаунтом», потому что может быть несколько встреч на одну учетную запись
Это неверно. Эта связь выглядит точно так же, как между контактом и учетной записью - один контакт, много учетных записей Это очень распространенный шаблон отношений в Salesforce.
Если Встреча логически связана с Учетной записью, она должна иметь поле отношения, ссылающееся на объект Учетной записи, с которым она связана.
Однако, имея Отношение «один ко многим» не означает, что вы можете тривиально представить определенные c точки данных от многих сторон к одной стороне. Родным инструментом для этого является поле сводной сводки, но оно не применимо к вашему варианту использования.
На самом деле есть три способа реализации вашей цели, которые, по сути, реализуют вариант свертки. резюме. VLOOKUP()
, который работает только в Правилах валидации, здесь не применяется.
- Напишите два триггера Apex (один для учетной записи и один для назначения), чтобы реагировать на все изменения, которые влияют на то, какое значение должно появиться в поле
Account__c.Status__c
. - Записать эквивалентную декларативную автоматизацию процессов и потоков, которая не может получить 100% пути, поскольку Process Builder и Flow не могут реагировать на удаление событий.
- Используйте бесплатное приложение с открытым исходным кодом Сводные сводки декларативного поиска Приложение для определения сводной сводки. DLRS может заполнять поле от дочернего объекта (Назначение) до родительского (Учетная запись) на основе сортировки по другому полю (
Date_Time__c
).