זיהוי כפילויות — מה קורה בשרת

“מה קורה אם אותו אדם ממלא את הטופס פעמיים?” — זו השאלה שהלקוח שואל בכל פרויקט, ובדרך כלל הוא מצפה לתשובה “המערכת תזהה ותמזג”. היא לא ממזגת. היא מזהה, מסמנת, ויוצרת שורה חדשה.

העמוד הזה מפרט בדיוק מה רץ בצד השרת, כדי שתוכלו לענות ללקוח לפני העלייה לאוויר ולא אחריה.

איך נראית הבדיקה

הבדיקה זהה בנקודות הקצה הקיימות (web2table ו‑web2case), ורצה אחרי בדיקת דגל ה‑Config ולפני יצירת הרשומה: דגל כבוי + טלפון קיים מחזיר … is Disabled, לא התאמה.

1 · נרמול הטלפון

השרת מסיר מהמספר כל תו שאינו ספרה, וממיר קידומת בינלאומית לצורה המקומית — 972… הופך ל‑0….

מה הגולש הקליד	הצורה המנורמלת
050-123-4567	0501234567
+972 50 1234567	0501234567
972501234567	0501234567

שלושת הפורמטים בטבלה, וגם "050 200 0001" עם רווחים, מאתרים את אותו איש קשר.

2 · סריקה של חמישה פורמטים שמורים

הנרמול לא מספיק, כי הנתונים במערכת עצמה שמורים בפורמטים מעורבים — ייבוא ישן, הקלדה ידנית, אינטגרציה שכתבה בפורמט בינלאומי. לכן השרת לא מחפש ערך אחד; הוא בונה מהמספר המנורמל שאילתה על חמישה פורמטים שמורים — בדיוק אלה, ולא אחרים:

Accounts.PhoneNumber ∈ {
  0501234567         ←  05XXXXXXXX
  972501234567       ←  9725XXXXXXX
  +972501234567      ←  +9725XXXXXXX
  050-1234567        ←  05X-XXXXXXX
  +972-50-1234567    ←  +972-5X-XXXXXXX
}

ובאותה צורה לקידומות של קווי נייח (02…, 03…, 04…, 08…, 09…): 039990001, 97239990001, +97239990001, 03-9990001 ו‑+972-3-9990001 כולם מאותרים מקלט 039990001. חמשת הפורמטים הסלולריים מאותרים גם מקלט מנורמל וגם מקלט זהה לפורמט השמור.

מגבלה ידועה — מספר שמור בפורמט אחר לעולם לא מאותר

הרשימה סגורה. איש קשר שה‑PhoneNumber שלו שמור כ‑050-123-4567, 050 1234567 או +972 50 1234567 — הפורמטים הנפוצים ביותר בהקלדה ידנית — לא יאותר בשום קלט, גם לא כשהטופס שולח את המחרוזת הזהה בדיוק (הקלט מנורמל לספרות לפני בניית השאילתה, והפורמט השמור אינו ברשימה). התוצאה היא איש קשר חדש בכל פנייה, בלי שום שגיאה.

לפני חיבור טופס למערכת קיימת: נרמלו את Accounts.PhoneNumber לאחד מחמשת הפורמטים (עדיף 05XXXXXXXX). שורות שנוצרות דרך הטפסים עצמן נשמרות כספרות בלבד (0501234567 או 972501234567, לפי מה שנשלח) ולכן תמיד מאותרות.

3 · OR מול האימייל

כל הווריאציות למעלה מחוברות ב‑OR להשוואת שוויון על Accounts.Email. כלומר: התאמה בטלפון או התאמה באימייל = כפילות. טלפון חדש לגמרי עם אימייל של איש קשר קיים מחזיר את ה‑accountId הקיים.

השוואת האימייל רגישה לאותיות גדולות/קטנות

