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

Найдите точную запись и нужное поле

Откройте карточку по устойчивому внутреннему идентификатору или SKU. Похожие названия товаров — слабый ориентир для расследования. В расширенной записи выберите Revision history в ленте активности. Сопоставьте изменение с моментом появления неверной цены на витрине: задержка обмена может отделять правку в базе от публикации результата.

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

Отличите автора от механизма обновления

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

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

Учитывайте неполную видимость истории

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

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

Сохраните вывод до окончания срока хранения

Глубина истории зависит от плана, а просмотр доступен по одной записи. Airtable не предлагает обычный экспорт истории правок или Web API для её выгрузки. Поэтому не откладывайте фиксацию существенного инцидента до окончания срока хранения. Сохраните собственный разбор с датами, конкретными полями и подтверждённой причиной, избегая ненужных данных покупателей.

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