Gravity Flow Form Connector - Плагин WordPress

Руководство по настройке и применению Gravity Flow Form Connector

Gravity Flow Form Connector нужен не для обычной контактной формы, а для тех случаев, когда данные должны двигаться между несколькими Gravity Forms и несколькими этапами Gravity Flow. В этом руководстве разберём, как понять роль расширения, подготовить формы, добавить шаги связывания, настроить сопоставление полей, проверить результат и быстро найти причину, если рабочий сценарий не продолжился.

Материал рассчитан на администратора WordPress, разработчика или владельца сайта, у которого уже есть Gravity Forms и Gravity Flow. Мы не будем пересказывать карточку продукта и не будем разбирать покупку или активацию лицензии. Вместо этого пройдём путь от схемы процесса до тестовой заявки, где одна форма создаёт запись в другой форме, а затем возвращает результат обратно.

Главная мысль: Form Connector полезен там, где одна большая форма становится слишком тяжёлой, где разные сотрудники должны работать в своих формах, где часть данных нужно переносить без ручного копирования, а итоговый статус должен оставаться понятным в основной заявке.

Какую задачу решает Form Connector в связке Gravity Forms и Gravity Flow

Обычная форма WordPress собирает запись и, в лучшем случае, отправляет уведомление или запускает интеграцию. Gravity Flow добавляет к записи маршрут: назначение ответственных, утверждение, пользовательский ввод, уведомления, статус, страницу задач и историю действий. Gravity Flow Form Connector расширяет эту модель ещё дальше: один шаг рабочего процесса может создать запись в другой форме, обновить существующую запись, получить значения из другой записи, удалить запись или дождаться отправки другой формы.

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

Лучший сценарий для расширения - процесс, где запись должна переходить между ролями и формами, а не просто отправлять письмо. Если вам нужно только передать несколько скрытых полей на следующую форму, иногда достаточно динамического заполнения Gravity Forms или более лёгкого дополнения. Если же каждая связанная форма должна иметь собственный рабочий процесс, назначенных исполнителей и историю, Form Connector становится намного уместнее.

Что происходит на уровне логики

Удобно мыслить так: Form A создаёт или содержит исходную запись, Gravity Flow ведёт её по шагам, а Form Connector на нужном шаге обращается к Form B или другой записи. В зависимости от выбранного типа шага расширение либо создаёт новую запись, либо ищет уже существующую, либо ждёт, пока назначенный пользователь отправит целевую форму через специальную ссылку.

Критически важно не путать Form Connector с внешним интегратором. Он работает внутри экосистемы Gravity Forms и Gravity Flow, а при удалённом сценарии ожидает наличие нужной связки на другом WordPress-сайте. Это не универсальная замена вебхукам, CRM-интеграциям или внешней шине данных, хотя в сложной схеме может использоваться рядом с ними.

Почему лучше разделять большую форму на несколько этапов

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

Такой подход также помогает разграничить доступ. Клиенту не нужно видеть поля для сотрудника, подрядчику не нужно открывать всю исходную заявку, а менеджер получает только тот набор данных, который нужен для его решения. В Gravity Flow это особенно ценно, потому что задачи и уведомления привязаны к шагам, а Form Connector добавляет между шагами мосты данных.

Кому подходит расширение, а кому лучше выбрать другой путь

Gravity Flow Form Connector чаще всего нужен сайтам, где формы уже стали частью внутреннего процесса. Это могут быть агентства, сервисные компании, образовательные проекты, медицинские или юридические приёмные, HR-процессы, техподдержка, внутренние заявки, многоэтапные согласования и проекты, где несколько отделов работают с разными частями одной заявки.

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

Когда продукт будет удачным выбором

• Нужно создавать связанные записи в других формах и запускать по ним отдельные рабочие процессы.
• Нужно обновлять основную запись после того, как другая форма собрала дополнительные данные.
• Нужно дождаться, пока назначенный пользователь отправит отдельную форму через защищённую ссылку.
• Нужно синхронизировать значения между несколькими Gravity Forms без большого объёма собственного кода.
• Нужно работать с удалённым WordPress-сайтом, где также установлены Gravity Forms, Gravity Flow и Form Connector.

Когда расширение может быть лишним

Если у вас одна простая форма, один получатель уведомления и нет маршрута по шагам, Form Connector будет избыточен. Он также не лучший выбор, если вся логика должна уходить во внешнюю CRM, таблицу, мессенджер или систему задач без внутреннего workflow в WordPress. В этом случае чаще смотрят на вебхуки, CRM-интеграции или автоматизаторы.

