Row-level security в отчетах: доступ по филиалам и менеджерам

Задача простыми словами: один отчет, разные данные

Иногда нужен один и тот же отчет для всех, но показывать он должен разное. Руководитель филиала видит только свой филиал, менеджер - только своих клиентов и продажи, а головной офис - всю картину. Это и есть Row-level security в отчетах: видимость строк данных зависит от того, кто открыл отчет.

Самый частый обходной путь - копировать витрины, отчеты или вкладки: «отчет для Алматы», «отчет для Астаны», «отчет для каждого менеджера». Сначала кажется удобно, но быстро начинается хаос. Меняются показатели, добавляются новые поля, правятся формулы - и вам нужно повторить это в десятках копий. Версии расходятся, цифры перестают совпадать, а поддержка превращается в гонку без финиша.

Риски тут не только в неудобстве. Если доступ настроен «на честном слове» (например, фильтром на странице или отдельной выгрузкой), данные легко показать не тем людям. Это может быть выручка другого филиала, зарплатные показатели, маржинальность или планы продаж. Дальше обычно идет цепочка проблем: утечки, споры из-за разных цифр и, главное, потеря доверия к отчетности.

Чаще всего в компании достаточно нескольких понятных ролей, которые потом превращаются в роли доступа в BI:

• сотрудник филиала - видит только свой филиал или участок;
• менеджер - видит только «своих» клиентов, сделки, планы;
• руководитель - видит команду целиком (например, всех менеджеров филиала);
• HQ (головной офис) - видит все филиалы и общий итог.

Хорошая цель звучит просто: один отчет, одна модель, единые метрики - и ограничения встроены в данные, а не в копии. Тогда показатель меняется один раз и одинаково корректно считается для всех, но каждый видит только то, что ему положено.

С чего начать: правила видимости и уровни доступа

Row-level security в отчетах начинается не с настроек в BI, а с договоренностей: какие данные считаются чувствительными и кому они реально нужны для работы. Если пропустить этот шаг, получится либо «всем все видно», либо «никто не может работать».

Сначала перечислите, что именно нужно скрывать. Часто это не только продажи, но и маржа, скидки, список клиентов, условия договоров и персональные данные. Важно заранее решить, скрываете ли вы сами записи (строки) или еще и детали внутри записи. Пример: показывать продажи по филиалу, но не показывать ФИО клиентов.

Дальше определите уровни доступа и смысл каждого уровня. Обычно хватает 3-4 уровней: филиал, регион, команда и конкретный менеджер. При этом один и тот же человек может попадать сразу в несколько правил, и это нормально: менеджер видит свой портфель, руководитель - команду.

Правила лучше фиксировать простыми фразами, без технических терминов. Например:

• менеджер видит только свои сделки и своих клиентов;
• руководитель команды видит все по своей команде;
• региональный руководитель видит филиалы региона;
• бэк-офис видит все, но без персональных данных;
• финансы видят маржу и скидки, остальные - только выручку.

Отдельно зафиксируйте исключения, иначе они «сломают» модель в самый неподходящий момент. Типичные случаи: временная замена менеджера (отпуск), совместные сделки (два менеджера), матричное руководство (функциональный руководитель), руководители, которым нужен сквозной обзор.

Наконец, проведите границу между ограничением строк и ограничением детализации. RLS отвечает на вопрос «какие записи видны», но иногда нужно дополнительно скрыть поля или показатели (например, маржу) даже внутри разрешенных строк. Это лучше согласовать заранее, чтобы не переделывать отчет после запроса «покажите всем, но без маржи и без клиентов».

Как устроить модель данных, чтобы RLS работал

Чтобы Row-level security в отчетах работал предсказуемо, начинайте не с ролей, а с модели. RLS чаще ломается не из-за формулы, а из-за того, что филиал или менеджер в фактах хранится по-разному, связи неоднозначные, а ключи не совпадают.

Основа - отдельные справочники. Делайте таблицу «Филиалы» и таблицу «Менеджеры» как измерения, а продажи, планы, заявки и другие события - как факты. В справочниках держите стабильные идентификаторы и атрибуты (название, регион, статус), но не пользователя.

Дальше важен маршрут, по которому фильтр попадает в факты. Если в строках факта уже есть BranchID, то связь «Филиалы -> Факт» должна быть один-ко-многим и однозначной. Если филиал определяется через магазин, отдел или проект, добавьте промежуточное измерение и обеспечьте один понятный маршрут фильтрации. Иначе RLS начнет давать разные результаты в разных визуализациях.

