Данные приложений и базы данных

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

На этой странице рассказывается, что это за хранилище, где оно находится и как приложение читает и записывает в него данные.

Что такое данные приложения

Когда агент создаёт приложение на основе данных, он может создавать настоящие таблицы — те самые структурированные строки и столбцы, которые вы представляете себе в электронной таблице или базе данных. У таблицы «лиды» могут быть столбцы для имени, компании и статуса; каждый лид — это одна строка.

В отличие от разового файла, эти таблицы сохраняются. Закройте рабочее пространство, вернитесь завтра, запустите приложение снова — строки всё ещё на месте. Именно это позволяет дашборду показывать «12 открытых задач» сегодня и «9 открытых задач» на следующей неделе, а не начинать каждый раз с нуля.

Вы не создаёте эти таблицы сами. Вы просите агента — «сделай мне простую CRM для отслеживания лидов» — и он настраивает таблицы и приложение вокруг них. Это встроено в каждое рабочее пространство; ничего не нужно устанавливать или включать.

Нужен готовый пример? Создание CRM для воронки продаж — полный готовый рецепт: таблица deals плюс канбан-доска с перетаскиванием, которая сохраняет каждое перемещение. Любое рабочее пространство может его попросить.

Ваши данные остаются в вашем рабочем пространстве

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

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

Показ данных другого рабочего пространства (если вы состоите в обоих)

Если вы состоите более чем в одном рабочем пространстве, дашборд можно построить так, чтобы он намеренно обращался к другому — например, домашнее рабочее пространство показывает сводку лидов из рабочего пространства клиента, к которому у вас тоже есть доступ. Вместо fetch('apps/leads') дашборд обращается к fetch('apps/~<workspaceId>/leads'), указывая другое рабочее пространство по id. Дашборд может узнать id рабочих пространств, в которых вы состоите, через fetch('me/workspaces'). Для чтения всё равно нужно быть участником того пространства; для записи там нужен доступ выше, чем «только чтение». Это происходит только тогда, когда дашборд специально создан запрашивать это по id — само по себе ничего между рабочими пространствами не переходит.

Как приложение читает и записывает свои данные

Под капотом приложение работает со своими таблицами через небольшой набор простых операций:

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

Например, приложение-трекер лидов может:

1. Insert — добавить строку, когда вы добавляете нового лида.
2. Query — запросить таблицу «лиды», чтобы показать их все на дашборде.
3. Update — изменить статус лида с «новый» на «связались».
4. Delete — удалить лида, который оказался дубликатом.

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

Получить ответы от человека: таблица, а не файл

Книга Excel — это результат. Plank показывает .xlsx и .csv как сетку только для чтения: можно выделить ячейку и переключить лист, и всё. Ввести туда нечего и сохранить нечем.

Поэтому файл не может быть способом собрать ответы. Ход, который кажется очевидным — выгрузить таблицу с пустым столбцом «Решение», отдать её и попросить заполнить — молча выбрасывает работу человека: набранное не сохраняется, и агент читает обратно тот же пустой столбец. Замерено 10.09.2026: бухгалтер потратил час на 125 строк, и файл вернулся с 0 заполненными решениями из 125.

Когда ответы нужны построчно, положите строки туда, куда можно писать:

1. Импортируйте их в таблицу — plank_app_preview_rows_file по книге, затем plank_app_import_rows по файлу строк, который она назовёт. (Возможно, вы это уже сделали: тот же первый шаг и сообщает вам состав столбцов.)
2. Добавьте столбцы для ответа в таблицу, а не в лист: решение, комментарий.
3. Дайте поверхность, которая пишет. Дашборд поверх таблицы — или форму, если человек не авторизован в Plank. И то и другое сохраняет прямо в строки.
4. Читайте ответы из таблицы, а не из файла.

Если строк единицы — просто спросите в чате: он тоже доступен для записи и дешевле, чем страница.

Выгрузить лист потом, чтобы человек сохранил его или переслал, — нормально и полезно. Правило только про направление: книга выносит ответы наружу, но никогда не принимает их внутрь.

Как это связано с HTML-дашбордами

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

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

Многостраничные дашборды

Дашборд не обязан быть одной страницей. Распространённый вариант — обзор, который перечисляет записи, и страница деталей для одной записи: кликаете на клиента в списке, попадаете на страницу этого клиента, кликаете «назад», чтобы вернуться.

Чтобы построить это, ассистент хранит каждую страницу как отдельный HTML-файл в той же папке и связывает их обычными ссылками — например, строка ссылается на client-detail.html?id=.... Plank выполняет переход на месте: страница деталей открывается внутри того же представления, как будто это одно приложение, с кнопкой «назад» для возврата к списку. Закрытие и повторное открытие файла снова начинает с первой страницы.

Под капотом каждая страница читает строку запроса через plank.params (например, plank.params.id) и загружает нужную строку данных через fetch('apps/<table>/' + plank.params.id). Вызовите plank.back(), чтобы добавить ссылку «назад» на предыдущую страницу. Держите все страницы одного приложения в одной папке (v1).

Вы ничего из этого не настраиваете сами — вы просите об этом («дай мне кликать на клиента, чтобы видеть его детали»), и ассистент связывает страницы вместе.

Хранение списка или объекта внутри строки (JSON)

Большинство столбцов хранят одно значение — имя, число, дату. Иногда запись естественно несёт небольшое структурированное значение: журнал активности сделки («позвонили 3-го», «написали 5-го»), набор тегов или произвольные атрибуты, каждому из которых не нужен отдельный столбец. Plank поддерживает столбец типа JSON именно для этого — один столбец, хранящий список или вложенный объект, который сохраняется и читается в том же виде (приложение может сохранить ["позвонили", "написали"] и прочитать тот же массив обратно).

Когда это уместно:

• Журнал активности или таймлайн, хранящийся прямо рядом с записью, к которой он относится, — «покажи недавние касания по этой сделке».
• Теги или метки — короткий список, который путешествует вместе со строкой.
• Гибкие или разрежённые атрибуты, которые отличаются от строки к строке и которые вы читаете только целиком.

Когда не стоит — лучше отдельная таблица:

• Вам нужно фильтровать, сортировать или суммировать по этим значениям («сделки с более чем 3 активностями», «сумма всех позиций»). Значение JSON хранится единым куском; база данных не может эффективно заглянуть внутрь него. Дайте каждому элементу собственную строку в связанной таблице.
• Список — это на самом деле собственный вид записей со своей жизнью (позиции, контакты, задачи), которые вы будете добавлять, редактировать и удалять по отдельности. Это связь один-ко-многим: дочерняя таблица, связанная с родительской, а не JSON-значение.

Правило: читаете целиком → столбец JSON подойдёт; нужно запрашивать по частям → отдельная таблица. Вы не выбираете тип столбца сами — попросите агента («веди журнал активности по каждой сделке»), и он подберёт правильную форму.

Когда стоит просить данные приложения

Выбирайте приложение на основе данных, когда работа состоит в том, чтобы отслеживать что-то со временем, а не выдать единственный готовый файл:

• Трекер или простая CRM (лиды, сделки, тикеты, кандидаты).
• Дашборд, который должен отражать самые свежие цифры при каждом открытии.
• Всё, где иначе вам пришлось бы заново вставлять один и тот же список в чат, чтобы «напомнить» агенту.

Если вам просто нужен разовый документ, обычный файл подойдёт лучше. Смотрите Как Plank выдаёт готовые документы, чтобы узнать, как выглядят эти документы и как изменить формат. Если же вам нужно что-то, что запоминает, попросите приложение.