Расширение требует дисциплины в проектировании. Нужно заранее понимать, где хранится исходный Entry ID, какие поля сопоставляются, кто назначен на шаг, какая страница содержит целевую форму и как вы будете тестировать результат. Без этой схемы Form Connector легко превратить в набор шагов, который вроде бы настроен, но непонятно, почему обновляет не ту запись или не двигает процесс дальше.

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

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

Техническая база

• На сайте должны быть установлены и работоспособны WordPress, Gravity Forms и Gravity Flow.
• Формы, которые участвуют в процессе, должны быть опубликованы или доступны в том месте, где их будет открывать назначенный пользователь.
• Для страниц с динамическими значениями, защищёнными ссылками и формами лучше заранее понять правила кеширования.
• У администратора должны быть права на редактирование форм, рабочих процессов, уведомлений и страниц WordPress.
• Если используется удалённый сайт, на нём также должна быть нужная связка и корректная настройка доступа к Gravity Forms API.

Процессная карта перед настройкой

Составьте маленькую таблицу вне сайта. В строках укажите формы, а в столбцах - назначение, ключевые поля, кто отправляет форму, какой Entry ID нужно хранить, какие шаги создают или обновляют другую запись. Эта предварительная карта экономит больше времени, чем попытка угадать всё прямо в админ-панели.

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

Установка в WordPress и первичная проверка после активации

Установка Form Connector технически похожа на установку обычного WordPress-плагина: загрузить ZIP-архив через Plugins - Add New - Upload Plugin, установить и активировать. Но в реальной работе важнее не сам факт активации, а проверка, что расширение появилось в контексте Gravity Flow и добавило нужные типы шагов.

После активации откройте одну из тестовых форм, перейдите в её настройки и найдите раздел Workflow. Создайте новый шаг и посмотрите список типов шага. В нём должны появиться варианты Form Connector: создание записи, обновление записи, обновление полей, удаление записи и ожидание отправки другой формы. Названия в интерфейсе могут немного отличаться, но смысл должен соответствовать документации.

Проверка на тестовой форме

1. Создайте Form A с несколькими простыми полями: имя, email, тип запроса, комментарий.
2. Создайте Form B с полями, которые должны получить часть значений из Form A.
3. Откройте настройки Form A и добавьте новый шаг в Workflow.
4. Выберите шаг, который создаёт новую запись в другой форме, и укажите Form B как целевую.
5. Сопоставьте 2-3 поля, сохраните шаг и отправьте тестовую запись через Form A.
6. Проверьте, появилась ли запись в Form B и видна ли она в списке Entries.

Если на этом этапе новый тип шага не появился, сначала проверьте активность Gravity Flow и Form Connector в списке плагинов. Затем убедитесь, что вы находитесь именно в настройках формы, а не в общих настройках WordPress. Workflow Steps являются формо-зависимыми: шаги настраиваются для конкретной Gravity Form.

Что не стоит проверять в первый день

Не начинайте сразу с удалённого сайта, платёжного сценария, большого количества условной логики и нескольких вложенных форм. Сначала подтвердите базовую механику на одном сайте: Form A создала Form B, Form B обновила Form A, история шагов в Gravity Flow показывает ожидаемое движение. Сложность нужно добавлять только после того, как простая цепочка уже доказала, что данные идут по правильному маршруту.

Пять типов шагов Form Connector и где их применять

Главная сила Gravity Flow Form Connector - не в одном универсальном действии, а в наборе разных шагов. Каждый шаг отвечает на отдельный вопрос: создать новую запись, обновить существующую, забрать значения из другой записи, удалить запись или поставить процесс на паузу до отправки другой формы. Если выбрать шаг неправильно, настройка получится хрупкой.

Create An Entry: когда нужна новая связанная запись

Шаг создания новой записи полезен, когда исходная заявка должна породить отдельную работу. Например, клиент отправляет запрос на мероприятие, а система создаёт записи для флориста и кейтеринга. Каждая целевая запись может иметь свой workflow, своих исполнителей и свой срок. Исходная запись при этом остаётся главной точкой, из которой процесс стартовал.

В настройке важно сопоставить поля целевой формы с полями исходной записи. Если целевая форма должна потом вернуть данные назад, сохраните ID новой записи в поле исходной формы или используйте отдельное поле-связку. Это не всегда красиво видно пользователю, поэтому такие поля часто делают административными или скрытыми.

