Создать новые объекты или создать новые типы записей существующих объектов?

Насколько я не являюсь противником стандартных объектов, но в данном случае данная дата модель отлично ложится на типы записей (Record Types). Так что все правильно написано выше какие типы записей и для каких стандартных объектов использовать!

Спасибо Дмитрий! 

Положу сюда ссылки на соответствующие разделы документации: 
[u][color=blue][url=https://help.salesforce.com/articleView?id=creating_record_types.htm&type=0&language=ru&release=206.15]Создание типов записей[/url]
[url=https://help.salesforce.com/articleView?id=customize_recordtype_considerations.htm&type=0]Рекомендации по созданию и обновлению типов записей и раскрывающихся списков[/url]
[url=https://help.salesforce.com/articleView?id=perm_sets_record_types_assign.htm&type=0&language=ru&release=206.16]Назначение настраиваемых типов записей в наборах полномочий[/url]
[url=https://help.salesforce.com/articleView?id=recordtypes_picklists_limitations.htm&type=0]Ограничения на создание и обновление типов записей и раскрывающихся списков[/url]
[url=https://help.salesforce.com/articleView?id=customize_standard_objects_limits_page.htm&language=ru&release=206.5&type=0]Ограничения для стандартных объектов[/url][/color][/u]

Кстати, а с чем связана рекомендация в официальной документации: "Прежде чем создать типы записей, добавьте все возможные значения типов записей в основной список раскрывающихся списков"?

[u][color=blue][url=https://help.salesforce.com/articleView?id=fields_creating_global_picklists.htm&language=ru&release=206.6&type=0]Создание набора значений глобального раскрывающегося списка[/url][/color][/u]

Чет по-русски совсем не воспринимается Salesforce :)
Можешь скинуть ссылку на страницу с этой рекомендацией?

А нашел

[i]Before creating record types, include all of the possible record type values in your master list of picklists. The master picklist is a complete list of picklist values that can be used in any record type.[/i]

Хм, даже сам не скажу что это за фигня.

Догадываюсь что это связано с тем что значения из пиклистов (picklist field) можно привязывать для определенных RecordTypes. А эта рекомендация связанная с каким-то "master picklist" каким-то образом выставляет дефолтное поведение. Короче пока этим можно не заморачиваться. Потом по необходимости можно будет настроить когда подойдет необходимость.

Можно ли углубить классификацию, и каким то образом добавить типы второго уровня? Например: в качестве Кредитора могут выступать два типа кредитных учреждений – банки и МФО. Оба обладают преимущественно одинаковым списком взаимосвязей и атрибутов, тем не менее есть и существенные отличия. Как лучше всего реализовать модель данных в данном случае?

[quote="Dmitry Shnyrev"]А нашел

[i]Before creating record types, include all of the possible record type values in your master list of picklists. The master picklist is a complete list of picklist values that can be used in any record type.[/i]

Хм, даже сам не скажу что это за фигня.

Догадываюсь что это связано с тем что значения из пиклистов (picklist field) можно привязывать для определенных RecordTypes. А эта рекомендация связанная с каким-то "master picklist" каким-то образом выставляет дефолтное поведение. Короче пока этим можно не заморачиваться. Потом по необходимости можно будет настроить когда подойдет необходимость.[/quote]

Понял. Ну на всякий случай сделаю заранее %)

[quote="Sergey Makarov"]Можно ли углубить классификацию, и каким то образом добавить типы второго уровня? [/quote]
Типы записей - это одноуровневая классификация. 
Для более серьезной можно наверное воспользоваться либо полем дополнительным Type(Picklist) например и в ним уже указывать более детальную или более общую классификацию. Или задействовать другой объект родительской (тика Категория).

Но по сравнению со стандартными RecordTypes это не даст никаких возможностей настраивать Layout объекта или привязывать значения в полях. 

[quote="Sergey Makarov"]Наша бизнес-модель имеет в своём составе Кредиторов (банки, МФО), Ритейлеров (сети розничных магазинов) и Заёмщиков (физ. лица, приобретающие товары у Ритейлеров в кредит, предоставляемый Кредиторами)[/quote]
Вот тут вообще еще идеально подходит Pesron Account.

[quote="DevNull"][quote="Sergey Makarov"]Наша бизнес-модель имеет в своём составе Кредиторов (банки, МФО), Ритейлеров (сети розничных магазинов) и Заёмщиков (физ. лица, приобретающие товары у Ритейлеров в кредит, предоставляемый Кредиторами)[/quote]
Вот тут вообще еще идеально подходит Pesron Account.[/quote]
Почему? Для каких конкретно ролей из перечисленных? Только для Заёмщиков?

Почему же? Просто у заемщиков есть свои филды к примеру как First Name/Last Name как у контакта, а у остальных как у аккаунтов. И все это на одном объекте Аккаунт. 
https://help.salesforce.com/articleView?siteLang=en_us&id=account_person.htm&type=0

[quote="DevNull"]а у остальных как у аккаунтов[/quote]
DevNull спасибо, про Person Account уже документацию изучил.
 
Вот ещё интересная статья: 
[u][url=https://help.salesforce.com/articleView?id=account_person_behavior.htm&type=0]Алгоритмы организаций-лиц[/url][/u]
[u][url=https://help.salesforce.com/articleView?siteLang=en_us&id=account_person_behavior.htm&type=0]Person Account Behaviors[/url][/u]

[quote="Sergey Makarov"][quote="DevNull"]а у остальных как у аккаунтов[/quote]
DevNull спасибо, про Person Account уже документацию изучил.
 
Вот ещё интересная статья: 
[u][url=https://help.salesforce.com/articleView?id=account_person_behavior.htm&type=0]Алгоритмы организаций-лиц[/url][/u]
[u][url=https://help.salesforce.com/articleView?siteLang=en_us&id=account_person_behavior.htm&type=0]Person Account Behaviors[/url][/u][/quote]

Главный вопрос – какие ограничения наследуют стандартные объекты в целом? Те, что потенциально могут вызвать проблемы при масштабировании дата-модели в будущем?

[quote="Dmitry Shnyrev"]Насколько я не являюсь противником стандартных объектов...[/quote]
В каких аспектах и почему ты против стандартных объектов? Правда очень интересно узнать твоё мнение, как у старшего товарища! :)

Ну в моем случае это скорее исторически так сложилось.
Я практически 90% времени работал на проектах по разработке пакетов(приложений) для salesforce.
А опыт показал что как только начинаешь трогать стандартные объекты у клиентов начинаются проблемы. 
Появляются конфликты в логике обслуживающей стандартные объекты (Trigger, Workflows, Validation rules, Required fields). В общем пакеты просто обязаны строиться на кастомных объектах чтобы избежать проблем в будущем на оргах клиентов.
Ну а что касается обычных клиентов, которые используют стандартный функционал SF, то конечно тут проблем нет и использовать стандартные объекты нужно. Но опять же как показывает практика стандартные объекты используют на 10% от силы даже не представляя для чего они нужны и какая логика стандартная на них завязана. Это тоже становится проблемой - могут быть конфликты. Я уже сотню костылей написал чтобы заставить работать то что по идее должно работать само.

Короче кастомный объект идеален потому что по умолчанию чист как слеза. А уже ты сам наворачиваешь на него то что тебе надо. 

[quote="Dmitry Shnyrev"]Ну в моем случае это скорее исторически так сложилось.
Я практически 90% времени работал на проектах по разработке пакетов(приложений) для salesforce.
А опыт показал что как только начинаешь трогать стандартные объекты у клиентов начинаются проблемы. 
Появляются конфликты в логике обслуживающей стандартные объекты (Trigger, Workflows, Validation rules, Required fields). В общем пакеты просто обязаны строиться на кастомных объектах чтобы избежать проблем в будущем на оргах клиентов.
Ну а что касается обычных клиентов, которые используют стандартный функционал SF, то конечно тут проблем нет и использовать стандартные объекты нужно. Но опять же как показывает практика стандартные объекты используют на 10% от силы даже не представляя для чего они нужны и какая логика стандартная на них завязана. Это тоже становится проблемой - могут быть конфликты. Я уже сотню костылей написал чтобы заставить работать то что по идее должно работать само.

Короче кастомный объект идеален потому что по умолчанию чист как слеза. А уже ты сам наворачиваешь на него то что тебе надо.[/quote]

Справедливо ли сказать, что для динамично масштабируемых систем с бизнес-требованиями которые до конца не известны, либо динамично меняются, предпочтительно использовать кастомные объекты?

Я бы на первое место поставил вопрос - будет ли распространяться решение в будущем или будет пилиться сугубо под текущего клиента (один орг). Ну и перед использованием того или иного стандартного объекта надо досконально изучить его предназначение по задумке SF и все стандартные поля а также бизнес логику которая на нем завязана. Не стоит опираться только на созвучное название. 
Вот к примеру тукущий проект один. Клиент не разобрался нужен ему Task или Case и пришли в итоге к тому что создаются сразу оба объекта причем вся инфа в них дублируется. Что с точки зрения архитектуры и здравого смысла полный бред.