Вы можете настроить доступ к данным в Salesforce на четырех основных уровнях.
Organization level - доступ к самой организации - логины-пароли-авторизация.
Если мы на орг уже попали - то что нам будет доступно определяется следующими уровнями:
Object level - доступ к объекту. Если у юзера есть доступ к объекту - все ок, все супер, идем дальше.
Record level - доступ к рекорду, то есть к самой записи. Вот тут может быть что есть доступ ко всем рекордам, а может и не ко всем - какие то видно, какие то нет. Самый основной доступ “по овнеру” (кто владелец - у того и доступ) например: рекрутер может видеть и редактировать свои позиции, а чужие видеть не может, редактировать тем более. Могут быть и более сложные критерии для разрешения/ограничения доступа.
Field level - доступ к полям. Если к рекорду доступ есть - все ок, но может не быть доступа к полю. Поля к которым нет доступа показаны не будут.
Когда вы пытаетесь получить какие то данные и что то с ними сделать, доступ проверяется поэтапно. Сначала Organization level - можно ли вообще вам тут быть? Если доступа нет - дальше вас просто не пустит.
Если на уровне организации у вас доступ есть, проверяется Object level - можно ли вам что либо делать с записями этого объекта? Если нельзя - дальше не пускает, если можно - дальше проверяется Record level - а конкретно с этой записью вам можно что-то делать, или нет? То же самое: если ничего нельзя - то ничего не видно, если можно - проверяем Field level, какие поля доступны?
В обратную сторону это не работает - если будет доступ к полю, но к объекту доступа нет - то к полю тоже не будет (даже если в настройках доступ к полю дали)
Виды доступа:
Object level: Read, Create, Edit, Delete - можно ли вообще видеть или редактировать рекорды этого объекта?
Record level: Read Only, Read/Write - можно ли видеть и редактировать конкретно этот рекорд?
(при этом учитываем предыдущий уровень - если нет доступа ‘Object level - Read’ - то не доступны никакие рекорды)
Field level :
Read Access - поле можно только видеть.
Edit Access - в это поле можно вносить значения при Create и Edit (если есть соответствующее разрешение на предыдущих уровнях)
ну и соответственно доступа к полю может вообще не быть - тогда его даже видно не будет.
Основные настройки Object level и Field level настраиваются на профиле, все остальные способы могут только расширить доступ (если на профиле разрешено - другими способами не ограничить)
Основной Record level настраивается через Organization–wide defaults, все остальное может только расширить доступ к рекордам, но не ограничивать.
Private - видны только свои рекорды, редактировать можно только свои рекорды (если есть соответствующий доступ на Object level)
Public Read Only - свои можно видеть, редактировать, чужие - только видеть (то же самое - если есть доступ на Object level)
Public Read/Write - можно редактировать и свои и чужие (если настроен Object level, естественно)
К Record level так же относятся настройки View All, Modify All , которые можно найти на профиле возле Object level (соответственно, если Record level указан Private, но на профиле возле объекта стоит View All - то юзер сможет видеть чужие рекорды)
Настраивая Field level вы можете заметить что на некоторых полях нельзя поставить или убрать галочки.
Например, вы не можете поставить доступ Edit на поле Created By. Это системное поле, и его никто из юзеров не может редактирвоать, так как в этом поле всегда должен быть указан юзер, который создал рекорд, и больше никто другой сюда записан быть не может, поэтому редактирвоать его нельзя (если бы можно было редактировать - мы бы потом не нашли крайних - кто создал, кто менял) так же нельзя редактировать поля-формулы (было бы странно, сели бы их можно было редактировать - тогда в эти поля можно было бы записать не актуальную информацию, а они на то и формулы, что бы подтягивать именно актуальную информацию)
Или, когда у вас есть обязательное поле - то оно будет доступно для Edit, и это никак не убрать. Потому что если доступ нет - то поле заполнить не получится, а его заполнять надо, потому что оно обязательное. Но, если нет доступа на предыдущих уровнях - то это поле никто редактирвоать не сможет. Это нужно для того, что если уж юзер имеет возможность редактировать эту запись - значит это поле по любому должен редактировать, потому что если не заполнить обядательное поле - теряется смысл его обязательности.
Где это настраивается можно почитать тут
Самая важная вещь в своих и чужих рекордах - это то, что они свои и чужие по полю Owner.
По дефолту, при создании рекорда овнером будет тот юзер, который создает рекорд. Но потом этого овнера можно сменить, и весь доступ перейдет к другому юзеру. Можно сделать кастомную форму, где овнера можно будет указать сразу. Для некоторых объектов можно настроить Assignment Rules, что бы этот самый овнер назначался автоматически зависимо от каких-то критериев. Овнером может быть не один юзер, а Queue, в которую входят несколько юзеров.И тут надо обратить внимание на то, что при связи Master-Detail у дочерних рекордов (которые Detail) овнера нет. Овнером этих дитейл-рекордов является овнер родительского рекорда.
Хоть он и является овнером, то что он овнер - еще не значит что у него есть доступ (смотрим выше - если доступа нет - то ничего не доступно)
Тут что бы увидеть дитейл-рекорды должен быть доступ и к родительскому рекорду, и к дочерним.
Создавая поле мастер-дитейл надо указывать какой уровень доступа необходим к родительскому рекорду, что бы можно было работать с дочерними.
Тут два варианта:
Read Only - что бы создавать-редактировать-удалять дочерние рекорды достаточно доступа Read к родительскому.
Read/Write - что бы создавать-редактировать-удалять дочерние рекорды нужен доступ Read/Write к родительскому (получается что создание, редактирование, удаление дочерних рекордов - это внесение изменений в родительский)
Если вам надо, что бы создавать дочерние рекорды могли только те, у кого есть доступ Read к родительскому - тогда при создании поля нужно указать первый вариант.
Если вам надо, что бы создавать дочерние рекорды могли только те, у кого есть доступ Read/Write к родительскому - тогда нужно указать второй вариант.
Если поле уже создали - нужно найти это поле на самом объекте (там где его создавали) и настроить в соответствии с требованиями.
Проблемы с доступом, с которыми можно столкнуться:
Есть объект Product. И есть объект Review - отзывы про этот продукт. Вроде кажется логичной связь мастер-дитейл, так как ревьюшки сами по себе существовать не могут, должны удаляться вместе с продуктом. Да и среднюю оценку на продукте легко подсчитать за счет Roll-Up Summary полей.
Продукты у нас создают одни юзеры, а ревьюшки пишут другие. Продавцы и клиенты. Что бы клиенты могли создавать ревьюшки на продукты, на поле мастер-дитейл мы укажем тип доступа к родительскому рекорду Read Only. Но клиенты должы еще и редактировать свои ревью. И вот тут мы столкнемся с недостатком такой связи. Можно дать клиентам доступ к редактированию вообще всех ревьюшек, или не давать доступ к редактированию вообще. Так как у ревью нет овнера, ревью не могут быть свои и чужие. Или редактируем все или вообще никакие.
И вы не можете сказать заказчику, что вам было удобнее сделать мастер-дитейл, поэтому с редактированием будет такая фигня)
Так что если нет необходимости именно в мастер-дитейл - делают лукап.
Это важно учитывать при создании модели шеринга (что кому должно быть доступно)
Пока это все, периодически буду дополнять)
Ставьте лайки, пишите комментарии 
