מוסכמות המוצר

1 · Accounts היא הטבלה המרכזית — לידים ולקוחות באותו מקום

אין טבלת “לידים” נפרדת. שדה בוליאני יחיד מפריד:

IsAccount	המשמעות
false	ליד: פנייה שעדיין לא הפכה ללקוח
true	לקוח

המרה = הפיכת הדגל + חותמת ב‑LeadConversionDate (שם השדה בבסיס המוצר; אצל חלק מהלקוחות קיים במקביל ConversionDate — שלפו סכימה).

שדות שני העולמות יושבים על אותה שורה: LeadStatusId, LeadOwnerId, LeadSourceId מצד אחד; StatusId, TypeId, OwnerId מהשני. אחרי המרה משתנה התשובה לשאלה איזה שדה סטטוס משמעותי — מקור נפוץ לדוחות שגויים.

ספירת “לקוחות” בלי IsAccount היא ספירה שגויה

GET /parse/classes/Accounts?limit=0&count=1 מחזיר לידים ולקוחות יחד. כל ספירה, דוח וסנכרון מסננים במפורש: where={"IsAccount":true}.

כל רשומה עסקית אחרת (Sales, Cases, Tasks, Activities, טבלאות מותאמות) מקושרת ל‑Accounts בשדה Pointer בשם AccountId. מפת הטבלאות.

2 · שמות באנגלית, ערכים בעברית

שמות טבלאות ושדות: PascalCase / CamelCase באנגלית. התוכן בעברית.

המוסכמה	התבנית	דוגמאות
טבלאות	PascalCase, ברבים לישויות	Accounts, SaleRows, PriceQuotes, Conversations
מחלקות מערכת	קידומת _ (שמורה)	_User, _Timeline, _Dictionary, _syslogTriggers
שדות Pointer	<Entity>Id	AccountId, SaleStatusId, OwnerId
שדה תצוגה	לכל טבלת lookup וישות יש Name:String — חריג אחד במוצר: UserStatuses, עם name באות קטנה	ברירת המחדל של כל רשימה נפתחת
טבלאות lookup	<Entity>Statuses · <Entity>Types · <Entity>States	CaseStatuses, TaskTypes, CaseSubTypes, CaseStates
מטא‑מצב	StateId על טבלת סטטוס → טבלת *States קבועה	CaseStatuses.StateId→CaseStates, LeadStatuses.StateId→AccountStatusesStates
חותמת אוטומציה	updatedByTrigger:String על כל טבלה שטריגר נוגע בה — מזהה הטריגר שכתב אחרון	Accounts, Tasks, SaleRows

אל תחפשו שדה בשם “טלפון”

התוויות בממשק אינן שמות השדות. הן יושבות בטבלת _Dictionary, §4.

3 · שדה Pointer מסתיים ב‑Id

השדה	הטבלה שאליה הוא מצביע
AccountId	Accounts
ContactId	Contacts
SaleStatusId	SaleStatuses
LeadSourceId	LeadSource
OwnerId	_User
CurrentUserId	_User

הסיומת היא מוסכמה, לא חוזה

“כמעט תמיד” מספיק כדי לשבור קוד. היעד האמיתי מוחזר ב‑targetClass בתשובת הסכימה, וזה המקור המחייב. סכימות.

צורת הכתיבה של Pointer בכל שכבה: סוגי נתונים.

4 · התוויות בעברית — _Dictionary

שדות אינם מגיעים עם תווית עברית מהקופסה: במערכת חדשה _Dictionary כלל אינה קיימת, ואף שדה בתשובת הסכימה אינו נושא dictionary. השכבה נולדת עם ה‑label הראשון.

כשנוצר שדה עם label (למשל דרך Add-Field-to-Table), נכתבת מיד שורה ל‑_Dictionary:

JSON

{ "tblName": "Sales", "field": "OwnerSetDate", "value": "תאריך הגדרת אחראי" }

ומאותו רגע התווית חוזרת בתוך הגדרת השדה ב‑Get-Schema של שכבת ה‑MCP:

JSON

"OwnerSetDate": { "type": "Date", "dictionary": "תאריך הגדרת אחראי" }

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

מגבלה ידועה — ב‑REST התווית לא ממוזגת לסכימה

GET /parse/schemas/<Table> מחזיר את השדה בלי dictionary, גם כששורת ה‑_Dictionary קיימת. רק Get-Schema של MCP ממזג. ב‑REST שלפו את _Dictionary בעצמכם (API Key או Master Key) ומזגו לפי tblName + field.

שדה שנוצר בלי label נשאר באנגלית

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

מעל התוויות יושב מילון המונחים, שמחליף את שם הישות המוצג (מכירה→פרויקט) ואינו נוגע בשמות הסכימה. Set-Terminology-Dictionary לבדו אינו מעדכן טקסטים שכבר יושבים בעמודים ובתפריטים (“מכירות” נשאר בתפריט); להחלפה בתוכן העמודים יש כלי נפרד, Replace-Terms, שרץ דף אחר דף. מילון מונחים.

5 · בחירה מרובה — תבנית שם מיוחדת

