I traced how website form submissions historically reached Litify and what the current routing evidence shows for Alert Communications.
Sources checked: Outlook, current saved form config, prior Gravity Forms/Litify handoff documents, the current form-fire QA report, and live Litify through LITIFY_ORG.
What was confirmed:
18 and form 19, posting to the Litify Salesforce Site intake endpoint.legacy_gf payload mode and still posts to the same Litify intake endpoint.sam@kylawoffice.com; I did not find current config evidence that Alert Communications is a direct real-time recipient of website form emails.WEB CONTACT FORMS source bucket, and per-lead Alert handoffs include Alert/LawRuler lead numbers.Web_Form__c is the website/chat/call lead capture object and links to litify_pm__Intake__c; litify_pm__Intake__c.Call_Center_Call_ID__c is populated on 13,819 records.Web_Form__c all-time platform counts: Intaker Web Chat 1,192; Website Contact Form 644; CallRail Call 460; Facebook Lead Form 28; Unbounce Landing Page Form 1.Created a PII-safe local report:
/Users/samaguiar/Repos/litisail-vault/reports/alert-communications-web-form-routing-2026-05-13.md
The trace reached a useful answer and I documented it. I did not make live website, Outlook, or Litify changes because the next step could notify an outsourced vendor and should be treated as approval-gated.
The cleanest reversible implementation is to keep the custom relay and add a separate Alert delivery target rather than rebuilding Gravity Forms. Suggested shape: add alert_recipients or call_center_recipients, send a separate call-center email with core form fields and the Litify record link, log Alert delivery separately, then QA first with a no-send/honeypot path and only run a real vendor-notifying test after approval.
A stronger option would be to ask Alert for a LawRuler/API/webhook endpoint and add that as the primary call-center delivery lane, with email as fallback.
Start with the local report above. Key historical files are: