Notion или Buildin: приёмка базы знаний строится на одном наборе проверок. Учебная команда: Марина — владелец, Павел — приглашённый читатель. Дерево «Команда» → «Регламенты» → «Публикация статьи». Первые две страницы закрыты Павлу, третья предоставлена ему на чтение. В третьей прикреплён publication-demo.pdf со строкой CHECK-PDF-05. База Tasks лежит у Марины и Павлу не открывается.
Что именно принимается: три страницы, две роли, PDF, три записи
Приёмка идёт по фиксированному списку объектов. Список короткий, поэтому его реально пройти целиком за один сеанс и повторить на второй платформе.
| Объект | Ожидаемое состояние | Кто проверяет |
|---|---|---|
| «Команда» | Закрыта Павлу | Марина и Павел |
| «Регламенты» | Закрыта Павлу | Марина и Павел |
| «Публикация статьи» | Читается Павлом | Павел |
| publication-demo.pdf | Открывается, видна строка CHECK-PDF-05 | Павел |
| Tasks: T01 | Проверить источники, Готово, Марина, 2026-11-06 | Марина |
| Tasks: T02 | Подготовить макет, В работе, Марина, 2026-11-07 | Марина |
| Tasks: T03 | Согласовать выпуск, Не начато, Марина, 2026-11-08 | Марина |
Обе учётные роли участвуют в приёмке. Марина редактирует все страницы и Tasks. Роль читателя здесь не формальность: именно она вскрывает наследование прав, которое владелец может не замечать.
Три записи Tasks заданы с ID, названием, Status, Owner и Due. Совпадение всех пяти полей по каждой строке — минимальный порог. Если после переноса поле потерялось, его восстанавливают вручную и отдельно отмечают затраты времени. Приёмка фиксирует факт ручной работы.
Порядок проверки: база, свойства, записи, потом представление
Последовательность важнее скорости. Сначала подтверждают объект базы, затем сохранённые свойства, затем записи, и только после этого настраивают представление. Обратный порядок даёт ложную картину.
Порядок действий под Мариной:
- Открыть базу Tasks и убедиться, что это объект базы.
- Сверить свойства: Status, Owner, Due присутствуют и имеют ожидаемый тип.
- Сверить три записи T01, T02, T03 по ID, названию, Status, Owner и Due.
- Создать вид «По статусу» с группировкой по Status.
- Убедиться, что в колонках «Готово», «В работе», «Не начато» стоит по одной карточке: T01, T02, T03 соответственно.
Пустая или ненастроенная доска сама по себе не доказывает, что импорт пришёл плоской таблицей. Отсутствие объекта базы или свойств требует отдельной диагностики: сначала проверяют данные, потом вид. Официальная справка Notion описывает механику CSV-импорта: строки становятся страницами, колонки — свойствами, а новые relations и formulas автоматически не создаются, их пересобирают вручную после импорта. Этот пункт стоит держать в чек-листе отдельной строкой.
Практический вывод: если карточек на доске меньше трёх, вопрос не в оформлении вида. Сначала перепроверяют записи и свойства, и только потом возвращаются к группировке.
Доступ: наследование и широкие права проверяются заново
Права в принимающем сервисе настраивают заново. Автоматический перенос списков доступа при смене платформы не предполагается, и это закладывают в план работ.
В справке Notion по совместной работе описано наследование: подстраница принимает права родительской страницы, а изменить их можно на уровне самой подстраницы. Там же описан приоритет: сервис уважает наиболее широкий уровень доступа, выданный пользователю. Одно узкое право не отменяет более широкую выдачу через другую часть меню доступа. Практический смысл для приёмки: недостаточно проверить одну настройку на одной странице.
Проверка под Павлом:
- Открыть «Публикация статьи» — текст читается.
- Открыть publication-demo.pdf — видна строка CHECK-PDF-05.
- Попытаться изменить текст на разрешённой странице — правка отклоняется.
- Открыть прямые ссылки на «Команда» и «Регламенты» — доступ отклоняется.
- Открыть прямые ссылки на Tasks — доступ отклоняется.
Поиск закрытого названия даёт дополнительную проверку метаданных, и одного отсутствия в поиске недостаточно вместо прямой проверки доступа. Отрицательные результаты здесь так же важны, как положительные: они показывают, что узкая выдача не перекрыта широкой.
Что подтверждено про Buildin и что берут на проверку
Собственный материал Buildin описывает импорт через Notion API: подключение аккаунта, выбор рабочего пространства, воссоздание страниц со связями баз данных и форматированием. Это заявление вендора. Оно не является гарантией переноса любых связей и прав, поэтому в приёмку его берут как гипотезу, которую проверяют тем же договором.
В своём разборе переезда с Notion Глеб Клинов уже описал успешный импорт базы в Buildin, после которого потребовалось заново настроить шапку. Здесь проверка ограничена конкретным учебным набором: тремя страницами, двумя ролями, PDF и полями Tasks. Импорт в рамках подготовки этой статьи не выполнялся.
| Проверяемая часть | Что подтверждено | Эталон учебной приёмки |
|---|---|---|
| Перенос в Buildin | Вендор описывает импорт через Notion API | Сверить три имени страниц, связи parent-child, три ID и свойства задач; потерю поля восстановить вручную |
| CSV в Notion | Справка: строки — страницы, колонки — свойства, новые relations и formulas не создаются | Проверить три записи, названия, Status, Due; собрать вид «По статусу» |
| База и вид | Сначала объект базы, свойства и записи, затем board | Пустой board не доказывает плоскую таблицу |
| Доступ | Права настраиваются заново в принимающем сервисе | Марина редактирует всё; Павел читает «Публикация статьи» и PDF |
| Файл | Присоединение и хранение PDF проверяются отдельно | Павел видит CHECK-PDF-05; картинка или пустая ссылка не принимается |
Условия использования Buildin командой проверяют отдельно от технического переноса. Если согласованный перенос через Notion API проходит тот же договор, платформа попадает в короткий список. Если нет — остаётся Notion.
Условное решение: остаться или переносить
Решение принимают по результату проверок.
Оставаться в Notion стоит, когда текущая база и права уже проходят приёмку, а выгоды смены не покрывают объём ручной проверки. Перенос рассматривают, когда согласованный перенос через Notion API проходит тот же договор и есть подтверждённые условия использования платформы командой.
Выбор по неподтверждённым признакам — стране оператора, рублёвому ценнику, обещанию автоматического переноса прав — не даёт устойчивого результата. Эти параметры в сравнительные факты не входят. Задача ограничена базой знаний и приёмкой миграции: три страницы, две роли, PDF, три записи Tasks.
Как читать ход проверки и действовать при расхождении
Разбор удобно вести от ожидания к факту. Для каждой строки заранее записывают, что должно быть видно, и что именно будет считаться отклонением. Тогда спор идёт о наблюдаемом состоянии.
Возьмём условный пример. Марина открывает базу Tasks и видит три записи, но у T02 в свойстве Status стоит «Готово». Ожидание по учебному набору — «В работе». Это расхождение данных. Действие читателя: не трогать вид, вернуться к записи T02, сверить её поля по ID, названию, Status, Owner и Due, исправить значение и только затем пересобрать группировку. Если после правки карточка встала в нужную колонку, приёмка по этому пункту пройдена.
Второй условный случай касается доступа. Павел открывает «Публикация статьи», читает текст, открывает PDF и видит CHECK-PDF-05. Затем он пробует изменить текст и получает отказ. Дальше он открывает прямую ссылку на «Регламенты» и получает отказ в чтении. Здесь важно, что проверка идёт по прямой ссылке: она показывает фактическую выдачу прав, тогда как поиск по названию отражает лишь видимость объекта в метаданных. Если закрытая страница не находится поиском, это ещё не подтверждает корректность доступа.
Третий случай — потеря поля при переносе. Допустим, после импорта у T03 пропало свойство Due. Действие читателя: восстановить дату вручную, отметить затраченное время и внести строку в отчёт приёмки. Такая запись нужна, чтобы ручная работа не осталась незамеченной при итоговом решении.
Возможная ошибка при проверке — судить о результате по одному признаку. Пустая доска, отсутствие названия в поиске или один отказ в правке сами по себе не описывают состояние базы. Каждый такой сигнал ведёт к следующему шагу: проверить объект базы, затем свойства, затем записи, и лишь потом представление. Такой порядок сохраняет причинно-следственную связь между наблюдением и выводом.
Полезно заранее зафиксировать, что считается пройденной приёмкой. Для учебного набора это: три страницы с ожидаемым состоянием доступа, читаемый PDF со строкой CHECK-PDF-05, три записи Tasks с полным набором полей и настроенный вид с группировкой по Status. Если какой-то пункт не выполняется, читатель возвращается к предыдущему шагу.
Отдельно стоит проговорить, как поступать с заявлениями вендора. Собственный материал Buildin описывает импорт через Notion API, и это утверждение относится к заявленному маршруту. В приёмке оно превращается в проверяемую гипотезу: тот же договор, те же три страницы, те же роли, тот же PDF и те же записи. Пока гипотеза не пройдена, она остаётся ожиданием.
Итоговое действие читателя простое. Пройти набор по порядку, зафиксировать каждое расхождение с указанием шага, на котором оно обнаружено, и принять решение по совокупности пройденных пунктов. Такой разбор даёт воспроизводимую картину и позволяет повторить проверку на второй платформе без изменения условий.
Частые вопросы
Notion или Buildin — что выбрать для базы знаний команды?
Выбор делают по результату приёмки учебного набора: три страницы, две роли, PDF и три записи Tasks. Если текущая база и права уже проходят проверку, остаются в Notion. Перенос рассматривают, когда согласованный перенос через Notion API проходит тот же договор.
Как проверить, что база перенеслась целиком?
Сначала подтверждают объект базы, затем свойства, затем три записи по ID, названию, Status, Owner и Due. Только после этого настраивают вид «По статусу» с группировкой по Status. Пустая доска не доказывает потерю базы, а отсутствие объекта или свойств требует отдельной диагностики.
Переносятся ли права доступа автоматически?
Права настраивают заново в принимающем сервисе. В справке Notion описано наследование прав подстраницами и приоритет наиболее широкого доступа. Проверка под читателем включает попытку правки разрешённой страницы и открытие прямых ссылок на закрытые страницы и Tasks.
Как убедиться, что PDF прикреплён корректно?
Файл проверяют отдельно от совпадения дерева страниц. Читатель открывает publication-demo.pdf и видит строку CHECK-PDF-05. Замена файла картинкой или пустой ссылкой приёмку не проходит.
Что делать, если после импорта поле потерялось?
Поле восстанавливают вручную и отдельно отмечают затраты времени. В справке Notion указано, что CSV-импорт создаёт строки и свойства, а новые relations и formulas автоматически не появляются. Потерю фиксируют в отчёте приёмки, чтобы она не всплыла позже.