Update An Entry: когда нужно вернуть результат в основную запись

Шаг обновления записи нужен, когда целевая форма или связанный процесс уже создал данные, которые должны попасть обратно в другую запись. Например, подрядчик отправил стоимость услуги, а основная заявка должна получить поле Vendor Quote и перейти к проверке менеджером.

Здесь самый важный параметр - поле с Entry ID целевой записи. Документация прямо указывает, что это поле используется для поиска записи, которую нужно обновить. Если поле пустое или содержит не тот ID, шаг либо ничего не сделает, либо изменит не ту запись. Поэтому в тестах всегда проверяйте не только итоговое значение, но и то, какой Entry ID участвовал в шаге.

Update Fields: когда текущая запись должна подтянуть значения из другой записи

Update Fields работает в обратном направлении: текущая запись получает значения из другой записи или из пользовательских значений. Это удобно, когда запись должна узнать актуального дежурного менеджера, подтянуть статус из основной заявки или обновить часть полей перед дальнейшим маршрутом.

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

Delete An Entry: когда данные нужно убрать по правилам процесса

Шаг удаления можно использовать для очистки временных или лишних записей, когда они больше не нужны. Документация описывает возможность удалить запись сразу или запланировать удаление. Это мощное действие, поэтому его нельзя ставить в рабочий процесс без тестовой копии и без ясного правила хранения данных.

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

Form Submission: когда процесс должен дождаться другой формы

Form Submission - один из самых полезных и одновременно самых требовательных шагов. Он ставит workflow на паузу, пока назначенный пользователь не отправит указанную форму. Пользователь должен открыть форму по ссылке из страницы детали workflow или по merge tag {workflow_form_submission_link} в письме. Эта ссылка содержит защитный токен, поэтому обычная отправка целевой формы без специальной ссылки не считается выполнением шага.

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

Подробная настройка после установки: от формы до сопоставления полей

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

Выбор сайта и целевой формы

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

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

Сопоставление полей

Field Mapping определяет, какие значения из одной записи попадут в другую форму или запись. Для простых полей это обычно очевидно: имя в имя, email в email, номер заявки в скрытое поле. Для составных полей, файлов, списков и полей с условной логикой нужна отдельная проверка. Документация Form Submission отдельно указывает ограничение по file upload fields, поэтому не планируйте перенос файлов через этот шаг без проверки конкретного сценария.

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

Что выбирать как источник значения

• Поле исходной формы, если значение ввёл пользователь или сотрудник.
• Custom Value, если нужно передать фиксированный статус или текстовую метку.
• Merge tag, если значение должно собираться из нескольких полей или системных данных Gravity Forms.
• Скрытое или административное поле, если значение нужно системе, но не должно редактироваться обычным пользователем.

Как проверить сопоставление без гадания

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

Entry ID как связующий ключ

Для обновления существующей записи нужен ID записи. Его можно хранить в скрытом поле, получать из URL, передавать через сопоставление или определять через фильтр, если у вас сложная логика поиска. В большинстве проектов лучше начать с простого скрытого поля. Оно прозрачно: видно, какой ID пришёл, его можно сравнить с записью, а ошибку легко повторить.

Когда связь строится не по Entry ID, а по поиску через поле, например по номеру заявки, email или внутреннему коду, повышается риск неоднозначности. Две записи могут совпасть по email, один номер может быть введён с пробелом, а старые записи могут остаться активными. Поэтому для рабочих процессов с юридически важными или финансовыми данными лучше хранить точный Entry ID.

Назначение исполнителей и письма

Для шагов, где человек должен что-то сделать, настройка assignee важнее внешнего вида формы. Пользователь должен получить задачу, открыть правильную ссылку и выполнить действие в тот момент, когда workflow находится на соответствующем шаге. Для Form Submission обязательно добавьте ссылку {workflow_form_submission_link} в письмо исполнителю или убедитесь, что он открывает форму со страницы детали workflow.

Если вы назначаете шаг на email-поле, помните, что такой пользователь может не иметь доступа к админ-панели. Значит, интерфейс выполнения должен быть доступен через публичную страницу workflow или специальную ссылку, а сама страница не должна отдавать устаревший кешированный HTML.

Условная логика, расписание и следующий шаг

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