Таблица сопоставления «пользователь -> доступ» обычно делается отдельной связующей таблицей (bridge). В ней каждая строка - пользователь и объект доступа: филиал и, при необходимости, менеджер. Один руководитель видит 3 филиала - значит у него 3 строки. Менеджер работает в нескольких филиалах - это тоже решается строками, а не копированием витрин.

Ключи должны быть едиными и «чистыми». Для объектов (филиал, сотрудник) используйте внутренний ID из мастер-системы (число или UUID), а не название. Для пользователя используйте тот идентификатор, который реально приходит в BI при входе (логин или UPN), и храните его в одном формате.

Чтобы не ломать агрегаты и итоги при фильтрации, проверьте базовые вещи:

• фильтры от справочников идут в факты по одному маршруту, без двусмысленных связей;
• нет отношений многие-ко-многим там, где можно обойтись bridge-таблицей;
• итоги считаются по фактам, а не по справочникам (иначе «пустые» филиалы будут вести себя странно);
• доступ «все филиалы» не оформляется отдельной ролью, им управляют через матрицу.

На практике это выглядит так: таблица «Продажи» хранит BranchID и ManagerID, «Филиалы» и «Менеджеры» связаны с ней, а «Доступы» связывает пользователя с разрешенными BranchID и ManagerID. Тогда RLS становится простым: вы ограничиваете «Доступы» по текущему пользователю, и фильтр сам доходит до нужных фактов, не ломая общие суммы.

Статический и динамический RLS: что выбрать

Row-level security в отчетах можно настроить двумя базовыми способами: статически (фиксированные роли) или динамически (правила зависят от пользователя). Оба варианта решают одну задачу - показать людям только свои филиалы, команды или клиентов. Разница в том, сколько ручной работы вам придется делать дальше.

Статический RLS: проще стартовать, сложнее расти

Статические роли подходят, когда структура стабильна и вариантов доступа мало. Например, у вас 5-10 филиалов, изменения редкие, а пользователей немного.

В этом подходе вы создаете роли вроде «Филиал Алматы», «Филиал Астана» и вручную добавляете людей в нужную роль. Это легко объяснить бизнесу и быстро запустить пилот.

Минусы проявляются позже: любое перемещение менеджера, открытие нового филиала или подмена на отпуск превращаются в поток ручных правок. Еще хуже, когда роли начинают дробиться: «Алматы - руководители», «Алматы - продавцы», «Алматы - стажеры». Поддержка разрастается вместе с оргструктурой.

Динамический RLS: меньше ручной работы, больше порядка

Динамический RLS нужен, когда пользователей много, а перестановки частые. Вместо десятков ролей вы делаете одну-две роли и связываете доступ с таблицей прав (матрицей), где указано, какой пользователь видит какой филиал, подразделение или менеджеров.

Обычно это работает так: пользователь входит под корпоративной учетной записью, BI берет его логин (или e-mail) и находит его в таблице прав. По найденным строкам фильтруются нужные филиалы и данные.

Если использовать корпоративные группы (например, отдел продаж, региональные команды), управление можно отдать ИБ или HR. Человека перевели в другой отдел - обновилась группа, и доступ изменился без редактирования отчета.

Таблица прав удобна еще и для контроля: вы открываете матрицу и сразу видите, кто и почему имеет доступ.

Пример: в розничной сети менеджер Иван сегодня отвечает за филиалы А и Б, а завтра только за Б. При статических ролях администратор правит роли в отчете. При динамическом RLS достаточно обновить строки в матрице доступов - и все отчеты, которые на нее опираются, покажут корректные данные.

Чтобы выбрать вариант, ответьте на несколько вопросов:

• сколько филиалов и пользователей будет через год;
• как часто меняются зоны ответственности;
• нужны ли временные доступы (замены, проекты, командировки);
• важен ли понятный аудит: кто кому и на каком основании открыл доступ.

Если ответы про рост и частые изменения - лучше сразу закладывать динамический RLS с матрицей прав и корпоративными группами.

Пошагово: как настроить ограничение по филиалам и менеджерам

Чтобы Row-level security в отчетах работал без копирования витрин, начинайте не с кнопок в BI, а с правил: кто что должен видеть и в каких случаях доступ расширяется (например, на время замещения).

