Мегаплан как CRM и управление задачами сравнивают с отдельными системами по правам сотрудников

Один сервис не означает, что продавец и исполнитель видят одинаковые данные. В справочнике Мегаплана доступ зависит от категории пользователя, участия в объекте, положения в структуре компании и групп. Название роли описывает лишь часть этой картины.

Передача задач между отделами требует согласованных статусов и ответственного за следующий шаг.

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

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

Начните с таблицы людей и действий. Для каждой роли укажите разрешённое и запрещённое. «Не должен видеть» столь же важно, как «должен работать»: сотрудник может открыть свою задачу и одновременно получить ненужный доступ к списку всех клиентов.

В примере ниже менеджер ведёт свою сделку, исполнитель сдаёт работу, руководитель распределяет задачи, подрядчик участвует в выделенной части заказа. Это отправная точка разговора с командой. Если вашей компании нужен другой порядок, меняется таблица, а не смысл проверки.

Права на чтение и права на изменение тоже разделите. Руководителю может быть нужен отчёт, но не возможность менять цену. Исполнитель может видеть срок, но просить перенос через согласование. Кто утверждает готовность заказа, решите до настройки автоматического завершения задачи.

Теперь возьмите реальные учётные записи. Исполнитель может оказаться начальником отдела или входить ещё в одну группу. Документация Мегаплана предупреждает: при нескольких группах сохраняются максимально возможные права. Проверка чистой роли не покрывает такого сотрудника.

Координирование тоже меняет доступ, но не открывает всё подряд. Справочник описывает, какие объекты координируемого видны и какая настройка даёт редактировать его задачи. Доступ координатора нужно проверить отдельно, а не приравнивать его к директору или обычному исполнителю.

Проверьте отчёт и внешнего участника. По документации Мегаплана отчёт показывает только доступные пользователю объекты. Внештатный сотрудник и контакт с гостевым доступом различаются; ограничение внештатников зависит от настройки. Нельзя считать доступ урезанным только потому, что в карточке стоит слово «внешний».

Разделение CRM и задач убирает часть общих экранов, но создаёт передачу заказа между системами. Нужно решить, какие данные уходят исполнителю: название работы, требования, срок, идентификатор заказа. Если вместе с ними копируются цена и весь контакт клиента, исходная проблема остаётся.

У передачи тоже есть права. Если связь настроена через отдельную учётную запись, запишите, что она читает и что меняет. Проверьте сбой: заказ пришёл повторно, срок обновился только в одном месте, сотруднику закрыли доступ, а копия осталась доступной. За исправление должен отвечать назначенный человек.

Сравните варианты на одном заказе и одной таблице прав. В общей системе проверяется настройка, в отдельных готовых системах ещё и передача, в собственном модуле ещё и сопровождение кода. Количество программ само по себе не определяет, кому доступны данные.

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

В таком случае можно сохранить CRM и разработать только исполнение. Менеджер продолжает вести сделку, модуль получает согласованный набор данных и возвращает состояние работы. Экономику полной замены разбираем в статье про свою CRM. Здесь граница уже: исправить подтверждённое расхождение в работе исполнителей.

Наш опыт относится к машине агентов на vibecoding.ru. Инженер ведёт машину агентов, которая строит в том числе собственную админку с «Контактами» и «Ручейками». На публичной карте машины админка выделена в отдельный регион. Мы не внедряли Мегаплан и не предъявляем клиентский кейс с этой CRM.

Работу агента начните с описания заказа, ролей и ожидаемого отказа в доступе. «Сделать удобную админку» не задаёт ни границ, ни приёмки. В постановке задач агенту разобрано, как превратить такое пожелание в проверяемую задачу.

Для разработки подготовьте вымышленные заказы и контакты. Не передавайте всю клиентскую базу только ради примера экрана. Как выбирать данные и среду для агента, разбираем в статье про персональные данные и агентов. Решение о доступе к рабочим данным принимается отдельно от решения написать код.

Устройство собственного пульта разбираем в уроке «Устройство админки» курса агентной разработки. Этот опыт помогает поставить вопросы об изменениях и проверках. Но он не отвечает вместо поставщика на вопрос, можно ли настроить конкретное ограничение в вашем Мегаплане.

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

Наши журналы показывают, почему эти проверки нужны. В одном случае защита страницы не покрывала прямые запросы данных. В другом разрешённое удаление задело соседнюю запись. Это разные сбои: право выполнить действие и правильность самого действия надо проверять отдельно.

Есть и ошибка приёмки: агент уверенно описывает проверку, которой не было. У нас независимый приёмник находил выдуманный внутренний замер и возвращал материал. Поэтому для модуля нужен результат испытания: кто вошёл, что попытался сделать и какой ответ получил. Фраза «права настроены» такого результата не заменяет.

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

Затем проверьте связь с CRM. Повторная передача не создаёт лишний заказ, смена срока видна там, где её ждут, а отказ связи заметен ответственному. Если нарушение проходит молча, разделённые системы только переносят проблему в другое место.

Закройте петлю: запишите расхождение, исправьте правило или реализацию, повторите тот же сценарий. После изменения ролей повторяется и проверка запретов. Так требования живут вместе с системой, а не остаются в документе, который подписали перед запуском.

Попросите команду выбрать заказ и пройти его от продажи до приёмки на вымышленных данных. В пилоте зафиксируйте тариф аккаунта, настройки и реальные назначения сотрудников. Страница тарифов Мегаплана предупреждает об архивных тарифах старых аккаунтов; сравнивать только текущие названия пакетов недостаточно.

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

Когда нужен именно код модуля исполнения, на странице услуг есть подписка «Один проект»: 250 000 ₽ в месяц. Инженер ведёт машину агентов и выполняет по одной задаче из очереди в репозитории клиента; пауза возможна в любой месяц. Это формат разработки, не обещание внедрить Мегаплан или закончить модуль за месяц. Условия проверены 8 октября 2026.

1. Опишите, что каждый сотрудник может читать, менять и подтверждать, а что ему запрещено.

2. Испытайте реальные назначения, совмещение групп, отчёты и отзыв доступа.

3. При разделении систем принимайте состав передачи и доступ к копиям данных.

4. Разрабатывайте модуль только под подтверждённое расхождение. После изменения ролей повторяйте проверку запретов.