Расписание пригодится, когда шаг должен стартовать позже: например, запросить уточнение через несколько дней или удалить временную запись после завершения процесса. Учитывайте, что плановые действия WordPress зависят от фоновой обработки и посещаемости сайта, поэтому не проектируйте критичный процесс как действие, которое обязано сработать в точную секунду.

Form Submission, защищённые ссылки и кеш: место, где чаще всего ошибаются

Form Submission отличается от обычной отправки формы тем, что workflow ждёт конкретную отправку через конкретную ссылку. Документация подчёркивает: если пользователь отправит целевую форму без токена в URL, шаг не распознает эту отправку как выполнение. Это сделано для защиты сопоставлений и исходного Entry ID от подмены.

Как должен выглядеть правильный путь

1. Workflow доходит до шага Form Submission.
2. Назначенный пользователь получает письмо или открывает страницу детали workflow.
3. Пользователь переходит по ссылке, созданной через {workflow_form_submission_link} или через интерфейс workflow.
4. Открывается страница с целевой формой, в URL присутствует защищённый параметр.
5. Поля заполняются значениями из исходной записи согласно Field Mapping.
6. После отправки целевой формы шаг завершается, и workflow переходит дальше.

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

Почему кеш ломает такие сценарии

Кеш может отдать старую страницу, скрыть параметры запроса, сохранить форму в состоянии, которое не соответствует текущему токену, или помешать динамическому заполнению. Gravity Forms отдельно предупреждает, что динамическое заполнение использует PHP и не работает корректно на кешированной странице. Документация Form Submission также указывает, что предупреждение о недействительной ссылке может решаться исключением submission page из кеша.

Для страниц, где открывается целевая форма Form Submission, безопасный минимум - исключить страницу из полного кеша и проверить query string. Если сайт использует агрессивный кеш хостинга, CDN или оптимизатор, проверьте не только плагин кеширования WordPress, но и настройки на уровне сервера.

Что писать пользователю в письме

В письме исполнителю не стоит давать две разные ссылки: одну обычную на страницу формы и одну workflow-ссылку. Это провоцирует ошибку. Лучше сделать один понятный призыв: открыть форму по защищённой ссылке, заполнить её, после отправки дождаться подтверждения. Если письмо идёт внешнему человеку, добавьте короткое объяснение, что ссылка действительна только для текущего этапа процесса.

Практический пример: заявка клиента, предложения подрядчиков и обновление основной записи

Разберём пример, близкий к демонстрационному сценарию Gravity Flow: клиент отправляет заявку на услугу, менеджер запускает отдельные процессы для подрядчиков, подрядчики дают предложения, а основная запись получает итоговые значения для финального согласования. Такой пример хорошо показывает, как Form Connector отличается от простой передачи данных между двумя формами.

Цель

Нужно получить процесс, где Form A хранит основную заявку клиента, Form B собирает предложение подрядчика, а после утверждения предложение возвращается в Form A. Клиент не видит внутренние поля подрядчика, подрядчик не видит всю исходную заявку, менеджер контролирует итог в основной записи.

Подготовка

• Form A: Client Request с полями имени, email, типа услуги, бюджета, комментария и скрытым полем для ID связанной записи.
• Form B: Vendor Quote с полями имени клиента, типа услуги, комментария для подрядчика, суммы предложения и скрытым полем Original Entry ID.
• В Form A включён workflow с шагом проверки менеджером и шагом Create An Entry для Form B.
• В Form B включён workflow с шагом User Input или Approval, а затем Update An Entry для Form A.

Шаги настройки

1. В Form A добавьте шаг Create An Entry после первичной проверки менеджером.
2. Выберите Form B как целевую форму и сопоставьте имя клиента, тип услуги и комментарий.
3. Передайте ID исходной записи Form A в скрытое поле Original Entry ID в Form B.
4. В Form B добавьте шаг для подрядчика, чтобы он указал сумму и комментарий.
5. После шага подрядчика добавьте Update An Entry, выберите Form A как целевую форму.
6. В качестве Entry ID используйте скрытое поле Original Entry ID.
7. Сопоставьте сумму и комментарий подрядчика с административными полями Form A.
8. Добавьте следующий шаг в Form A: уведомление менеджеру или финальное согласование с клиентом.

Проверка результата

Отправьте тестовую заявку через Form A. После обработки шага Create An Entry откройте список записей Form B и убедитесь, что новая запись создана. Затем завершите шаг подрядчика в Form B и проверьте Form A: поля предложения должны обновиться, а timeline должен показать прохождение соответствующих шагов.