1) Зафиксируйте роли и уровни видимости

Опишите 2-3 роли человеческим языком и привяжите их к уровням данных. Часто хватает схемы: сотрудник видит только свой филиал, менеджер - свой список клиентов или свой план, руководитель - команду или регион. Сразу разберите спорные места: видит ли менеджер планы других, видит ли руководитель персональные показатели, как обрабатываются совместные продажи.

2) Подготовьте таблицу прав (матрицу доступов)

Нужен один источник прав, где каждая строка - это разрешение. Не делайте «одну колонку на филиал», делайте «пользователь - объект доступа». Минимальный набор полей:

• логин (как он приходит из учетной записи);
• тип доступа (филиал, менеджер, регион);
• код филиала или ID менеджера (тот же ключ, что в фактах);
• дата начала и, при необходимости, дата окончания;
• примечание или владелец изменения (чтобы разбирать спорные случаи).

3) Свяжите таблицу прав с моделью

В модели данных таблица прав должна соединяться с теми же справочниками, через которые фильтруются факты: филиалы, сотрудники, менеджеры. Главное правило: фильтр должен доходить до продаж, планов и других показателей по обычным связям. Если связи «ломаются» или идут обходными путями, RLS будет давать неожиданные дыры.

4) Настройте правило фильтра и проверьте на тестовых учетках

Создайте роль и задайте условие: показывать строки, где логин текущего пользователя совпадает с логином в таблице прав. После этого проверьте минимум три сценария: сотрудник одного филиала, менеджер с доступом к двум филиалам, руководитель региона. Тестируйте не только суммы, но и детализацию: таблицы, карточки, выгрузки.

5) Согласуйте процесс обновления прав

Даже идеальная настройка разваливается, если непонятно, кто меняет доступ. Назначьте владельца матрицы (часто это HR, служба безопасности или руководитель продаж) и простой регламент: как добавляем нового сотрудника, как закрываем доступ при увольнении, как оформляем временное расширение.

Пример: менеджер А ведет филиалы 01 и 02, менеджер Б - только 03. В матрице это будут три строки, а не три копии витрины. В отчете оба видят один и тот же дашборд, но цифры разные, потому что фильтр проходит через справочник филиалов к фактам продаж и планов.

Где хранить и как обновлять матрицу доступов

Матрица доступов - это таблица, которая отвечает на простой вопрос: какой пользователь какие строки данных может видеть. Для Row-level security в отчетах важно, чтобы эта таблица была единственным источником прав, а не набором ручных исключений в разных витринах.

Лучший источник для матрицы - операционные системы. Обычно это HR (штат, оргструктура, руководители) и CRM (закрепление клиентов, регионов, менеджеров). Если назначения менеджеров живут в CRM, берите их оттуда. Если филиал и должность фиксируются в HR, берите из HR. Главное - не плодить отдельные «справочники» в Excel на чьем-то компьютере.

Что хранить в матрице

Чтобы права были понятными и проверяемыми, держите минимум полей:

• UserID (почта или доменная учетная запись);
• уровень доступа (филиал, регион, конкретный менеджер);
• ключ доступа (код филиала или ID менеджера);
• дата начала и дата окончания (для временных назначений);
• источник и причина (HR, CRM, приказ, проект).

История изменений решает проблему переездов и ротаций. Если менеджер сменил филиал, не перезаписывайте строку: закрывайте старое назначение датой окончания и добавляйте новое. Тогда отчеты за прошлые периоды можно показывать корректно: по старой структуре или по текущей (это уже бизнес-правило), но матрица должна позволять оба варианта.

Временный доступ (отпуск, подмена, проект) удобнее делать не отдельными ролями, а сроком действия. Руководителю продаж добавили доступ к филиалу на 2 недели - он автоматически исчезает после даты окончания. Это сильно снижает риск «забытых» расширенных прав.

Как обновлять без ручных правок

Автоматизация обычно сводится к расписанию загрузки и простым контролям качества:

• регулярная выгрузка из HR и CRM (например, раз в сутки);
• склейка по стабильным ключам (UserID, коды филиалов, ID сотрудников);
• проверки на дубликаты, пустые ключи, назначения без даты начала;
• лог изменений (что поменялось, даже если источник внешний);
• сигнал при аномалиях (менеджер без филиала, филиал без руководителя).

Практический пример: Иванова перевели из филиала А в филиал Б, а на время передачи дел дали доступ к обоим на 10 дней. В матрице это выглядит как закрытое назначение для А, новое для Б и временная строка на параллельный доступ. В отчете права будут вести себя предсказуемо, без копирования витрин.

Частые ошибки и ловушки при внедрении RLS

Даже если Row-level security в отчетах настроен формально правильно, проблемы часто начинаются на стыке данных, справочников и реальных процессов.

1) Пользователь идентифицируется неправильно

Частая причина утечек или, наоборот, пустых отчетов - неверный ключ пользователя. Логины меняются, в AD бывают дубликаты, кто-то заходит через UPN, а в матрице доступов записан e-mail. В итоге один человек получает чужие права, а другой теряет свои.

Практика простая: выберите один стабильный идентификатор (например, корпоративный UPN) и используйте его везде одинаково: в матрице доступов, в таблице пользователей, в правиле RLS.

2) В фактах нет филиала (или он пустой)

Роли часто строят по филиалу, но в таблице продаж или обращений поле «Филиал» заполнено не всегда или заполняется разными значениями. Тогда фильтр не срабатывает: либо показывается лишнее, либо не показывается ничего.

Перед настройкой проверьте:

• есть ли в фактах ключ филиала на каждой строке;
• нет ли строк с пустым филиалом;
• совпадают ли коды филиалов между фактами и справочником;
• не смешаны ли названия и коды («Алматы» vs «ALM»);
• есть ли единый справочник филиалов, а не несколько похожих.

3) Смешивание ролей и неожиданные «суммы прав»

Жизнь сложнее схемы «один человек - один филиал». Руководитель может временно замещать коллегу, менеджер ведет клиентов в двух регионах, бухгалтерии нужен доступ к нескольким филиалам. Если пользователь попадает сразу в несколько ролей, он увидит объединение доступов. Иногда это правильно, иногда нет.

Чтобы не запутаться, не плодите роли вручную. Храните матрицу «пользователь - сущность доступа» (филиал, менеджер, подразделение) и делайте правило так, чтобы его можно было объяснить одной фразой. В спорных случаях добавляйте тип доступа (например, «только свой филиал» или «по списку») и фиксируйте, кто выдает такие права.

4) Обход ограничений через экспорт и детализацию

RLS должен работать не только на графиках. Проверьте, что пользователь не получает лишнее через экспорт данных, «показать как таблицу», детализацию по клику и страницы с деталями. Это особенно важно там, где есть персональные планы и KPI.

5) Слишком сложные правила, которые никто не поддерживает

Если правило выглядит как «магия» и держится на одном человеке, оно сломается при первой реорганизации. Простая схема и понятная матрица доступов почти всегда лучше, чем хитрый набор исключений.

Ориентир: если завтра поменяются руководители и зоны ответственности, вы должны обновить доступы заменой строк в матрице, а не переписыванием формул и ролей.

Как проверить, что ограничения работают правильно

Проверка RLS отвечает на простой вопрос: один и тот же отчет показывает разные данные разным людям, и при этом цифры остаются корректными. Ошибка часто прячется не в таблицах, а в итогах, фильтрах и «особых» пользователях.

Начните с 3-5 тестовых пользователей, которые представляют разные роли: менеджер филиала, руководитель филиала, руководитель региона, сотрудник бэк-офиса (видит несколько филиалов), администратор (видит все). Удобно завести отдельные тестовые учетные записи, чтобы проверки можно было повторять после изменений модели.

Минимальный набор проверок

Прогоняйте один и тот же набор страниц и визуализаций, меняя только пользователя:

• видимость строк (таблица с деталями): «чужие» филиалы и менеджеры не появляются ни при сортировке, ни при поиске;
• итоги и подитоги: суммы считаются только по разрешенным данным, без «подмешивания» скрытых строк;
• фильтры и срезы: пользователь не может выбрать запрещенный филиал даже через поиск по значениям;
• экспорт и детализация: при выгрузке и проваливании в детали остаются те же ограничения;
• пустые результаты: если у пользователя нет доступа, отчет корректно показывает пусто (а не ошибку и не «все данные»).

Дальше сделайте сверку по контрольным цифрам. Это заранее известные числа по конкретному филиалу за период: выручка, количество заказов, план, маржа. Контрольные значения лучше брать из доверенного источника (например, закрытый реестр или выгрузка из учетной системы) и фиксировать для теста.

