Настройте йерархична защита за подробен достъп до данни
Бележка
Ако сте активирали режима само за Унифициран интерфейс, преди да използвате процедурите в тази статия, направете следното:
- Изберете Настройки (
) в лентата за навигация. - Изберете Разширени настройки.
Моделът за защита на йерархията е разширение на съществуващите модели на защита на Dynamics 365 Customer Engagement (on-premises), които използват бизнес единици, права за достъп, споделяне и екипи. Може да се използва заедно с всички останали съществуващи модели за защита. Защитата на йерархията предлага по-детайлен достъп до записи за дадена организация и помага да се намалят разходите за поддръжка. Например в сложни сценарии можете да започнете със създаването на няколко бизнес единици и след това да добавите защита на йерархията. Това ще допринесе за по-детайлен достъп до данни с далеч по-малко разходи за поддръжка, отколкото се изисква за голям брой бизнес единици.
Модели за защита на йерархия на мениджър и йерархия на позиция
Два модела за защита могат да се използват за йерархии – йерархия на мениджър и йерархия на позиция. С йерархията на мениджър, мениджърът трябва да бъде в същата бизнес единица като отчета или в родителската бизнес единица бизнес единицата на отчета, за да има достъп до данните от отчета. Йерархията на позиция позволява достъп до данни между бизнес единици. Ако сте финансова организация, може да предпочетете модела на йерархия на мениджър, за да предотвратите достъпа до данни на мениджърите извън техните бизнес единици. Въпреки това, ако сте част от организация за обслужване на клиенти и искате мениджърите да получат достъп до случаи на услугата, разглеждани в различни бизнес единици, йерархията на позиция може да е по-добрият вариант за вас.
Бележка
Докато моделът на защита на йерархията осигурява определено ниво на достъп до данни, допълнителен достъп може да бъде получен чрез използване на други форми на защита, като например права за достъп.
Йерархия на мениджър
Моделът на йерархията на мениджър се базира на управленска верига или пряка отчетна структура, където релациите на мениджъра и отчета се установяват чрез полето „Мениджър“ в обекта на системния потребител. С този модел на защита мениджърите могат да получат достъп до данните, до които техните отчети имат достъп. Те са в състояние да работят от името на техните директни отчети или да осъществят достъп до информация, която се нуждае от одобрение.
Бележка
С модела за защита на йерархията на мениджър, мениджърът има достъп до записите, притежавани от потребителя или екипа, на който потребителят е член, и до записите, които са директно споделени с потребителя или екипа, на който потребителят е член. Когато даден запис се споделя от потребител, който е извън веригата на управлението, с пряко подчинен потребител с достъп само за четене, мениджърът на пряк подчинен има достъп до споделения запис само за четене.
В допълнение към модел на защита на йерархия на мениджър, мениджърът трябва да има поне привилегиите за четене на ниво потребител, за да види данните от отчетите. Например, ако мениджърът не разполага с достъп за четене до обекта „Случай“, мениджърът няма да може да види случаите, до които неговите отчети имат достъп.
За непряк подчинен в същата верига на управление на мениджър мениджърът има достъп само за четене до данните на непряк подчинен. За директен отчет, мениджърът има достъп „Четене“, „Писане“, „Актуализиране“, „Добавяне“ и „Добавяне към“ към данните на отчета. За да илюстрираме модела за защита на йерархията на мениджър, нека да разгледаме диаграмата по-долу. Изпълнителният директор може да чете или актуализира данните на вицепрезидента по продажбите и данните на вицепрезидента по услугите. Въпреки това главният изпълнителен директор може само да чете данните на мениджъра по продажбите и данните на мениджъра по услугите, както и данните за продажбите и услуги. Можете допълнително да ограничите количеството данни, достъпни от даден мениджър с „Дълбочина“. „Дълбочина“ се използва за ограничаване на броя нива по дълбочина, до които мениджърът има достъп само за четене на данни от техните отчети. Например, ако дълбочината е зададена на 2, главният изпълнителен директор може да види данните на вицепрезидента по продажбите, вицепрезидента по услугите и мениджърите по продажбите и услугите. Въпреки това главният изпълнителен директор не вижда данните за продажби или данните за поддръжката.
Важно е да се отбележи, че ако един директен отчет има по-голям достъп за защитата до обект от мениджъра му, мениджърът може да не може да види всички записи, до които директният отчет има достъп. Следващият пример илюстрира тази точка.
Една бизнес единица има трима потребители: потребител 1, потребител 2 и потребител 3.
Потребител 2 е директен отчет на потребител 1.
Потребител 1 и потребител 3 имат потребителско ниво на достъп за четене за обекта клиент. Това ниво на достъп дава на потребителите достъп до притежавани от тях записи, споделени с потребителя записи и записи, които са споделени с екипа, на който потребителят е член.
Потребител 2 има достъп за четене на бизнес единица за обекта клиент. Това позволява на потребител 2 да види всички клиенти за бизнес единицата, включително всички клиенти, притежавани от потребител 1 и потребител 3.
Потребител 1, като пряк мениджър на потребител 2, има достъп до отчетите, притежавани от или споделени с потребител 2 и клиенти, които са споделени с или притежавани от екип, на които потребител 2 е член. Потребител 1 обаче няма достъп до акаунтите на Потребител 3, въпреки че неговият пряк подчинен може да има достъп до акаунтите на Потребител 3.
Йерархия на позиция
Йерархията на позиция не се базира на структура с директно отчитане, като йерархията на мениджър. Не е нужно потребителят да е действителен мениджър на друг потребител за достъп до данните на потребителя. Като администратор ще дефинирате различните работни места в организацията и ще ги подредете в йерархията на позиция. След това можете да добавяте потребители към дадена позиция, или, както казваме, да сложите „етикет“ на потребител с определена позиция. Потребителите могат да бъдат маркирани само с една позиция в дадена йерархия, но дадената позиция може да се използва за множество потребители. Потребителите на по-високи позиции в йерархията имат достъп до данните на потребителите на по-ниски позиции в пътя на пряк предшественик. Директните по-високи позиции позволяват достъп за „Четене“, „Писане“, „Актуализиране“, „Добавяне“ и „Добавяне към“ до данните на по-ниските позиции в пътя на пряк предшественик. Недиректните по-високи позиции позволяват права „Само за четене“ до данните на по-ниските позиции в пътя на пряк предшественик.
За да илюстрираме концепцията за пътя на пряк предшественик, нека да погледнем диаграмата по-долу. Позицията „Мениджър по продажбите“ има достъп до данните за продажбите, но няма достъп до данните за поддръжката, които са в различен път на предшественик. Същото се отнася и за позицията „Мениджър по услугите“. Тя няма достъп до данни за продажбите, което са в пътя на продажбите. Както и в йерархията на мениджър можете да ограничите количеството данни, достъпни от по-високи позиции с „Дълбочина“. Дълбочината ще ограничи колко нива по дълбочина по-висока позиция има достъп „Само за четене“ на данните от по-ниските позиции в пътя на пряк предшественик. Например, ако дълбочината е зададена на 3, позицията на изпълнителен директор може да вижда докрай данните от позициите „Вицепрезидент по продажбите“ и „Вицепрезидент по поддръжката“ до позициите „Продажби“ и „Поддръжка“.
Бележка
С модела за защита на йерархията на позиция, потребителите на по-висока позиция имат достъп до записите, притежавани от потребителите на по-ниска позиция или от екипа, на който потребителят е член, и до записите, които са директно споделени с потребителя или екипа, на който потребителят е член.
Освен моделът за защита на йерархия на позиция потребителите на по-високо ниво трябва да имат поне привилегиите за четене на ниво потребител за даден обект, за да видят записите, до които потребителите на по-ниско ниво имат достъп. Например, ако потребител на по-високо ниво не разполага с достъп за четене до обекта „Случай“, потребителят няма да може да види случаите, до които потребителите на по-ниски позиции имат достъп.
Настройване на защита на йерархия
За да настроите защитата на йерархията, трябва да имате администраторски права за достъп.
Защитата на йерархията е забранена по подразбиране. За да разрешите:
Отидете в Настройки>Сигурност.
Изберете Йерархична защита и изберете Разрешаване на йерархично моделиране.
Важно
За да направите промени в Защита на йерархията, трябва да имате привилегията Промяна на настройките за защита на йерархията.
След като разрешите моделирането на йерархия, изберете конкретния модел, като изберете Йерархия на мениджър или Йерархия на позиция по избор. Всички системни обекти са разрешени за фабрично зададена защита на йерархия, но можете да изключите определени обекти от йерархията. Прозорецът Защита на йерархията, показан по-долу:
Задайте Дълбочина на желаната стойност за ограничаване на броя нива по дълбочина, до които мениджърът има достъп „Само за четене“ до данни от техните отчети. Например, ако дълбочината е равна на 2, мениджърът има достъп само до собствените си акаунти и сметките на отчетите на две нива дълбочина. В нашия пример, ако влезете в Приложения на Customer Engagement не като администратор, който може да вижда всички акаунти, а като вицепрезидент по продажбите, ще можете да виждате само активните акаунти на потребителите, показани в червения правоъгълник, както е показано по-долу:
Бележка
Докато защитата на йерархията предоставя на вицепрезидента по продажбите достъп до записите в червения правоъгълник, допълнителен достъп може да бъде наличен въз основа на правата за достъп, които има вицепрезидента по продажбите.
Задаване на йерархиите на мениджър и позиция
Йерархията на мениджър лесно се създава чрез релацията на мениджъра в записите на системния потребител. Можете да използвате справочното полето „Мениджър“ (ParentsystemuserID), за да укажете мениджъра на потребителя. Ако вече сте създали йерархията на позицията, можете също да поставите етикет на потребителя на определена позиция в йерархията на позиция. В следващия пример специалистът по продажбите се отчита на мениджърът по продажбите в йерархията на мениджър и също има позицията „Продажби“ в йерархията на позиция:
За да добавите потребител към дадена позиция в йерархията на позиция, използвайте справочното поле, наречено „Позиция“ във формуляра на отчета на потребителя, както е показвано по-долу:
Важно
За да добавите потребител към позиция или да промените позицията на потребителя, трябва да имате привилегията Присвояване на позиция за потребител.
За да промените позицията във формуляра на записа на потребителя, на лентата за навигация изберете Още (...) и да изберете различна позиция, както е показано по-долу:
За да създадете йерархия на позицията:
Отидете в Настройки>Сигурност.
Изберете Позиции.
За всяка позиция предоставете името на позицията, родителя на позицията и описанието. Добавете потребители към тази позиция чрез справочно поле, наречено Потребители на посочената позиция. По-долу следва пример за йерархията на позиция с активните позиции.
Примерът на разрешените потребители със съответните им позиции е показан по-долу:
Съображенията за производителност
За да се увеличи производителността, препоръчваме:
Запазване на ефективна защита на йерархията за 50 потребители или по-малко съобразно мениджър/позиция. Вашата йерархия може да има повече от 50 потребители под мениджър/позиция, но можете да използвате настройката „Дълбочина“ за намаляване броя на нивата за достъп „Само за четене“, като така ограничавате ефективният брой потребители под мениджър/позиция за 50 потребители или по-малко.
Използвайте модели за защита на йерархията заедно с други съществуващи модели за защита за по-сложни сценарии. Избягвайте да създавате голям брой бизнес единици, като вместо това създайте по-малко на брой бизнес единици и добавете защита на йерархията.
Вижте също
Концепции за защита за Microsoft Dynamics 365 for Customer Engagement
Заявка и визуализиране на йерархични данни