Если Form B создалась, но Form A не обновилась, почти всегда стоит начать с поля Original Entry ID. Проверьте, что в Form B лежит ID именно исходной записи Form A, а не ID самой записи Form B.

Нюанс с несколькими подрядчиками

Если один клиентский запрос должен создать несколько подрядных заявок, лучше заранее решить, как вы будете хранить несколько связанных ID и как возвращать результаты. Одна строка с одним Entry ID уже не подходит. Можно создать отдельные поля для каждого типа подрядчика, использовать отдельные дочерние процессы или подключать дополнительные инструменты для группировки связанных записей. Не пытайтесь решать это случайным текстовым полем без схемы.

Практичные идеи применения на разных типах сайтов

Form Connector особенно полезен там, где один пользовательский запрос распадается на несколько внутренних задач. Ниже не список «где угодно», а сценарии, которые опираются на подтверждённые возможности расширения: создание записей, обновление записей, ожидание другой формы, сопоставление полей и работа нескольких workflow.

Сервисная компания и подрядчики

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

HR-процесс с несколькими отделами

Кандидат заполняет первичную форму. После отбора Form Connector создаёт отдельные записи для службы безопасности, руководителя отдела и HR. Каждый отдел работает в своей форме, а основная запись получает статусы. Такой сценарий помогает не показывать всем участникам всю анкету кандидата и не смешивать служебные комментарии с публичными полями.

Поддержка клиентов и уточняющие формы

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

Процессы с временными или служебными записями

Иногда связанная запись нужна только на время согласования. Delete An Entry может использоваться как часть политики очистки, но только после тестирования и с ясным пониманием, когда данные уже не нужны. Для процессов с персональными данными это может быть полезно, но решение должно согласовываться с вашими внутренними правилами хранения.

Проверка результата: как понять, что связка работает правильно

Проверка Form Connector не должна ограничиваться фразой «ошибок нет». Нужно доказать, что каждое действие произошло с правильной записью, правильными полями и в правильный момент workflow. Для этого удобнее использовать тестовый набор данных с узнаваемыми значениями: например, TEST-FC-001 в названии заявки и отдельные уникальные значения для каждого поля.

Мини-чек-лист после тестовой отправки

• В исходной форме появилась запись с тестовым идентификатором.
• Шаг Gravity Flow дошёл до нужного Form Connector Step и не был пропущен условной логикой.
• Целевая запись создана или обновлена именно в той форме, которая указана в настройке.
• Сопоставленные поля получили ожидаемые значения, а пустые значения объяснимы.
• Скрытое поле Entry ID содержит правильный ID связанной записи.
• Письмо исполнителю содержит workflow-ссылку, а не обычный URL формы.
• Timeline показывает движение процесса и следующий шаг соответствует схеме.

Как тестировать без риска для реальных данных

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

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

Безопасное расширение через фильтры, если стандартного Entry ID недостаточно

В большинстве проектов лучше использовать скрытое поле с Entry ID. Но иногда запись нужно искать по бизнес-ключу: номеру заявки, внутреннему коду, выбранному проекту. В документации Form Connector есть фильтр gravityflowformconnector_update_entry_id, который позволяет изменить целевой Entry ID для шага Update An Entry. Такой подход стоит применять только разработчику или администратору, который понимает Gravity Forms API и может протестировать поиск на копии процесса.

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

add_filter( 'gravityflowformconnector_update_entry_id', 'jf_find_target_entry_by_case_code', 10, 5 );

function jf_find_target_entry_by_case_code( $target_entry_id, $target_form_id, $entry, $form, $step ) {
    // Ограничьте код конкретной исходной формой.
    if ( (int) $form['id'] !== 12 ) {
        return $target_entry_id;
    }

    // Ограничьте код конкретным шагом Workflow.
    if ( ! $step || (int) $step->get_id() !== 34 ) {
        return $target_entry_id;
    }

    // Поле 5 в исходной форме хранит внутренний код заявки.
    $case_code = rgar( $entry, '5' );
    if ( empty( $case_code ) ) {
        return $target_entry_id;
    }

    $search_criteria = array(
        'status'        => 'active',
        'field_filters' => array(
            array(
                'key'   => '3',
                'value' => $case_code,
            ),
        ),
    );

    $paging  = array( 'offset' => 0, 'page_size' => 1 );
    $entries = GFAPI::get_entries( $target_form_id, $search_criteria, null, $paging );

    if ( ! empty( $entries ) && ! empty( $entries[0]['id'] ) ) {
        return (int) $entries[0]['id'];
    }

    return $target_entry_id;
}