אין טיפוס “בחירה מרובה”. שם השדה הוא המטא‑דאטה:

array_<purpose>_Pointer_<TargetTable>

JSON

{ "array_interests_Pointer_Interests": ["uNbbHuMGlK", "j17RjXmHdN"] }

• הטיפוס בסכימה חייב להיות Array.
• _Pointer_ הוא ליטרל עם P גדולה; שם טבלת היעד case‑sensitive.
• שגיאת אותיות (array_x_pointer_Y) או טיפוס Pointer שוברים את המנגנון בשקט: השדה נשמר בלי הרנדור הנכון.
• ערך שנבחר ולא נמצא בטבלת ה‑lookup — השמיטו את השדה מהגוף, אל תשלחו מחרוזת ריקה.

צורות האחסון והתחביר לשאילתה: סוגי נתונים.

6 · רשימות תלויות — האב יושב על העמוד, לא על הסכימה

רשימה נפתחת מסוננת לפי בחירה קודמת (מחלקה → תת‑מחלקה) עובדת בשלושה חלקים:

1. טבלת הבן מחזיקה Pointer יחיד חזרה לטבלת האב.
2. הטבלה המארחת מחזיקה שני שדות Pointer — אחד לאב, אחד לבן.
3. ההפעלה יושבת על שדה הבן בעמוד, לא בסכימה.

לכן אותה סכימה מתנהגת כרשימה תלויה בעמוד אחד וכרשימה רגילה באחר, ומי שמסתכל רק בסכימה לא יראה את ההבדל.

7 · המוסכמות שאין להן חריגים

הכלל	ההשלכה
objectId הוא בדיוק 10 תווים	מזהה באורך אחר בשדה table_<Field> של web2table נזרק בשקט (200 והשדה ריק); בשדה account_<Field> — ובכל כתיבה ב‑REST — הבקשה כולה נכשלת ב‑400 {"code":111,"error":"schema mismatch … expected Pointer<…> but got String"}. כלי Get-Data של MCP אוכף minLength/maxLength = 10 בסכימה
שם שדה אינו ניתן לשינוי	“תיקון” = שדה חדש + מיגרציה. לכן שדות עם שגיאות כתיב שורדים בייצור לנצח
טיפוס שדה ננעל אחרי הערך הראשון	תכננו שם וטיפוס לפני היצירה. התסמין: שדה Date/Pointer מחזיר שגיאה 111, אבל שדה String ממיר בשקט
אין אכיפת ייחודיות על PhoneNumber / Email	חיפוש‑לפני‑יצירה הוא באחריותכם
טבלה חדשה נולדת חסרת הרשאות	“השדות מופיעים ריקים” — התקלה מספר 1 אחרי הקמה

מחיקה נחסמת כשיש מצביע — ולא משאירה מצביעים תלויים

במערכת חדשה דלוק המתג Check dependencies before Delete operation (סביבת הפיתוח ← Databases ← המערכת ← Settings):

JSON

{ "code": 119,
  "error": "Pointer to Object xK9mP2qRsT exists in table Tasks in key AccountId. Delete is not allowed." }

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

דריפט בשמות שדות — Phone מול PhoneNumber

השדה הקנוני, שמנועי זיהוי הכפילויות ושיוך השיחות עובדים מולו, הוא PhoneNumber. מספרי טלפון ישראליים מאוחסנים בכמה פורמטים (05X…, 972…, +972…, עם מקפים ובלי) והפלטפורמה אינה מנרמלת. אל תקודדו רשימת שדות בלי לשלוף סכימה.

8 · כתיבות מפעילות אוטומציות

כל כתיבה — גם דרך Master Key, גם ב‑batch, גם מפונקציית שרת — מפעילה טריגרים מסוג data change: התראות, מיילים והודעות WhatsApp ללקוחות אמיתיים. השרשרת מוגבלת ל‑3 רמות עומק (הרשומה הרביעית בשרשרת כבר לא נוצרת, וב‑_syslogTriggers נרשם blocked! trigger step is to deep -3), אבל כל רשומה מפעילה את הרמה הראשונה.

לפני טעינה המונית תאמו עם מי שמחזיק את האוטומציות. ל‑POST /parse/batch אין דגל השתקה, ודגל skipTriggers ברמת הבקשה מתעלמים ממנו.

Create-Many עם skipTriggers — הדגל מכובד

skipTriggers ו‑skipTimeline מכובדים באימות Master Key: הרשומה נוצרת בלי שהטריגר רץ ובלי שורת _Timeline. data הוא אובייקט שטוח — כל מפתח הוא שם שדה, וכך גם ב‑Create-Data / Update-Data. כלי נתונים.

batch · מגבלות ומכסות.

המשך מכאן

• סוגי נתונים — הפורמט ב‑JSON לכל טיפוס, בשלוש השכבות
• מפת הטבלאות — לאיזו טבלה כותבים
• מילון מונחים — מהמונח של הלקוח אל שם המחלקה
• סכימות — המקור המחייב לכל מערכת
• עבודה עם רשומות — ה‑CRUD עצמו