Zaobserwowana awaria
CRM zwraca HTTP 400, a rekord leada nie powstaje.
To przejrzyste demo z fikcyjnymi danymi, a nie case study klienta. Pokazuje dowody, których wymagam przed uznaniem workflow za naprawiony.
Sprawdź dowodyBrak company_name. CRM odrzucił żądanie.
Widoczna odpowiedź 400 jest objawem. Naprawa musi poprawić kontrakt danych i udowodnić, że ścieżki błędów pozostają kontrolowane.
CRM zwraca HTTP 400, a rekord leada nie powstaje.
Formularz wysyła company, ale kontrakt CRM wymaga company_name.
Normalizacja payloadu, walidacja pól i kontrolowana obsługa ponowień.
{
"email": "lead@example.com",
"company": "Example Studio"
}{
"email": "lead@example.com",
"company_name": "Example Studio",
"source": "website"
}| Przypadek | Oczekiwany rezultat | Status |
|---|---|---|
| Kompletny lead | Jeden rekord CRM i jedno powiadomienie | OK |
| Brak firmy | Bezpieczna wartość lub jawna ścieżka walidacji | OK |
| Timeout CRM / 429 | Ograniczone ponowienia, potem alert administratora | OK |
| Powtórzony webhook | Brak zduplikowanego rekordu CRM | OK |
Prawdziwy projekt korzysta z zanonimizowanych logów i uzgodnionych danych testowych. Dostęp jest potrzebny dopiero po potwierdzeniu zakresu i płatności.
Wyślij błąd, oczekiwany rezultat i zanonimizowany zrzut wykonania. Powiem, czy zadanie pasuje do Workflow Rescue, czy najpierw wymaga diagnozy.