Отдельно проверьте исключения: руководитель региона видит все свои филиалы, временная замена менеджера дает доступ только на срок замещения, совместительство не раскрывает лишние филиалы. На практике именно исключения ломают логику чаще всего.

Чтобы тест не был разовым «пробегом», зафиксируйте сценарии: кто тестируется, какие страницы, какие фильтры, какие контрольные цифры и ожидаемый результат. Тогда проверку можно быстро повторять перед релизом обновлений отчетности.

Пример: розничная сеть с филиалами и персональными планами

Представим розничную сеть из 8 филиалов. Есть один отчет по продажам и планам, но данные должны отличаться для разных людей. Здесь хорошо подходит Row-level security в отчетах: один набор данных, а видимость режется по правилам.

Менеджер магазина открывает отчет и видит только свои сделки, свою выручку и свой план. Он сравнивает себя с прошлым месяцем, но не видит других менеджеров, даже в том же филиале. Директор филиала видит всех менеджеров своего филиала, региональный руководитель - филиалы своего региона, а головной офис (HQ) - всю сеть.

Чтобы это работало без копирования витрин, в модели обычно разделяют факты (продажи, планы, возвраты), справочники (филиалы, регионы, менеджеры) и таблицу прав (кто к чему имеет доступ).

Сложный момент: один клиент обслуживается двумя филиалами. Например, корпоративный клиент закупает в филиале А, но иногда отгружается через филиал Б. Тут есть два понятных варианта.

Первый: привязать продажи к филиалу отгрузки и в правах дать доступ к клиенту обоим филиалам через отдельную таблицу исключений (клиент - филиал).

Второй: ввести правило «основной филиал клиента» и показывать такие продажи только основной команде, а второму филиалу давать доступ только к агрегату (без деталей по менеджерам).

Выбор зависит от того, как в компании считают ответственность и бонусы.

Еще один жизненный кейс: менеджера переводят в другой филиал. В идеале в матрице доступов меняется только назначение (и, при необходимости, дата начала). После этого в отчете он сразу видит новые данные. Важно заранее решить, что делать с историей: показывать ли старые продажи менеджера после перевода. Обычно это оформляют правилом «видимость по текущему филиалу» или «видимость по филиалу на момент продажи».

Иногда нужен общий отчет для обсуждения на планерке, но без персональных деталей. Тогда делают отдельную страницу или отдельный набор визуализаций, где данные агрегированы до уровня филиала или региона, а поля с менеджерами скрыты или недоступны по роли.

Чек-лист и следующие шаги для внедрения без боли

Row-level security в отчетах держится не на одной настройке роли, а на дисциплине: понятные правила, одна таблица прав и регулярная проверка.

Быстрый чек-лист перед запуском

• В модели есть четкие ключи для связи фактов с филиалом и менеджером (без дублей и «серых зон»).
• Таблица прав отделена от бизнес-данных и обновляется из понятного источника.
• Роли проверены на тестовых пользователях: минимум «менеджер», «руководитель филиала», «центральный офис».
• Есть негативные тесты: пользователь точно не видит чужой филиал и чужие планы.
• В отчете нет обходных путей (страниц или визуализаций, которые тянут данные в обход фильтров модели).

Кто отвечает за права и как их поддерживать

Назначьте владельца процесса. Обычно это не BI-разработчик, а бизнес-роль: например, руководитель продаж или администратор учетных записей. Его задача - подтверждать, кто кому подчиняется, какие филиалы доступны и когда доступ нужно убрать.

Дальше нужен простой регламент: как добавлять новых сотрудников, что делать при переводе в другой филиал, как быстро закрывать доступ при увольнении и как часто проводить ревизию (например, раз в месяц).

Если отчеты начинают тормозить из-за усложнения модели и правил, чаще всего помогает не «еще один фильтр», а аккуратная пересборка модели и надежная инфраструктура. В больших организациях, где BI и хранение данных должны работать стабильно, может быть полезна системная интеграция и инфраструктурные решения от GSE.kz (например, серверы S200 для размещения BI и данных) с поддержкой 24/7 и сервисной сетью по Казахстану.

Следующий шаг после внедрения - завести календарь проверок и один «контрольный» набор тестовых пользователей, чтобы любой релиз можно было прогнать за 10-15 минут.