השוויון על Email הוא השוואת מחרוזות מדויקת: איש קשר שמור עם Dana@Example.co.il מאותר רק מקלט זהה באותיות; dana@example.co.il יוצר איש קשר חדש. רווחים מסביב כן מנוקים. נרמלו אימיילים ל‑lowercase — גם בטופס וגם בטבלת Accounts — לפני שאתם סומכים על ההתאמה הזו.

JSON

// המבנה הלוגי של השאילתה (המחשה)
{ "$or": [
    { "PhoneNumber": "0501234567" },
    { "PhoneNumber": "+972501234567" },
    { "PhoneNumber": "050-1234567" },
    { "Email": "israel@example.co.il" }
] }

4 · ב‑web2table — שלושה מפתחות נוספים

web2table מרחיב את אותה בדיקה:

המפתח בבקשה	מול איזה שדה	הערה
phone	PhoneNumber	מפתח חובה
phone2	טלפון משני	מזין את החיפוש, אבל אינו נשמר — אין שדה טלפון משני בתבנית vanilla
email	Email
email2	אימייל משני	מזין את החיפוש, אבל אינו נשמר — אין שדה אימייל משני בתבנית vanilla
idnum	CompanyId	ח.פ. / ת.ז. — התאמה מדויקת, בלי נרמול

כל אחד מחמשת המפתחות, לבדו, מאתר איש קשר קיים. ב‑idnum אין נרמול — "123-456-780" לא מתאים ל‑"123456780", והמחרוזת נשמרת ב‑CompanyId כפי שנשלחה.

forks של לקוחות משנים את כללי ההתאמה

אצל חלק מהלקוחות פותחה גרסה ייעודית של הפונקציה עם כללי התאמה נוספים — למשל התאמה גם מול PhoneNumberHusband / PhoneNumberWife, או התאמת idnum מול שדה ID במקום CompanyId.

כשאתם תומכים בלקוח ספציפי — קראו את הקוד שנפרס אצלו, אל תניחו את החוזה הגנרי.

account_PhoneNumber לא מזין את הבדיקה

ב‑web2table, מפתחות האיתור הם בלי קידומת. מי ששולח account_PhoneNumber במקום phone מקבל איש קשר משוכפל בכל פנייה — כי הערך נכנס לשדה, אבל לא נכנס לשאילתה.

כפילות לא חוסמת יצירה

זו הנקודה שהכי חשוב להסביר ללקוח מראש.

ב‑getlead — תמיד נוצרת שורה חדשה

שליחה חוזרת של אותו טלפון ל‑getlead יוצרת שורת ליד שנייה שמסומנת בסטטוס “ליד כפול” (QYvLV9xHE1 בתבנית), בעוד הליד הראשון מקבל “ליד חדש” (e9TwcETDGq).

התוצאה	מה קורה
נמצאה התאמה	נוצרת שורת ליד חדשה, ומסומנת בסטטוס “ליד כפול”
לא נמצאה	נוצרת שורת ליד חדשה עם ה‑LeadStatusId שנשלח בבקשה, ואם לא נשלח — עם סטטוס “ליד חדש”

אין מיזוג ואין עדכון של הליד הקיים. הרציונל: שתי פניות הן שני אירועים עסקיים, גם אם מדובר באותו אדם — והשדה שמבדיל ביניהן הוא הסטטוס.

אל תקודדו את מזהי הסטטוס בלי לאמת

ברירות המחדל של התבנית (Get-Data על LeadStatuses):

הסטטוס	ה‑objectId בתבנית
ליד חדש	e9TwcETDGq
ליד כפול	QYvLV9xHE1

באותה טבלה יושבים גם ZrOOwnHPiz = ליד תקול, ו‑NzEAM7MeLO = ליד בטיפול.

במערכות מותאמות — כלומר בחלק ניכר מהלקוחות — הם שונים. שלפו את LeadStatuses של הלקוח ואמתו:

JSON

// Get-Data
{ "table": "LeadStatuses", "keys": ["Name"], "limit": 100 }

קוד שמסתמך על מזהה שלא קיים במערכת הזו יכתוב סטטוס שגוי או ריק, בלי להתריע.