Код лучше размещать через Code Snippets, собственный маленький плагин или дочернюю тему. После установки отправьте тестовую запись с уникальным кодом, проверьте, какую запись нашёл фильтр, и только потом включайте сценарий для реальных пользователей. Откат простой: отключить snippet и вернуться к стандартному Entry ID из настроек шага.

Если вам приходится писать много таких фильтров, это сигнал пересмотреть структуру процесса. Возможно, Entry ID нужно сохранять явно, а не искать запись каждый раз по косвенным полям.

Частые проблемы и диагностика Form Connector

Ошибки в Form Connector обычно выглядят как «ничего не произошло», хотя на самом деле одно из условий не выполнено: пользователь открыл не ту ссылку, кеш отдал старую страницу, Entry ID пустой, шаг пропущен условной логикой или целевая форма выбрана неверно. Диагностику лучше вести от симптома к причине, а не менять все настройки подряд.

Form Submission не двигает workflow дальше

Симптом: целевая форма отправлена, запись в Gravity Forms появилась, но исходный workflow остался на шаге Form Submission.

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

Исправление: обновите письмо исполнителю, уберите обычную ссылку на форму, оставьте только workflow-ссылку. Затем создайте новую тестовую запись и повторите путь. Если ошибка повторяется, проверьте кеш страницы формы и исключите её из полного кеширования.

Поля в целевой записи пустые

Симптом: запись создана, но часть значений не перенеслась.

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

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

Обновилась не та запись

Симптом: Update An Entry прошёл, но данные появились в другой записи или не там, где ожидалось.

Проверьте поле Entry ID. В тестовой записи откройте значение скрытого поля, сравните его с ID целевой записи в списке Entries. Если ID хранится как текст, убедитесь, что в нём нет пробелов, лишних символов или значения из другой формы.

Исправление: вернитесь к схеме связей и временно выведите Entry ID в административном поле, чтобы видеть его в записи. Если ID вычисляется через фильтр, добавьте временное логирование или упростите поиск до одного уникального поля.

Ссылка сообщает, что форма больше недействительна

Симптом: пользователь открывает ссылку из письма и видит предупреждение о недействительности формы или ссылки.

Проверьте три вещи: workflow всё ещё находится на нужном шаге, ссылка открыта тем assignee, для которого она была создана, и страница не кешируется. Если шаг уже завершён или пропущен, старая ссылка не обязана работать.

Исправление: создайте новую тестовую запись, отправьте новое письмо и проверьте ссылку сразу. Если мгновенно повторяется ошибка, отключите кеш для submission page и проверьте, не режет ли CDN query string.

Шаг с удалением не сработал сразу

Симптом: Delete An Entry настроен, но запись не исчезла моментально.

Документация указывает, что удаление может выполняться после завершения workflow и требует времени. Также действие может быть запланировано. Проверьте, завершён ли процесс, не стоит ли задержка и не ожидает ли система фоновой обработки.

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

Письма не приходят назначенным пользователям

Симптом: workflow ждёт пользователя, но он не получает письмо со ссылкой.

Причина может быть не в Form Connector, а в настройках workflow email, SMTP, назначении assignee или почтовой доставке WordPress. Проверьте, включено ли письмо на этом шаге, правильный ли merge tag вставлен, кто назначен исполнителем и есть ли почтовый журнал.

Исправление: протестируйте уведомление на внутреннем пользователе, затем на email-поле. Для важных процессов используйте SMTP и журнал отправки. Если письмо не нужно, дайте исполнителю понятный доступ к странице Inbox или Workflow Detail.

Когда Gravity Flow Form Connector будет удачным выбором

Gravity Flow Form Connector стоит использовать, если ваш сайт уже работает на Gravity Forms и Gravity Flow, а процесс вырос за пределы одной формы. Он помогает разделить длинные сценарии на управляемые формы, передавать только нужные значения, ждать действий назначенных пользователей и возвращать итоговые данные в основную запись.

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

Когда схема уже понятна и вы готовы проверить её на своём сайте, можно перейти к скачиванию Gravity Flow Form Connector и протестировать расширение сначала на копии или тестовом наборе форм. Такой порядок безопаснее, чем сразу подключать многоформовый workflow к реальным заявкам.