Больная тема для меня. Уже не раз "сталкивался лбами" в споре по поводу использования стандартных объектов. Поэтому хочу спросить вашего мнения "В чем преимущество использования стандартных объектов?". Сколько работаю ни разу не видел реальной выгоды от стандартных объектов, зато геморроя встречал кучу. Почему же тогда все на них молятся?
Согласен, если CRM используется по прямому назначению и используется стандартный функционал, то стандартные объекты это само собой разумеющееся. Но если функционал кастомный, то зачем использовать стандартные объекты только потому, что они имеют похожее по смыслу название?
Вот взять к примеру Contact, к нему нельзя добавить поле Master Detail на какой-нибудь другой объект, к нему ограничен доступ в некоторых типах лицензий. И это самое безобидное. В других стандартных объектах есть моменты поинтереснее. Кроме того если делать свой пакет и привязываться к стандартным объектам нужно сразу готовиться объяснять на security review почему вы используете стандартные объекты. Я уже не говорю про кучу будущего геморроя с несовместимостью с кастомным функционалом на оргах клиентов.
Так В чем преимущество использования стандартных объектов?
Вот пример:
у тебя небольшое кастомное приложение и вместо стандартных Контак\Эккаунт ты успользуешь кастомные. Но организации-заказчику понравилось твоя работа и тебе отдают на автоматизацию и другие бизнес процессы, и следующий из них типичный CRM (который не имеет смысла пилить в ручную) и под него ты покупаешь лицензию Salesforce, и там используется стандартный Контакт. И потом когда двигаешь новый проект в единый Прод, видишь, что у тебя там два Контакта...
или в Эккаунт нужна иерархия...
1. Это уже косяк архитектуры. Зачем мешать котлеты с котятами. Есть кастомное приложение, которое имеет свой контакт, а есть CRM функционал у заказчика. Не проблема будет если будет два объекта Контакт, которые можно синхронизировать между собой. А вот будет проблема когда у заказчика хранятся в контактах Сантехники, а он устанавливает твое приложение для учета Дворников, но при это не хочет чтобы среди его Сантехников появились Дворники 
2. А в чем проблема сделать иерархию в кастомном объекте? Self-reference? Не думаю что иерархия аккаунтов это преимущество над кастомными объектами.
на то у каждого проекта есть собственный РекТайп, лейаут и кастомные поля для контатка и эккаунта, и соответсвенно настроен RLS
Да, согласен, есть рекорд тайп есть. Но вот не хочет заказчик мешать две сущности, а потом разделять из с помощью рекорд тайпа и отдельных лайаутов. Я просто пример с Дворниками и Сантехниками неудачный привел - они просятся в один объект. Пусть это будут "покупатели" и "работники склада". Вот их зачем объединять в Контакт? На "Покупателях" будет навешена куча бизнес логики, которая к "работникам склада" вообще никакого отношения не имеет. Но если их объединить, то ВЕЗДЕ в логике и отчетах придется ставить проверки.
ну может быть. если это бизнес сущности, технически близкие к Контакту, но являющиеся активными действиющими объектами в бизнес логике, то возможно они и заслуживают свою собственную таблицу (которая может иметь лукап на Контакт).
Хотя в начале мне показалось, что вопрос был поставлен по другому: чем самопильный контакт хуже стандартного?
А то, что таблица "Водители нашей автобазы" это не тоже самое , что и Контакты, это понятно.