ב‑web2table — איש קשר קיים מקושר, לא משוכפל

כאן ההתנהגות הפוכה, וזו בדיוק הסיבה שיש שתי נקודות קצה:

התוצאה	מה קורה ל‑Accounts	מה קורה לטבלת היעד
נמצא איש קשר	לא נוצרת שורה חדשה, וגם לא מתעדכן דבר	נוצרת שורה חדשה, מקושרת אליו דרך AccountId
לא נמצא	נוצר איש קשר חדש עם הערכים מ‑account_* ומ‑DefaultValues.Account	נוצרת שורה חדשה, מקושרת אליו

איש קשר קיים לא מתעדכן — וזה מתוכנן

שדות account_* מוחלים רק כשנוצר איש קשר חדש. אם לקוח חוזר ממלא טופס עם כתובת חדשה, הכתובת הישנה נשארת.

הבקשה “שהטופס יעדכן את הפרטים של לקוח חוזר” אינה נתמכת בנקודת הקצה הזו — היא דורשת REST API בצד שרת או פונקציית שרת ייעודית. ראו מודל האבטחה.

IsFirst — השדה שנראה אמין ואינו

בכל שורה שנוצרת בטבלת היעד השרת ממלא IsFirst. הרבה דוחות “לידים חדשים מול לקוחות חוזרים” נשענים עליו — ולכן חשוב לדעת מתי הוא נכון:

מצב הבקשה	איש הקשר	IsFirst
כל בקשה	חדש	true
נשלח isExistsAccountCheck: true	קיים	false
לא נשלח isExistsAccountCheck	קיים	true ← לא נכון עסקית

בלי isExistsAccountCheck כל שורה מסומנת כראשונה

זה לא באג אלא ברירת מחדל, אבל התוצאה זהה: דוח שמראה 100% פניות ראשונות. אם IsFirst משמעותי לדיווח — שלחו את הדגל בכל בקשה.

אותו דגל משפיע גם על שדה ה‑Name שהשרת ממלא בשורה החדשה כשלא נשלח Name בבקשה:

המצב	ערך Name שנקבע
Name נשלח בבקשה	הערך שנשלח
איש קשר חדש	"פניה ראשונה"
איש קשר קיים + isExistsAccountCheck	"פניה חוזרת"

הפלטפורמה עצמה לא אוכפת ייחודיות

זו עובדה שקובעת ארכיטקטורה בכל אינטגרציה, לא רק בטפסים: אין אילוץ ייחודיות על PhoneNumber או על Email בטבלת Accounts. שום דבר לא ימנע מכם ליצור עשר רשומות עם אותו טלפון.

לכן:

• בטפסים — זיהוי הכפילויות של getlead / web2table הוא מה שמחליף את האילוץ החסר. זו סיבה טובה להשתמש בנקודות הקצה האלה ולא לכתוב יצירה ישירה.
• ב‑REST API — האחריות עליכם: find‑before‑create בכל זרימה שיוצרת אנשי קשר.

Bash

# find-before-create ב-REST — בדיקה לפני יצירה. צד שרת בלבד.
curl -sS -G "https://api.mbapps.co.il/parse/classes/Accounts" \
  -H "X-Parse-Application-Id: $APP_ID" -H "X-Parse-Master-Key: $MASTER_KEY" \
  --data-urlencode 'where={"PhoneNumber":"0501234567"}' \
  --data-urlencode 'limit=5'
# 0 תוצאות → ליצור · 1 → לעדכן · יותר מאחת → כפילות קיימת, דורשת החלטה אנושית

JavaScript

// find-before-create ב-REST — בדיקה לפני יצירה. צד שרת בלבד.
const params = new URLSearchParams({
  where: JSON.stringify({ PhoneNumber: '0501234567' }),
  limit: '5',
});
const res = await fetch(`https://api.mbapps.co.il/parse/classes/Accounts?${params}`, {
  headers: {
    'X-Parse-Application-Id': APP_ID,
    'X-Parse-Master-Key': MASTER_KEY,
  },
});
// 0 תוצאות → ליצור · 1 → לעדכן · יותר מאחת → כפילות קיימת, דורשת החלטה אנושית

