יישום Salesforce Optimization · CloudX
שיפור ותמיכה ב-Salesforce קיים: Health Check, ניקוי נתונים ואדמין במיקור חוץ
CloudX היא חברת ייעוץ ישראלית שמשפרת ומתחזקת מערכות Salesforce (סיילספורס) קיימות. אנחנו מתחילים ב-Health Check שממפה נתונים, אוטומציות, הרשאות וחוב טכני, בונים תוכנית תיקונים לפי סדר עדיפויות, מבצעים אותה בשלבים ונשארים כאדמין ותמיכה שוטפת. גם הטמעה שלא הצליחה אפשר בדרך כלל לייצב ולשפר בלי להתחיל מאפס. אנחנו עובדים עם סטארטאפים, חברות סייבר ו-SaaS, עמותות וקרנות, ומתמחים בפיתוח כלי מדידת ARR ובתהליכי Go-To-Market.
סימנים שה-Salesforce שלכם צריך טיפול
רוב הארגונים שפונים אלינו לא מחפשים מערכת חדשה. יש להם Salesforce (סיילספורס) שעובד, אבל לא כמו שהוא אמור לעבוד. אלה הסימנים שאנחנו רואים הכי הרבה:
- הצוות עוקף את המערכת. אנשי המכירות מנהלים גיליון בצד, והנתונים מגיעים ל-Salesforce באיחור או לא מגיעים בכלל.
- הדוחות לא מסכימים זה עם זה. השיווק, המכירות והכספים מציגים מספרים שונים לאותה שאלה, ואף אחד לא סומך על הדשבורד.
- שגיאות Flow במייל. הודעות כשל נוחתות בתיבה של מישהו, ואף אחד לא בטוח מה הן שוברות.
- כפילויות. אותו לקוח מופיע פעמיים או שלוש, וההיסטוריה שלו מפוצלת בין רשומות.
- פחד לשנות. כל שינוי קטן שובר משהו אחר, כי אין תיעוד ואין מי שמכיר את המערכת לעומק.
- הרשאות רחבות מדי או צרות מדי. משתמשי אינטגרציה עם System Administrator, ובמקביל אנשי מכירות שנחסמים בעריכה של הרשומות שלהם.
- האדמין עזב. תהליכים ממשיכים לרוץ תחת המשתמש של מי שכבר לא בחברה, והגישה שלו לא באמת נחסמה.
- התראות מ-Salesforce שאף אחד לא מטפל בהן. תעודות שפגות, דרישות MFA ויכולות שיוצאות משימוש.
אם שלושה או יותר מהסימנים האלה מוכרים לכם, Health Check הוא הצעד הנכון הבא.
מה בודקים ב-Health Check של Salesforce
Health Check הוא בדיקה מסודרת של ה-org, עם גישת קריאה בלבד, שמסתיימת בממצאים ובתוכנית עבודה לפי סדר עדיפויות. זה ההיקף שאנחנו מכסים:
| תחום | מה בודקים | ממצאים נפוצים |
|---|---|---|
| נתונים | כפילויות, שדות חובה ריקים, ערכים לא אחידים, Matching Rules ו-Duplicate Rules | אותו לקוח בכמה רשומות, ערכי מדינה וארץ לא תקינים שמפילים Flows |
| אוטומציות | Flows, Workflow Rules, Process Builder, Apex Triggers וסדר ההפעלה ביניהם | כמה Flows על אותו אובייקט, אוטומציות ישנות שעדיין רצות, Flows בלי טיפול בשגיאות |
| אבטחה והרשאות | פרופילים, Permission Sets, Sharing Rules, היררכיית תפקידים, FLS, MFA ו-SAML | משתמשי אינטגרציה עם הרשאות אדמין, עקיפת MFA, תעודות שפגו |
| תלויות ומשתמשים | משימות מתוזמנות, חיבורי OAuth, Email-to-Case, נמעני התראות, Outbound Messages | תהליכים קריטיים שרצים תחת משתמש של עובד שעזב |
| חוב טכני | קוד בלי בדיקות, שדות ואובייקטים שלא בשימוש, יכולות שיוצאות משימוש | קריאות SOAP API ישנות, רכיבים שאף אחד לא יודע מה הם עושים |
| אימוץ ודוחות | מי נכנס, מה מעודכן, אילו דוחות בשימוש ועל אילו הגדרות הם נשענים | דוחות שסותרים זה את זה, דשבורדים שאף אחד לא פותח |
נתונים
נתונים לא נקיים הם הסיבה הראשונה שצוותים מפסיקים לסמוך על Salesforce. אנחנו מודדים כפילויות ב-Lead, Contact ו-Account, בודקים את ה-Matching Rules וה-Duplicate Rules הקיימים, ובונים זיהוי לפי מייל, דומיין או שם וחברה. איחוד רשומות נעשה בכלי ייעודי או ברכיב LWC ו-Apex שאנחנו בונים לזה, תמיד עם כללים כתובים לגבי איזו רשומה שורדת ומה קורה להיסטוריה.
אוטומציות
ב-org שגדל לאורך שנים יש בדרך כלל שכבות: Workflow Rules ו-Process Builder מהדור הקודם, Flows שנבנו על ידי כמה אנשים שונים, ולפעמים גם Apex Triggers. אנחנו ממפים מה רץ על כל אובייקט ובאיזה סדר, מאתרים לולאות ורקורסיה, מעבירים אוטומציות ישנות ל-Flow ומוסיפים Fault Paths, כדי שכשל יגיע לאדם הנכון במקום להיבלע. כשאפשר, ממירים Flow ל-Before-Save, שרץ מהר יותר ולא מפעיל עדכון נוסף על הרשומה.
אבטחה, שיתוף ו-FLS
כאן נמצאים הממצאים הרגישים ביותר. אנחנו בודקים מי רואה אילו רשומות ושדות, איך Sharing Rules והיררכיית התפקידים משתלבים, אילו משתמשים יכולים לעקוף MFA, ואילו משתמשי אינטגרציה רצים עם פרופיל System Administrator במקום Permission Set מינימלי על רישיון Integration ייעודי. אחר כך מעבירים את הגישה ל-Permission Sets ו-Permission Set Groups, ובודקים כל תפקיד בתרחיש אמיתי.
חוב טכני ואימוץ
חוב טכני ב-Salesforce הוא לא רק קוד. הוא גם שדות שאף אחד לא ממלא, דוחות שנשענים על הגדרות שהשתנו, ויכולות ש-Salesforce מוציאה משימוש. במקביל אנחנו בודקים אימוץ: מי באמת עובד במערכת, איפה הצוות עוקף אותה, ומה המסכים צריכים כדי שהעבודה תהיה מהירה יותר בפנים מאשר בחוץ.
הטמעה שלא הצליחה: לייצב במקום להתחיל מאפס
הטמעת סיילספורס שלא הצליחה היא מצב נפוץ מאוד, והיא כמעט אף פעם לא אומרת שצריך לזרוק את המערכת. ברוב המקרים מודל הנתונים סביר, והבעיה היא אוטומציות שנבנו בלי תכנון, הרשאות שלא נבדקו, ותהליך שלא הותאם לאופן שבו הצוות עובד בפועל.
הגישה שלנו היא לייצב קודם: לעצור את מה שמשבש נתונים, לתקן את מה שחוסם את העבודה היומית, ורק אז לבנות מחדש חלקים ספציפיים. בנייה מחדש מלאה שווה את זה רק כשמודל הנתונים עצמו חוסם את העסק, ואת ההחלטה הזו מקבלים על בסיס ממצאי ה-Health Check ולא על בסיס תחושה.
איך CloudX עובדת: בדיקה, תוכנית, תיקונים ותמיכה
- בדיקה (Audit). גישת קריאה בלבד, שיחות עם בעלי התפקידים המרכזיים, ומיפוי של נתונים, אוטומציות, הרשאות, תלויות ודוחות. בסוף מקבלים מסמך ממצאים בשפה עסקית, ולא רק רשימה טכנית.
- תוכנית לפי סדר עדיפויות. כל ממצא מקבל רמת סיכון, הערכת מאמץ ובעלים. קודם מה שעלול לשבור תהליך קריטי או לחשוף נתונים, אחר כך מה שחוסם את הצוות, ובסוף שיפורים.
- תיקונים בשלבים. כל שינוי נבנה ב-Sandbox, נבדק, עובר דרך ניהול גרסאות ו-Salesforce CLI ונפרס עם תוכנית חזרה. שינויים רגישים, כמו השבתת משתמש או החלפת משתמש אינטגרציה, מקבלים Change Plan ו-Runbook כתובים.
- תמיכה שוטפת. אחרי הייצוב אנחנו ממשיכים כצוות אדמין ופיתוח: פניות, שגיאות, שינויים קטנים, שיפורים והיערכות לשחרורים של Salesforce.
אדמין Salesforce במיקור חוץ ותמיכה שוטפת
לא כל ארגון צריך אדמין Salesforce במשרה מלאה, וגם ארגון שיש לו אדמין צריך לפעמים מפתח, ארכיטקט או מומחה אבטחה. מודל האדמין כשירות של CloudX נותן גישה לצוות שלם, לפי הצורך.
מה כלול בדרך כלל:
- טיפול בפניות משתמשים: הרשאות, שדות, דוחות ותקלות.
- אבחון ותיקון של שגיאות Flow ו-Apex, כולל שורש הבעיה ולא רק עקיפה.
- שינויים ופיתוחים קטנים, מ-Validation Rules ועד רכיבי LWC.
- ניהול משתמשים, כולל Onboarding ו-Offboarding בטוח של עובדים.
- מעקב אחרי התראות Salesforce: תעודות, MFA, יכולות שיוצאות משימוש ושחרורים.
- תיעוד שוטף של ה-org, כך שהידע נשאר אצלכם.
כשאדמין עוזב, אנחנו ממפים לפני ההשבתה את מה שרץ תחת המשתמש שלו, ומעבירים כל פריט לבעלים חדש לפי Runbook. השבתה לפני המיפוי עוצרת לא פעם תהליכים בלי שום שגיאה גלויה.
GTM, RevOps ומדידת ARR
חלק גדול מעבודת השיפור שלנו נעשה בסטארטאפים ובחברות סייבר ו-SaaS, שבהן Salesforce הוא המערכת של צוותי ה-Go-To-Market. שם הבעיות חוזרות על עצמן: ליד שנמצא גם במצב MQL וגם במצב SQL, שלבי מכירה שאפשר לדלג עליהם, תאריכי סגירה שזזים בעסקאות חידוש, ומשתמשי אינטגרציה של כלי Sales Engagement עם הרשאות מלאות.
אנחנו מתמחים בפיתוח כלי מדידת ARR בתוך Salesforce. ב-org קיים זה מתחיל בבדיקה של איפה ההכנסה באמת יושבת: שורות חוזה, מנויים או Opportunity Products. משם בונים תהליך מתוזמן שכותב Snapshot לכל לקוח בכל תקופה, מסווג כל שינוי כלקוח חדש, הרחבה, צמצום או נטישה, ומוסיף בקרת חידוש שמתריעה כשתאריך החידוש לא תואם לחודש ההכנסה האחרון. התוצאה היא מספר ARR אחד שההנהלה והדירקטוריון יכולים לסמוך עליו, עם עקבות לכל שינוי.
על הטמעות GTM מלאות, Agentforce ואינטגרציות אפשר לקרוא בעמוד הטמעת Salesforce שלנו.
בקרת איכות בעזרת AI
שיפור של org קיים דורש לדעת מראש מה כל שינוי עלול לשבור. לכן אנחנו משלבים AI בבקרת האיכות שלנו, ואדם תמיד מאשר את התוצר:
- סוכן QA אוטומטי שרץ בייצור בעבודת המסירה שלנו. שינוי סטטוס ב-monday.com מפעיל בדיקה של Validation Rules, Flows, הרשאות ובדיקות Apex, והדוח חוזר לאותו פריט.
- תדריך על org לא מוכר (הדגמה). סקיל של Claude שקורא מטא-דאטה במצב קריאה בלבד ומפיק פרופיל ארגון, תדריך על שגיאת Flow ותדריך השפעה של שינוי מתוכנן. בהרצה על org אמיתי, תדריך השגיאה זיהה שורש בעיה שונה ממה שהודעת השגיאה רמזה.
שלבי פרויקט שיפור טיפוסי
- שיחת פתיחה. מה כואב היום, מי משתמש במערכת, ואילו התראות או תקלות פתוחות.
- גישה. משתמש לקריאה בלבד בסביבת Production וגישה ל-Sandbox.
- Health Check. מיפוי ומסמך ממצאים.
- סדנת עדיפויות. עוברים יחד על הממצאים ומחליטים מה מתקנים קודם.
- ייצוב. תיקון מה שמסכן נתונים, אבטחה או תהליכים קריטיים.
- שיפור. ניקוי נתונים, איחוד אוטומציות, הרשאות, מסכים ודוחות.
- תיעוד ומסירה. תיעוד ה-org ותוכנית לשלב הבא.
- תמיכה שוטפת. אדמין כשירות, בהיקף שמתאים לכם.
Health Check ממוקד לוקח בדרך כלל כמה שבועות, ותוכנית ייצוב ושיפור נמשכת לרוב כמה חודשים, בהתאם להיקף ה-org ולמספר הצוותים.
ממה מורכבת העלות
אין מחיר קבוע לשיפור Salesforce, כי העלות נגזרת ממה שנמצא ב-org. הגורמים העיקריים:
- גודל ומורכבות ה-org: מספר האובייקטים המותאמים, ה-Flows, קוד ה-Apex והאינטגרציות.
- מצב הנתונים: כמות הכפילויות והיקף הניקוי וההסבה.
- רגישות אבטחה: מספר התפקידים, פורטלים חיצוניים ודרישות רגולציה או ביקורת.
- היקף הבנייה מחדש: תיקונים נקודתיים לעומת החלפה של תהליך שלם.
- מודל התמיכה: בנק שעות, ריטיינר חודשי או צוות שמשולב בעבודה השוטפת.
ה-Health Check עצמו הוא הדרך האמינה לקבל הערכה, כי הוא מחליף ניחוש בממצאים.
מעבר לתיקון: הצעדים הבאים
org מיוצב הוא בסיס טוב להרחבה. ארגונים רבים ממשיכים מכאן ל-Agentforce וסוכני AI, לאינטגרציה מסודרת עם NetSuite ומערכות נוספות דרך Workato, או, בעמותות ובקרנות, לשיפור של NPSP או Nonprofit Cloud (Salesforce לעמותות).
שלחו לנו מה לא עובד היום ב-Salesforce שלכם. נגיד לכם מה כדאי לבדוק קודם ואיך ייראה Health Check אצלכם. קבעו שיחה.
פרויקטים שעשינו
כמה חברות SaaS, סייבר ומדיה · בייצור
Offboarding בטוח של אדמין ומשתמשי אינטגרציה
בכמה חברות SaaS, סייבר ומדיה אדמין ותיק עמד לעזוב, ותהליכים רבים רצו תחת המשתמש שלו. מיפינו את טביעת הרגל שלו ב-org: משימות מתוזמנות, חיבורי OAuth, Outbound Messages, Email-to-Case, דשבורדים שרצים בשמו ונמעני התראות, כולל 33 נקודות הגדרה של התראות ב-org אחד. כל חברה קיבלה Change Plan לפי דחיפות ו-Runbook מפורט. באחת מהן גילינו שסגירת חשבון ה-Google של העובד לא חוסמת את הכניסה, כי למשתמש יש סיסמה מקומית והרשאה לעקוף MFA. בחברת סייבר העברנו Flow יומי קריטי לבעלים פעיל, חיזקנו אותו עם Fault Paths, והעברנו את משתמש האינטגרציה של כלי ה-Sales Engagement מפרופיל System Administrator ל-Permission Set מינימלי על רישיון Integration ייעודי.
חברת טכנולוגיה לענף הבנייה · בייצור
תיקון Flows והרשאות בחוזים ובמעקב פגישות
אנשי המכירות נחסמו בעריכת חוזים אחרי שהופעלו, ו-Flow של תוצאות פגישות היכרות יצר משתתפים בלי שדות המעקב, כך שהצטברו כ-1,360 שורות לא תואמות. נתנו הרשאת הפעלת חוזים לפרופילי המכירות הרלוונטיים, והוספנו Validation Rule שמתיר עריכה של שני שדות מוגדרים בחוזה פעיל ונועל את השאר. את ה-Flow שמחתים תאריכים על תפקידי אנשי קשר בפרויקט המרנו ל-Before-Save, ואבחנו את שורש הבעיה ב-Flow של תוצאות הפגישה. הצוות עובד על החוזים בלי לפתוח פניות לאדמין, והחוזים הפעילים נשארים מוגנים.
חברת אד-טק · בייצור
החזרת זרימת הנתונים מ-Data Cloud ל-Marketing Cloud
זרמי הנתונים של Contact, Lead, Account ו-Opportunity נכשלו בכל רענון במשך חודשים, ושום רשומה לא הגיעה ל-Marketing Cloud. איתרנו את הסיבה: שדות של פיצ'ר שכבר כובה נשארו בשאילתת ה-stream. מאחר שב-Data Kit מנוהל אי אפשר למחוק אותם, השבתנו אותם ב-stream והחזרנו את הזרימה. באותה עבודה הגדרנו External Client App להעברת אינטגרציה של הלקוח מ-SOAP API, שיוצא משימוש, ל-REST, ומסרנו למפתחים שלו את הפרטים. לאורך הדרך הלקוח קיבל עדכונים בשפה לא טכנית.
מוסד להשכלה גבוהה וארגוני B2B · בייצור
החזרת מיזוג הכפילויות הלילי וניהול כפילויות לפי דומיין
במוסד להשכלה גבוהה, חשבונות עם אותו מייל, שבאחד מהם חסר מספר זהות, הפסיקו להתמזג במיזוג האוטומטי הלילי, והכפילויות התחילו להצטבר. פירקנו את הלוגיקה של חוק המיזוג, הסברנו לצוות איך הוא מחליט, וניהלנו את הבירור מול התמיכה של Cloudingo עד שנמצאה הסיבה: אינדוקס חלקי. אחרי אינדוקס מחדש המיזוג הלילי חזר לרוץ בהצלחה. בארגוני B2B אנחנו בונים זיהוי כפילויות לפי דומיין מייל על פני Lead, Contact ו-Account: שדה שמחלץ את הדומיין, השלמה לרשומות קיימות, Matching Rules ו-Duplicate Rules, ועקיפה מבוקרת למשתמש האינטגרציה.
חברות סייבר ו-SaaS · בייצור
Snapshot של ARR ובקרת חידושים
צוותי ה-GTM היו צריכים מספר ARR אחד, ותהליכי מכירה שמזינים אותו באופן עקבי. בנינו אוטומציית ARR שכותבת Snapshot לכל לקוח בכל תקופה ורושמת כל תנועה ברמת ה-Account, Flow שפותח הזדמנות מפגישת Prospecting, ו-Screen Flow שמחייב סיבה מסודרת כשעסקה נסגרת כהפסד. נוסחת בקרה בדוח משווה את תאריך החידוש לחודש ההכנסה האחרון לפי הפרש חודשים, כך שרק מקרים שבאמת חורגים מסומנים לבדיקה. ההנהלה רואה ARR ותנועות על אותם נתונים שהצוות מעדכן ממילא.
חברת SaaS · בייצור
סקירת אבטחה: SAML, MFA עמיד לפישינג ופרישת SOAP
החברה מתחברת ל-Salesforce דרך Google Workspace כ-SAML IdP, וקיבלה בבת אחת כמה התראות: תעודת חתימה שפגה, דרישה ל-MFA עמיד לפישינג והודעה על פרישת SOAP API. בדקנו שהחלפת התעודה לא דורשת תיאום מול Google, איתרנו תעודות ישנות והגדרה של Salesforce כ-IdP שלא הייתה בשימוש, וניתחנו את היסטוריית הכניסות כדי לבדוק אילו אינטגרציות עדיין נשענות על SOAP. סימנו גם משתמש אינטגרציה של מערכת השיווק שרץ עם הרשאות System Administrator. הצוות קיבל תשובה ברורה ותוכנית פעולה לכל התראה.
שאלות נפוצות
מה זה Health Check ל-Salesforce ומה הוא כולל?
Health Check הוא בדיקה מסודרת של org קיים, בגישת קריאה בלבד, שמסתיימת במסמך ממצאים ובתוכנית עבודה לפי סדר עדיפויות. הוא מכסה איכות נתונים וכפילויות, אוטומציות (Flows, Workflow Rules, Process Builder ו-Apex), הרשאות, שיתוף ו-FLS, תלויות במשתמשים ובאינטגרציות, חוב טכני, ואימוץ ודוחות. כל ממצא מקבל רמת סיכון, הערכת מאמץ ובעלים.
כמה זמן לוקח Health Check למערכת סיילספורס?
Health Check ממוקד לוקח בדרך כלל כמה שבועות, בהתאם לגודל ה-org, למספר האוטומציות והאינטגרציות ולמספר הצוותים שעובדים במערכת. תוכנית הייצוב והשיפור שאחריו נמשכת לרוב כמה חודשים, ואפשר לבצע אותה בשלבים בלי לעצור את העבודה השוטפת.
הטמעת ה-Salesforce שלנו לא הצליחה. צריך להתחיל מאפס?
בדרך כלל לא. ברוב ההטמעות שלא הצליחו מודל הנתונים סביר, והבעיה היא אוטומציות שנבנו בלי תכנון, הרשאות שלא נבדקו ותהליך שלא הותאם לעבודה בפועל. אנחנו מייצבים קודם, מתקנים את מה שחוסם את הצוות, ובונים מחדש רק חלקים ספציפיים. בנייה מלאה מחדש שווה את זה רק כשמודל הנתונים עצמו חוסם את העסק.
מי נותן תמיכה ב-Salesforce בישראל?
CloudX היא חברת ייעוץ ישראלית שנותנת תמיכה שוטפת ב-Salesforce לסטארטאפים, לחברות סייבר ו-SaaS, לעמותות ולקרנות, בעברית ובאנגלית. התמיכה כוללת טיפול בפניות משתמשים, אבחון ותיקון שגיאות Flow ו-Apex, שינויים ופיתוחים קטנים, ניהול משתמשים, מעקב אחרי התראות Salesforce ותיעוד שוטף של ה-org.
אדמין Salesforce במיקור חוץ או אדמין בתוך החברה?
אדמין במיקור חוץ מתאים לארגון שלא צריך משרה מלאה, או לארגון שיש לו אדמין אבל צריך לפעמים מפתח, ארכיטקט או מומחה אבטחה. במודל האדמין כשירות של CloudX מקבלים גישה לצוות שלם לפי הצורך, עם תיעוד שנשאר אצלכם. ארגונים עם אדמין פנימי משתמשים בנו לא פעם כגיבוי ולפרויקטים שדורשים פיתוח.
איך מנקים כפילויות ונתונים ב-Salesforce?
מתחילים במדידה: כמה כפילויות יש ב-Lead, Contact ו-Account ולפי אילו מפתחות (מייל, דומיין, שם וחברה). אחר כך מגדירים כללים כתובים לגבי איזו רשומה שורדת, מאחדים בכלי ייעודי או ברכיב LWC ו-Apex, ומוסיפים Matching Rules ו-Duplicate Rules כדי שכפילויות חדשות ייעצרו בכניסה. ניקוי ערכים לא אחידים, כמו מדינות וארצות, מונע גם שגיאות Flow.
כמה עולה שיפור או תמיכה שוטפת ב-Salesforce?
אין מחיר קבוע, כי העלות נגזרת ממה שנמצא ב-org: מספר האובייקטים, ה-Flows, הקוד והאינטגרציות, מצב הנתונים, רגישות האבטחה, היקף הבנייה מחדש ומודל התמיכה (בנק שעות, ריטיינר או צוות משולב). ה-Health Check הוא הדרך האמינה לקבל הערכה, כי הוא מחליף ניחוש בממצאים.
איך מעבירים Workflow Rules ו-Process Builder ל-Flow?
ממפים קודם את מה שרץ על כל אובייקט ובאיזה סדר, כולל Apex Triggers. אחר כך מעבירים כל אוטומציה ל-Flow ב-Sandbox, מאחדים Flows כפולים, ממירים ל-Before-Save כשאפשר, ומוסיפים Fault Paths. כל העברה נבדקת מול תרחישים, ורק אז מכבים את האוטומציה הישנה בייצור.
האדמין שלנו עוזב. מה עושים לפני שמשביתים את המשתמש?
לפני ההשבתה מאתרים את מה שרץ תחת המשתמש: משימות מתוזמנות, חיבורי OAuth, Email-to-Case, Outbound Messages, דשבורדים ונמעני התראות. מעבירים כל פריט לבעלים חדש לפי Change Plan ו-Runbook כתובים, ובודקים שגם הגישה באמת נחסמת, למשל כשיש למשתמש סיסמה מקומית או הרשאה לעקוף MFA. השבתה לפני המיפוי עוצרת לא פעם תהליכים בלי שגיאה גלויה.
איך בודקים הרשאות ו-FLS ב-Salesforce?
בודקים פרופילים, Permission Sets, Sharing Rules והיררכיית תפקידים, ומאתרים מי רואה אילו רשומות ושדות. מחפשים במיוחד משתמשי אינטגרציה עם פרופיל System Administrator, משתמשים שיכולים לעקוף MFA ושדות רגישים בלי FLS מתאים. אחר כך מעבירים את הגישה ל-Permission Sets ו-Permission Set Groups, ובודקים כל תפקיד בתרחיש אמיתי.
איך מודדים ARR ב-Salesforce כשהנתונים לא מסודרים?
מתחילים בבדיקה של איפה ההכנסה באמת יושבת: שורות חוזה, מנויים או Opportunity Products. אחר כך בונים תהליך מתוזמן שכותב Snapshot לכל לקוח בכל תקופה ומסווג כל שינוי כלקוח חדש, הרחבה, צמצום או נטישה, לצד בקרת חידוש שמתריעה על תאריכים שלא תואמים לחודש ההכנסה האחרון. CloudX מתמחה בפיתוח כלי מדידת ARR בתוך Salesforce.
אפשר לשפר את Salesforce בלי להפריע לעבודה השוטפת?
כן. כל שינוי נבנה ונבדק ב-Sandbox, עובר דרך ניהול גרסאות ו-Salesforce CLI ונפרס עם תוכנית חזרה. שינויים רגישים מתוזמנים מראש ומלווים ב-Runbook, והצוות ממשיך לעבוד כרגיל בזמן שהשיפורים עולים בשלבים.
אתם עובדים גם על org שהטמיע שותף אחר?
כן, רוב עבודת השיפור שלנו נעשית על orgs שהוטמעו על ידי אחרים או נבנו לאורך שנים על ידי כמה אנשים. אנחנו מתחילים בקריאה של ההגדרות הקיימות ובתיעוד שלהן, כך שגם אם אין תיעוד מסודר, יוצאים מה-Health Check עם תמונה ברורה של מה רץ ולמה.
עודכן לאחרונה: