В Notion 3.8 появились более детальные возможности управления свойствами и историей изменений. Для товарного справочника это важно там, где закупка, контент и другие сотрудники работают с одной базой, но не должны одинаково изменять каждое поле. Новость относится к функциям Notion, а не к готовой интеграции с кабинетами маркетплейсов.

Что показал релиз 13 октября

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

Разделите поля по реальной ответственности

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

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

Используйте историю для расследования конкретной правки

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

В материале о владельце товарных данных разобраны организационные правила такой работы. Релиз Notion добавляет технические средства для их реализации, но не заменяет основание изменения. История показывает действие в системе; причину выбора новой комплектации нужно хранить в принятом журнале или связанном документе.

Проверьте модель на тестовой базе

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

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