Python

# find-before-create ב-REST — בדיקה לפני יצירה. צד שרת בלבד.
import json
import requests

res = requests.get(
    "https://api.mbapps.co.il/parse/classes/Accounts",
    headers={
        "X-Parse-Application-Id": APP_ID,
        "X-Parse-Master-Key": MASTER_KEY,
    },
    params={"where": json.dumps({"PhoneNumber": "0501234567"}), "limit": 5},
)
# 0 תוצאות → ליצור · 1 → לעדכן · יותר מאחת → כפילות קיימת, דורשת החלטה אנושית

PHP

<?php
// find-before-create ב-REST — בדיקה לפני יצירה. צד שרת בלבד.
$query = http_build_query([
    "where" => json_encode(["PhoneNumber" => "0501234567"]),
    "limit" => 5,
]);
$ch = curl_init();
curl_setopt_array($ch, [
    CURLOPT_URL => "https://api.mbapps.co.il/parse/classes/Accounts?{$query}",
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [
        "X-Parse-Application-Id: {$APP_ID}",
        "X-Parse-Master-Key: {$MASTER_KEY}",
    ],
]);
$response = curl_exec($ch);
curl_close($ch);
// 0 תוצאות → ליצור · 1 → לעדכן · יותר מאחת → כפילות קיימת, דורשת החלטה אנושית

אל תריצו קריאה כזו עם Application Id בלבד

מה שקורה בפועל תלוי ב‑CLP (הרשאות ברמת המחלקה) של Accounts בטננט שלכם:

• כש‑find סגור לאנונימי, GET /parse/classes/Accounts עם ה‑Application Id בלבד מוחזר עם 400 {"code":119,"error":"Permission denied for action find on class Accounts."}.
• כש‑find פתוח ("*": true) אותה קריאה מחזירה 200 עם רשומות אמיתיות — כלומר Application Id לבדו מספיק כדי לקרוא את פנקס הלקוחות.

בשני המקרים המסקנה זהה: find‑before‑create הוא תמיד קוד צד שרת עם Master Key או API Key, ולא קוד בדפדפן. בדקו את מצב ה‑CLP אצלכם ב‑GET /parse/schemas/Accounts לפני שאתם מסתמכים על כך שהקריאה חסומה.

שתי רשומות Accounts עם אותו טלפון ואותו אימייל ייווצרו זו אחר זו, שתיהן ב‑201 — אין שום אילוץ שמונע זאת.

Phone מול PhoneNumber

נתקלתם בשדה Phone בסקריפט דוגמה? השדה הקנוני שמנועי זיהוי הכפילויות של הטפסים עובדים מולו הוא PhoneNumber; בסכימת Accounts של תבנית vanilla אין שדה בשם Phone כלל. אל תקודדו שם שדה בלי לשלוף סכימה — התקנות שונות זו מזו.

מה להגיד ללקוח

שלושה משפטים שחוסכים שיחה שלמה אחרי העלייה לאוויר:

1. “אותו אדם שממלא פעמיים ייצור שתי רשומות.” ב‑getlead — שני לידים, השני מסומן ככפול. ב‑web2table — איש קשר אחד ושתי רשומות עסקיות.
2. “המערכת מסמנת, אתם מחליטים.” מיזוג לידים כפולים הוא תהליך עסקי — אפשר לבנות אותו כטריגר או כתצוגת עבודה על סטטוס “ליד כפול”, אבל הוא לא קורה מעצמו.
3. “פרטים של לקוח חוזר לא מתעדכנים מהטופס.” אם זה נדרש — זה פיתוח נפרד, לא הגדרה.

המשך

• getlead · web2table
• אבחון תקלות — “איש קשר הוכפל” ו“איש קשר קיים לא התעדכן”
• מיפוי שדות — איך שולפים את LeadStatuses ובונים מפה