Retool → PostgreSQL → Power BI: как редактировать данные для отчётов

Обновлено 2 сентября 2026 года.

Retool подходит для внутренних форм, PostgreSQL — для данных приложения и аналитических витрин, Power BI — для отчётности. При объединении этих инструментов главный вопрос — кто владеет каждым полем. Если загрузчик копирует сделки из CRM, ручная правка суммы в его таблице может исчезнуть при следующей синхронизации.

Выберите, где сохранять изменение

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

Если поле существует только для аналитики — например, внутренний комментарий к плану или согласованная классификация — храните его отдельно. Практичная схема: raw.deals_current для состояния источника и app.deal_annotations для дополнений Retool. Витрина соединяет их по ключу портала и сделки.

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

Контракт таблицы редактирования

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

Учебный SQL ниже предполагает таблицу app.deal_annotations с колонками portal_id, deal_id, analyst_note, version и updated_at. Это запрос с позиционными параметрами для серверного обработчика, а не готовая вставка в редактор Retool:

UPDATE app.deal_annotations
SET analyst_note = $1,
    version = version + 1,
    updated_at = now()
WHERE portal_id = $2
  AND deal_id = $3
  AND version = $4
RETURNING version;

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

Читай также: BI Data Tools: инструменты аналитика и ограничения генераторов

Настройки запросов Retool

Retool поддерживает prepared statements: значения из компонентов передаются параметрами. Следуйте синтаксису конкретного ресурса, а не собирайте SQL строковой конкатенацией из пользовательского ввода. Динамические имена таблиц не являются обычными параметрами значений.

Разделите ресурсы чтения и записи и ограничьте права роли базы нужными таблицами или функциями. Скрытая кнопка в интерфейсе не заменяет проверку разрешений на сервере. Общая SQL-учётная запись сама по себе не сообщает PostgreSQL, какой сотрудник открыл приложение.

Адрес базы должен быть доступен именно из окружения Retool. Имя сервиса postgres из локального Docker Compose не становится публичным адресом для облачного приложения. Настройте предусмотренное вашей инфраструктурой защищённое соединение.

Витрина Power BI

Дайте Power BI доступ к представлению, которое явно объединяет данные источника и дополнения. Уберите произвольный LIMIT из общей витрины: иначе отчёт будет молча игнорировать часть сделок. Итоговую сортировку определяйте в запросе или визуализации.

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

В режиме Import сохранение формы не обновляет уже опубликованную модель мгновенно. DirectQuery также не гарантирует немедленную перерисовку открытого отчёта. Проверьте полный путь изменения: Retool → база → витрина → модель → экран пользователя, и покажите время актуальности данных.

Проверка перед выдачей доступа

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