פרויקט סיום חלק א'
21/03/2026
אין תגובות
פרויקט סיום חלק א'
Loading…
Reload document 
Open in new tab 
דף הבית לאחר עדכון והוספת דשבורד
מסמך אפיון ויישום Salesforce
פרויקט גמר CRM-Period
ניהול משרות וגיוס עובדים – : WeJobs
| שם הפרויקט | מערכת ניהול משרות וגיוס עובדים |
|---|---|
| מסלול | יישום Salesforce – CRM-Period |
| שם הסטודנט: | עדי דורון |
| מרצים | מיכל חביב | אורן מורן | גיל הוד | הודיה שלו |
| תאריך הגשה | 15/03/2026 |
| גרסת מסמך | V2.2 |
תקציר מנהלים (Executive Summary)
מטרת הפרויקט היא יישום מערכת Salesforce לניהול מקצה-לקצה של תהליכי השמה:
פתיחת משרות, ניהול מועמדים, ראיונות, התאמה, השמה ומעקב לאחר קליטה.
המערכת תספק מקור אמת אחד, אוטומציות ודוחות ניהוליים בזמן אמת.
הפרויקט מתאר אפיון ויישום מערכת Salesforce לניהול תהליכי השמה מקצה לקצה:
איסוף מועמדים, ניהול לקוחות (מעסיקים), פתיחת משרות, תיאום ראיונות,
ביצוע השמות, ומעקב KPI תפעולי וניהולי. המטרה היא סטנדרטיזציה של התהליך,
שיפור איכות הנתונים, הפחתת עבודה ידנית, ושקיפות מלאה באמצעות דוחות ודשבורד
תוצרים עיקריים:
- מודל נתונים מותאם (אובייקטים ושדות) לתהליך השמה
- אוטומציות (Flows) לניהול סטטוסים, התראות, ומשימות
- מסכי Lightning מותאמים לפרופילי משתמש (Recruiter / Manager)
- דוחות ודשבורד לניהול משפך השמה ומדדי ביצוע
- תוכנית בדיקות UAT ומסמך הדרכה למשתמשים
המצב הקיים (AS-IS)
תיאור החברה
WeJobs היא חברת השמה שלי לשעבר הפועלת בישראל ומלווה ארגונים בתהליכי גיוס. החברה מנהלת מאגר מועמדים, לקוחות עסקיים, ומשרות פתוחות – באמצעות שילוב של Excel, מיילים, ו WhatsApp. מצב זה מייצר כפילויות, חוסר עקביות בסטטוסים, ואובדן מידע לאורך התהליך.
תהליכים קיימים
המצב היום התהליך מנוהל באמצעות Excel, מיילים ו-WhatsApp ללא מערכת מרכזית
- קליטת מועמד: קבלת קורות חיים, הזנה ידנית לקובץ, והמשך תקשורת במייל.
- פתיחת משרה: בקשה ממעסיק, תיעוד באקסל, ושיתוף במייל למגייסים.
- שידוך: התאמה ידנית בין מועמד למשרה, תיאום ראיונות, ומעקב בוואטסאפ
- השמה: סיכום בעל פה, ללא תיעוד אחיד של תנאים, דמי הצלחה, ומועד התחלה.
בעיות ואתגרים (Pain Points)
| # | בעיה | השפעה |
|---|---|---|
| 1 | סטטוסים לא אחידים (ראיון/הצעה/השמה) בין מגייסים | עיכובים בהשמה, ניהול משפך לא מדויק וקושי בניהול עומסים |
| 2 | מידע מבוזר | איבוד נתונים |
| 3 | אין דוחות או מדדים (Time to Fill, Conversion) | קושי ניהולי, קבלת החלטות ללא נתונים |
| 4 | אין SLA | פגיעה בלקוחות |
| 5 | כפילויות במועמדים ובמשרות, ללא מנגנון דה-דופליקציה אחיד | בזבוז זמן, טעויות בתקשורת מול לקוחות |
מטרות הפרויקט (TO-BE) ו- (KPIs)
מטרות עסקיות
שקיפות, אוטומציה של תהליכים, מדידה.
- אחידות תהליך ומדיניות סטטוסים בכל הארגון
- שיפור איכות נתונים והפחתת כפילויות
- קיצור זמן איוש (Time to Fill) באמצעות אוטומציות ומשימות
- שקיפות מלאה למשפך גיוס והחלטות מבוססות נתונים
מדדים להצגה בדף הבית (KPIs)
- רשימת משרות פתוחות
- רשימת מועמדים בתהליך
- רשימת מועמדים שממתינים להחלטה
Scope הפרויקט
In Scope
אובייקטים, Flows, דוחות, הרשאות, דשבורד, Lightning Pages
- הקמת אפליקציה ייעודית: WeJobs Recruiting
- הגדרת אובייקטים: מועמד, משרה, מועמדות (קישור), ראיון, מטלה, המלצה (ממליץ)
- אוטומציות Flow: TBD
- הרשאות: Profiles/Permission Sets, Role Hierarchy, Sharing בסיסי
- דוחות ודשבורד: רשימת משרות פתוחות, מועמדים בתהליך, מועמדים שממתינים להחלטה
- בדיקות UAT והדרכת משתמשים
Out of Scope
אינטגרציות חיצוניות, מיגרציה
- אינטגרציה דו-כיוונית עם מערכות ATS חיצוניות
- מיגרציה מלאה של היסטוריה מאקסלים ישנים (בוצע רק סט נתונים מדגם)
אפיון תהליכים עסקיים (Use Cases)
| ID | Use Case | Actor | Trigger | תוצאה |
|---|---|---|---|---|
| UC-01 | קליטת מועמד חדש | TBD | קליטת קו"ח או ליד חדש | קורות חיים במערכת |
| UC-02 | פתיחת משרה ללקוח | TBD | בקשה ממעסיק | משרה פתוחה ממעסיק |
| UC-03 | שיוך מועמד למשרה (מועמדות) | TBD | מועמד מתאים למשרה פתוחה | זימון וסטטוס מעודכן |
| UC-04 | תיאום ראיון ועדכון תוצאות | TBD | הוגדר ראיון עם המעסיק | Application |
| UC-05 | השמה וסגירה עסקית | TBD | קבלת המועמד לעבודה והסכמה על תנאים | Application |
אפיון מבנה נתונים (Data Model)
אובייקטים סטנדרטיים
| Object API | תיאור |
|---|---|
| Reports | דוחות להצגת המקורות הטובים ביותר |
| Dashboards | מאגד דוחות ונתונים על משרות פתוחות מועמדים חזקים |
אובייקטים מותאמים אישית
| Object API | תיאור |
|---|---|
| Candidate | מועמד (פרטי מועמד, כישורים, סטטוס במאגר) |
| Jobs | משרה/דרישת לקוח (תפקיד, אזור, שכר, סטטוס) |
| Applications | מועמדות: קישור N:N בין מועמד למשרה + סטטוס תהליך |
| Interviews | ראיון: תאריך, סוג, תוצאה, הערות |
| Recommendations | המלצות / המלצה - ממליץ |
| Assignments | מטלת בית |
קשרים בין אובייקטים
תרשים קשרים (ברמה לוגית)
Job (משרה) 1 ——< Application (מועמדות) >—— 1 Candidate (מועמד)
ומתחת ל־Application (כהורה תהליך):
- Application ——< Interview
- Application ——< Assignment
- Application ——< Recommendation
ובנוסף:
- Recommendation ——(Lookup)→ Candidate (לנוחות דיווח/שליפה)
- Interview ——(Lookup)→ User (Interviewer)
קישור: Application ⬅ Job (Master-Detail)
סיבת הבחירה:
- במסמך מופיע: “מועמדות למשרה” היא ישות תלוית משרה ומקשרת בין מועמד למשרה
- עסקית: כשמשרה נסגרת/נמחקת (בדגש על מחיקה חריגה), כל המועמדויות אליה מאבדות הקשר העסקי שלהן.
- נדרש לתמיכה בדוח “רשימת משרות פתוחות” + יכולת למדוד עומס/כמות מועמדויות לכל משרה.
ההשפעה על הדוחות:
- מאפשר Roll-Up Summary על Job:
- Count של (Application) מועמדויות
- פילוחים לפי שלב מועמדות (בדוחות דרך Summary/Grouping,ו- Roll-Up דרך שדות עזר אם נרצה בעתיד)
- הדוחות “משרות פתוחות + כמה מועמדויות” נהייה טבעי יותר.
משמעות למחיקה
- מחיקה מדורגת: מחיקת Job תמחק את כל ה־Applications (ואיתם גם Interviews/Assignments/Recommendations אם הם תלויים ב־Application).
- זה “חד” אבל עקבי לוגית.
- בפועל: ברוב הארגונים לא מוחקים משרות — משנים סטטוס ל“סגורה”.
משמעות לביצועים
- Roll-up native ב־Salesforce → יעיל מהיר "וזול" יחסית לפתרונות Flow.
האם אפשר לבחור אחרת ?
כן: Lookup מ- Application ל- Jobs
השלכות בחירה זו:
- אין Roll-Up native על Job (נדרש פתרון Flow כדי לספור מועמדויות).
- Application היה יכול “לחיות” בלי משרה (פחות הגיוני עסקית).
- שיתוף/בעלות לא יורשים אוטומטית מהמשרה.
קישור Application ⬅ Candidate (Lookup)
סיבת הבחירה:
- מועמד יכול להגיש מועמדויות למספר משרות.
- בחרתי Lookup (ולא Master-Detail) כדי:
- לא להחיל מחיקה אוטומטית של מועמדויות כשמוחקים מועמד (לא נכון עסקית).
- Lookup שומר על היסטוריית מועמדויות גם אם מועמד נמחק.
משמעות לדוחות
- מאפשר דוחות “מועמדים בתהליך/ממתינים להחלטה” על בסיס Application
- אין Roll-Up Summary על Candidate כי ( Lookup)
משמעות לביצועים
- גמישות גבוהה, פחות Cascade
האם אפשר היה לבחור אחרת?
כן: Master-Detail מ- Applications ל – Candidate
השלכות בחירה זו:
- היה Roll-Up native על Candidate + אכיפת “אין Application בלי Candidate” ברמת קשר
תובנה מקצועית
- אם חשובים KPI/ דשבורדים על Candidate בצורה קלאסית ⬅ Master-Detail
- אם חשוב “שימור היסטוריה גם אם מועמד נמחק/מנוקה” ⬅ Lookup
קישור Recommendation ⬅ Application (Master-Detail)
סיבת הבחירה:
- המלצה היא תיעוד בתוך מועמדות ספציפית. אין לה משמעות בלי Application
- מופיע במפורש במסמך: “קשר אב-בן”
משמעות לדוחות
- Roll-Up על Application:
- Count להמלצות
- מאפשר לבנות לוגיקה עתידית: “יש/אין המלצה” או מספר המלצות לפני החלטה.
משמעות למחיקה
- מחיקת Application תמחק את ההמלצות שלה ⬅ נכון לתהליך.
משמעות לביצועים
- מבנה היררכי עקבי ו Native relationship + roll-ups
האם היה אפשר לבחור אחרת ?
- Lookup – לא מומלץ כאן כי זה סותר דרישת “אב-בן” לפי המסמך, ויפגע בעקביות תהליך.
קישור Interview ⬅ Application (Master-Detail)
סיבת הבחירה
- לפי המסמךInterview הוא אירוע בתוך תהליך המועמדות (Application)
- במציאות אין ראיון בלי מועמדות ספציפית
משמעות לדוחות
- Roll-Up על Application:
- מספר ראיונות (ניתוח ראיונות כחלק מהתהליך)
- ממוצע התרשמות טכנולוגית/יחסי אנוש/מוטיבציה (בעתיד אם נייצג מספרית או באמצעות שדות עזר)
- מאפשר דשבורדים: “מועמדויות עם X ראיונות” או “ממתינות לראיון HR”.
ביצועים
- יעיל יותר מאוטומציות לספירה.
- אין "ראיון יתום", אכיפת שיוך
האם היה אפשר לבחור אחרת ?
- Lookup – יאפשר ראיון “יתום” בלי מועמדות, פחות נכון עסקית, וגם יפגע ב־RollUps
קישור Assignment ⬅ Application (Master-Detail)
סיבת הבחירה
- לפי המסמך Assignment נשלח “במסגרת המועמדות”
- הוא חלק מובנה בתהליך
משמעות לדוחות
- Roll-Up על Application:
- מספר מטלות
- ממוצע ציון מספרי
- סטטוס מטלות (נשלח/הושלם/נבדק)
משמעות למחיקה
- Application נמחק ⬅ מטלות נמחקות.
ביצועים
- מאפשר ביצוע של אוטומציה באופן אגרגטיבי (Flow aggregations)
- RollUps – טבעי (Native Rollups)
האם היה אפשר לבחור אחרת ?
- Lookup – פחות מתאים, יצריך אוטומציות לשמירת מדדים
- ויאפשר מטלות יתומות.
קישור Recommendation ⬅ Candidate (Lookup)
סיבת הבחירה
- לפי המסמך נוסף לצורך “קשר למועמד”
- מאפשר חיפוש ודוחות על המלצות לפי מועמד, בלי לסבך היררכיה
למה Lookup ולא Master-Detail ?
- האובייקט Recommendation כבר Detail של Application (Master-Detail).
לא נרצה להפוך אותה לעוד Detail של Candidate כי:
-
- זו “תלות כפולה” מיותרת (Recommendation כבר מגיעה ל־Candidate דרך Application).
- Lookup נותן לנו גמישות (למשל: אם בעתיד נרצה לשייך המלצה למועמד גם מחוץ למועמדות, או להעביר המלצה בין מועמדויות בצורה מבוקרת).
משמעות לדוחות
- מקל על דוחות שמתחילים מאובייקט Recommendation ומקובצים לפי Candidate.
- לא חובה טכנית (כי אפשר Report Type דרך Application→Candidate)
- שימושי מכיוון שמפחית מורכבות Report Types.
משמעות למחיקה
- אם Candidate נמחק, ה־Lookup יתאפס/יחסם לפי הגדרות (ולא יפיל את ההמלצה מיד),
אך בפועל Candidate לא אמור להימחק.
- ב- LookUp אין מחיקה מדורגת בניגוד ל־Master-Detail
האם היה אפשר לבחור אחרת ?
- לא לשים קשר ישיר או ליצור קשר בכלל ולהסתמך על Application→Candidate בלבד.זה אפשרי, נראה שפחות נוח לדוחות מסוימים.
קישור Interview ➡ User (Interviewer) (Lookup)
סיבת הבחירה
- המסמך מגדיר “User מראיין”
- User הוא סטנדרטי, ולכן Lookup הוא הבחירה הנכונה.
משמעות לדוחות
- דוחות: כמה ראיונות לכל מראיין, איכות התרשמות ממוצעת לפי מראיין, עומסים
משמעות למחיקה
- אם משתמש יוצא מהארגון/מנוטרל, הרשומה עדיין קיימת ,לרוב Salesforce לא “מוחק” משתמשים.
אלטרנטיבה ?
- Text field לשם המראיין — לא מומלץ (אין עקביות, אין דוחות לפי משתמש אמיתי).
תרשים ERD של הפרויקט
אפיון שדות אובייקט Candidates
| DateType | Filed Name | Filed LABEL |
|---|---|---|
| Text (80) | Name | Candidate Name |
| Long Text Area (32768) | Candidate_Notes__c | Candidate Notes |
| Picklist | Candidate_Status__c | Candidate Status |
| Picklist | City__c | City |
| Picklist | Candidate _Gender__c | Candidate Gender |
| Date | Consent_Date__c | Consent Date |
| Checkbox | Consent_to_Contact__c | Consent to Contact |
| Lookup (User) | CreatedById | Created By |
| Picklist | Current_Process_Step__c | Current Process Step |
| Picklist | Education_Level__c | Education Level |
| Email__c | ||
| Lookup (User) | LastModifiedById | Last Modified By |
| URL (255) | LinkedIn_URL__c | LinkedIn URL |
| Picklist | Main_Tech__c | Main Tech |
| Phone | Mobile_Phone__c | Mobile Phone |
| Lookup (User,Group) | OwnerId | Owner |
| Picklist | Source__c | Source |
| Number (2, 0) | Years_Of_Experience__c | Years Of Experience |
אפיון שדות אובייקט Jobs
| DateType | Filed Name | Filed LABEL |
|---|---|---|
| Date | Close_Date__c | Close Date |
| Lookup (User) | CreatedById | Created By |
| Long Text Area (32768) | Description__c | Description |
| Text(8) (External ID) | External_ID__c | External ID |
| Checkbox | Hybrid__c | Hybrid |
| Formula (Text) | Job_Flag__c | Job Flag |
| Formula (Text) | Job_Requirements1__c | Job Requirements |
| Text (80) | Name | Jobs Name |
| Lookup (User) | LastModifiedById | Last Modified By |
| Picklist | Management_Level__c | Management Level |
| Date | Open_Date__c | Open Date |
| Lookup (User,Group) | OwnerId | Owner |
| Checkbox | Requires_Degree__c | Requires Degree |
| Checkbox | Requires_Dev_Background__c | Requires Dev Background |
| Checkbox | Requires_Over_1_Year_Experience__c | Requires Over 1 Year Experience |
| Picklist | Salary_Range__c | Salary Range |
| Picklist | Status__c | Status |
| Formula (Text) | Job_requirements__c | דרישות התפקיד |
אפיון שדות אובייקט Application
| DateType | Filed Name | Filed LABEL |
|---|---|---|
| Auto Number | Name | Application Name |
| Picklist | Application_Process__c | Application Process |
| Lookup (Candidate) | Candidate__c | Candidate |
| Formula (Number) | Candidate_Score__c | Candidate Score |
| Picklist | Candidate_Source__c | Candidate Source |
| Lookup (User) | CreatedById | Created By |
| Picklist | Fit_Level__c | Fit Level |
| Long Text Area (32768) | General_Notes__c | General Notes |
| Checkbox | Has_Recommendation__c | Has Recommendation |
| Master-Detail (Jobs) | Jobs__c | Jobs |
| Lookup (User) | LastModifiedById | Last Modified By |
| Picklist | Motivation_Level__c | Motivation Level |
| Formula (Text) | Motivation_And_Flag__c | Motivation Level |
| Formula (Text) | Motivation_Level_Flag__c | Motivation Level Flag |
אפיון שדות אובייקט Interviews
| Data Type | API Name (Field Name) | Field Label |
|---|---|---|
| Master-Detail (Application) | Application__c | Application |
| Lookup (User) | CreatedById | Created By |
| Picklist | Interpersonal_Impression__c | Interpersonal Impression |
| Date | Interview_Date__c | Interview Date |
| Text Area (255) | Interview_Location__c | Interview Location |
| Auto Number | Name | Interview Name |
| Picklist | Interview_Type__c | Interview Type |
| Text (80) | Interviewer__c | Interviewer Name |
| Lookup (User) | LastModifiedById | Last Modified By |
| Picklist | Motivation_Impression__c | Motivation Impression |
| Picklist | Tech_Impression__c | Tech Impression |
אפיון שדות אובייקט Assignments
| Data Type | API Name (Field Name) | Field Label |
|---|---|---|
| Master-Detail (Application) | Application__c | Application |
| Auto Number | Name | Assignment Name |
| Lookup (User) | CreatedById | Created By |
| Long Text Area (32768) | General_Notes__c | General Notes |
| Lookup (User) | LastModifiedById | Last Modified By |
| Number (3, 0) | Score_Numeric__c | Score Numeric |
| Text (80) | Score_Text__c | Score Text |
| Picklist | Status__c | Status |
| Picklist | Type__c | Type |
אפיון שדות אובייקט Recommendations
| Data Type | API Name (Field Name) | Field Label |
|---|---|---|
| Master-Detail (Application) | Application__c | Application |
| Lookup (Candidate) | Candidate__c | Candidate |
| Long Text Area (32768) | Cons__c | Cons |
| Lookup (User) | CreatedById | Created By |
| Checkbox | Enforce_Candidate_Sync__c | Enforce Candidate Sync |
| Long Text Area (32768) | General_Notes__c | General Notes |
| Lookup (User) | LastModifiedById | Last Modified By |
| Long Text Area (32768) | Pros__c | Pros |
| Auto Number | Name | Recommendation Name |
| Recommender_Email__c | Recommender Email | |
| Text (80) | Recommender_Name__c | Recommender Name |
| Phone | Recommender_Phone__c | Recommender Phone |
כללים ואוטומציות (Flows)
TBD
ממשק משתמש (UI)
Pages ו-Layouts מותאמים.
WeJobs Recruiting ייעודית עם ניווט:
Candidates, Jobs, Candidates, Applications, Interviews, Recommendations, Assignments, Reports, Dashboards
הרשאות ואבטחת מידע
TBD
דוחות דשבורדים ותזמונים
תזמון לשליחת אנליזה
בדיקות (UAT)
TBD
הדרכה והטמעה
כתיבת תוכנית הדרכת למשתמשים.
- User Guide קצר (10–15 עמודים): ניווט, יצירת רשומות, עבודה עם הסטטוסים, דוחות.
- הדרכה למגייסים (60 דק'): תהליך End-to-End + תרגול.
- הדרכה למנהלים (45 דק'): דשבורד, KPI, והפקת דוחות.
Deliverables להגשה (CRM-Period)
| Deliverable | שם | היקף/תכולה |
|---|---|---|
| D-01 | מסמך אפיון (מסמך זה) | כולל AS-IS/TO-BE, Use Cases, Data Model, UI, Security, Testing |
| D-02 | Salesforce Org/Project | אובייקטים, שדות, קשרים, Flows, Validation Rules, Layouts, Pages |
| D-03 | Reports & Dashboard | לפחות 4 דוחות + דשבורד אחד עם 4–6 רכיבים |
| D-04 | UAT + הדרכה | טבלת תסריטי בדיקות + User Guide/מצגת קצרה |
| D-05 | מצגת (אופציונלי) | תסריט דמו: תהליך השמה מקצה לקצה |
סיכום
המערכת מספקת פתרון מלא, מדיד ואוטומטי לניהול תהליכי השמה,
יישום Salesforce לתהליכי השמה מאפשר שליטה מלאה במשפך הגיוס, סטטוסים אחידים, אוטומציה של משימות והתרעות, ושיפור משמעותי ביכולת הניהול והדיווח. השלב הבא (לאחר פרויקט הגמר) מומלץ להתמקד בהרחבת יכולות חיפוש/Matching, העשרת נתוני מועמדים, ושילוב אינטגרציות (למשל אימייל/Calendars).
Loading…
פרויקט סיום חלק ב'
21/03/2026
אין תגובות
פרויקט סיום חלק א'
תנאים מקדימים ייבוא נתונים:
- הסרת כפילויות
- בדיקת קיום השדות הרלוונטיים באובייקט (בדגש על שדות חובה)
- בדיקה שהקובץ נותן מענה לוולידציות באובייקטים
- התאמת ערכים בהתאם לערכי האובייקט
- התאמת תבנית תאריך למערכת
סה״כ מספר משרות פתוחות
הדוח המוצג בדשבורד מציג KPI מרכזי – מספר המשרות הפתוחות במערכת הגיוס של הארגון. ניתן לראות כי קיימות 21 משרות פתוחות.
הנתון מבוסס על אובייקט Job במערכת, שבו מנוהלות כלל המשרות בארגון.
הדוח מסנן את הרשומות כך שיוצגו רק משרות שהסטטוס שלהן הוא "Open", ובכך מספק תמונת מצב עדכנית של היקף הגיוס בחברה.
המידע מוצג כ-Metric / KPI Widget בדשבורד כדי לאפשר למנהלת משאבי האנוש לראות במהירות את היקף הגיוס הכולל מבלי להיכנס לדוחות מפורטים.
- יצרתי Report על אובייקט Job.
- הוגדר פילטר Status = Open
- בדוח בוצע חישוב Row Count (ספירת רשומות).
- הדוח הוסף לדשבורד כ-Metric Component המציג מספר יחיד גדול וברור.
כך מתקבל נתון מרכזי: כמה משרות פתוחות קיימות כרגע במערכת.
הצגת KPI מרכזי למנהלת הגיוס
לפי דרישות הפרויקט, אושרת צריכה לנהל משרות פתוחות ותהליך גיוס עובדים.
הצגת מספר המשרות הפתוחות מאפשרת לה להבין מיד:מה היקף הגיוס הנוכחי
האם נדרש להגדיל מאמצי גיוס
האם יש עומס בגיוס לעומת משאבי HR הקיימים
2. שימוש ב-Metric בדשבורד
בחרתי להציג את הנתון כ-Metric מכיוון ש:זהו מדד אחד מרכזי
המידע צריך להיות ברור במבט ראשון
אין צורך בפירוט או גרף
זו שיטת הצגה מקובלת בלוחות מחוונים ניהוליים.3. שימוש ב-Filter על Status
להציג רק משרות רלוונטיות לתהליך הגיוס
להוציא מהחישוב משרות סגורות או שהתקבלה החלטה לגביהן
כך מתקבל נתון מדויק עסקית.
הדוח מאפשר למנהלת משאבי האנוש:
- להבין את עומס הגיוס הנוכחי
- להחליט האם צריך להוסיף תקני גיוס
- לזהות האם יש יותר מדי משרות פתוחות לאורך זמן
- לעקוב אחרי התקדמות סגירת משרות
מועמדויות לפי שלב בתהליך
הדוח מציג ניתוח של מועמדויות לפי שלב בתהליך הגיוס באמצעות תרשים משפך (Funnel). התרשים מבוסס על אובייקט Application ומקבץ את הרשומות לפי השדה Application Process, כך שניתן לראות כמה מועמדים נמצאים בכל שלב בתהליך – החל מסינון קורות חיים ועד קבלת החלטה.
נדרש מסמך: פרויקט סיום – חלק א'
יצרתי דוח שמחשב את Record Count של מועמדויות ומקבץ אותן לפי שלבי התהליך,
מוצג בדשבורד כתרשים Funnel.
תרשים משפך מאפשר לזהות במהירות באיזה שלב בתהליך הגיוס מועמדים “נתקעים” או נושרים,
וכך מסייע למנהלת משאבי האנוש לייעל את התהליך ולקבל החלטות מבוססות נתונים לגבי שיפור שלבי הגיוס.
דוח מועמדים לפי מידת התאמה
הדוח מציג משרות עם מועמדים לפי מידת התאמה ומוטיבציה, ומטרתו לזהות מועמדים חזקים בתהליך הגיוס.
הדוח מבוסס על נתוני המועמדויות באובייקט Application, ומשלב מידע על המועמד,
המשרה והציון הכולל (Candidate Score) המחושב לפי מדדי התאמה ומוטיבציה.
נדרש במסמך: פרויקט סיום – חלק א'
לצורך קביעת מדדי ההתאמה והמוטיבציה הוספתי שדה מסוג Formula ובוא הגדרתי לכל סטטוס ערך:
שדה Fit Level -High = 3 | Medium = 2 | Low = 1 והכפלתי ב 10 לקבל תוצאה בעשרות (ראיה עתידית ל 100)
שדה Motivation Level -High = 3 | Medium = 2 | Low = 1 והשארתי ביחידות לדיוק גבוהה
להלן הנוסחה בשדה:
( CASE(TEXT( Fit_Level__c ), "High", 3, "Medium", 2, "Low", 1, 0) * 10)
+
CASE(TEXT(Motivation_Level__c), "High", 3, "Medium", 2, "Low", 1, 0)
בניית דוח המציג מועמדים שלא נדחו, הכולל את שם המועמד, המשרה אליה הגיש מועמדות ואת ציון ההתאמה הכולל. הנתונים ממוינים לפי Candidate Score ומודגשים באמצעות Conditional Formatting כדי לזהות במהירות מועמדים חזקים.
הצגת הנתונים בטבלה עם דירוג וצביעה מאפשרת למנהלת משאבי האנוש לאתר במהירות מועמדים
- בעלי התאמה גבוהה בצע ירוק
- התאמה בינונית בצבע כתום
- והתאמה נמוכה בצבע אדום,
מאפשר לקבל החלטות גיוס יעילות יותר ולהימנע מפספוס מועמדים איכותיים בתהליך.
נדרש: במסמך: פרויקט סיום משאבי אנוש ב'
דוח מקורות הגיוס והשוואה
הדוח מציג ניתוח של מקורות הגיוס של מועמדים והשוואה בין מספר המועמדויות לבין מספר המועמדים שהתקבלו לעבודה (Hired).
הנתונים מקובצים לפי השדה Candidate Source, וכך ניתן לראות אילו מקורות אמינים (איכותיים) מביאים יותר מועמדים ואילו מקורות מובילים בפועל לגיוס עובדים.
נדרש במסמך: פרויקט סיום משאבי אנוש ב
נבנה דוח על אובייקט Application שבו בוצעה קיבוץ לפי מקור המועמד, ונוספה השוואה בין Record Count של כל המועמדויות לבין Record Count של מועמדים שהתקבלו.
הדוח מוצג בדשבורד כתרשים עמודות להשוואה בין הנתונים.
הצגה השוואתית מאפשרת לזהות אילו מקורות גיוס הם היעילים ביותר, כלומר לא רק מביאים הרבה מועמדים אלא גם מובילים לגיוס בפועל.
מידע זה מסייע למנהלת משאבי האנוש לקבל החלטות מושכלות לגבי השקעה בערוצי גיוס אפקטיביים יותר בעתיד.
מקורות הגיוס לפי שלבי תהליך המועמדות
הדוח מציג ניתוח של מקורות הגיוס לפי שלבי תהליך המועמדות.
הנתונים מקובצים תחילה לפי
Candidate Source ולאחר מכן לפי Application Process, וכך ניתן לראות באיזה שלב בתהליך נמצאים המועמדים מכל מקור גיוס.
נבנה דוח על אובייקט Application, שבו בוצע Grouping כפול – תחילה לפי מקור המועמד ולאחר מכן לפי שלב בתהליך הגיוס, תוך הצגת Record Count לכל שלב.
מבנה הדוח מאפשר להבין לא רק מאיזה מקור מגיעים מועמדים, אלא גם
כיצד הם מתקדמים בתהליך הגיוס.
כך ניתן לזהות מקורות שמביאים מועמדים איכותיים שמתקדמים לשלבים מתקדמים, לעומת מקורות שבהם רוב המועמדים נפסלים בשלבים מוקדמים.
משרות עם הכי הרבה מועמדים איכותיים
בניית הדוח מבוססת על אובייקט Application המציג לכל משרה את מספר המועמדים האיכותיים שהגישו מועמדות.
הדוח מסנן מועמדים בעלי מידת התאמה גבוהה ומוטיבציה גבוהה, מקבץ אותם לפי משרה ומחשב את מספרם באמצעות Record Count.
מאחר שכל הערכת מועמד נשמרת באובייקט Application, זהו המקום המדויק ביותר לנתח את איכות המועמדים.
קיבוץ לפי משרה מאפשר לזהות במהירות אילו משרות מושכות מועמדים איכותיים יותר
דוח זה מסייע למנהלת הגיוס להבין היכן תהליך הגיוס יעיל יותר והיכן יש צורך בשיפור.
משרות עם הכי הרבה מועמדים איכותיים
לצורך הדוח הוספתי שדה מסוג Formula באובייקט Application שמודד כמה זמן בתהליך
עם הנוסחה:
TODAY() – DATEVALUE(CreatedDate)
יצירת שדה מסוג נוסחה באובייקט Application המחושב את מספר הימים שעברו מאז יצירת המועמדות.
באמצעות שדה זה נבנה דוח המסנן מועמדים שנמצאים בתהליך הגיוס מעל 14 יום ועדיין לא התקבלה לגביהם החלטה.
החישוב מאפשר לזהות מועמדים ש"נתקעו" בתהליך הגיוס ולחשוף צווארי בקבוק בשלבי המיון.
כך מנהלת משאבי האנוש יכולה לזהות במהירות מועמדים הדורשים טיפול או החלטה ולייעל את תהליך הגיוס.
פרויקט סיום חלק ג'
22/03/2026
אין תגובות
פרויקט סיום חלק א'
מענה לדרישה:
Master-Detail בין Application ל-Job + שדה עזר על Application + Roll-Up Summary על Job + שדה Formula/Checkbox להצגת הדגל.
לפי מסמכי הפרויקט Application הוא אובייקט שמקשר בין משרה למועמד, וכולל כבר את שדות התהליך, מידת המוטיבציה ומידת ההתאמה. בנוסף, הדרישה בחלק ג' היא רק להציג דגל אדום כאשר יש לפחות 3 מועמדים מתאימים שעברו את שלב הצעת השכר והמשרה עדיין פתוחה.
- יצירת Formula Checkbox על Application בשם: Qualified_For_Hot_Job
נוסחה:
AND (ISPICKVAL( Fit_Level__c , "High"), OR(ISPICKVAL(Application_Process__c, "Offer"),
ISPICKVAL(Application_Process__c, "Hired")))- יצירת Roll-Up Summary על Jobבשם: High_Fit_After_Salary_Offer_Count
סופר כמה Qualified_For_Hot_Job = True - יצירת Formula Checkbox על Jobבשם: Show_Red_Flag
נוסחה:
AND(ISPICKVAL(Status__c, "Open"), High_Fit_After_Salary_Offer_Count__c >= 3)
כך הדגל נקבע אוטומטית לפי מצב המשרה ומספר המועמדויות הרלוונטיות. הדרישה למסמך אכן קושרת בין מצב המשרה הפתוחה לבין 3 מועמדים או יותר ברמת התאמה גבוהה אחרי שלב הצעת השכר.
- יצירת שדה Formula Text על Job בשם: Red Flag Banner
נוסחה:
IF(Show_Red_Flag__c, "🔴 HOT JOB – 3+ high-fit candidates after salary offer", "" )
- יצירת Formula Checkbox על Application בשם: Qualified_For_Hot_Job
התנאי לחיווי משרה חמה : High_Fit_After_Salary_Offer_Count >= 3
התנאי לחיווי משרה חמה : High_Fit_After_Salary_Offer_Count >= 3
מענה לדרישה:
מבוסס על 3 שדות התרשמות שקיימים באובייקט המבוססים על ערכים Low, Medium, High:
- Tech Impression – התרשמות טכנולוגית
- Interpersonal Impression – התרשמות HR יחסי אנוש
- Motivation Impression – התרשמות מוטיבציה
יצירת שדה Interview Score מסוגFormula (Number,1) שמחשב את הציון הסופי
עדכון Compact Layout כדי שהציון יופיע בכותרת הרשומה
נוסחת השקלול המומלצת
אם שלושת הערכים הם 1–3, אז: ממוצע מינימלי = 1, ממוצע מקסימלי = 3
כדי להמיר ל־1–10 השתמשתי בנוסחה: ((Average−1)/2)∗9+1
כך: כל הציונים נמוכה → 1 | כל הציונים גבוהה → 10 | ערכים באמצע יקבלו ציון יחסי
גרסה יותר מקצועית עסקית, שבה לקריטריון Tech Impression יש משקל גבוה יותר, כי ברוב תהליכי הגיוס המקצועיים היכולת הטכנולוגית נחשבת קריטית יותר, אך עדיין נשמר איזון עם HR ו־Motivation.
נוסחה בשדה Interview Score
ROUND((((CASE(TEXT( Tech_Impression__c ),"Low", 1,"Medium", 2,"High", 3,1) * 0.5)
+
(CASE(TEXT( Interpersonal_Impression__c ),"Low", 1,"Medium", 2,"High", 3,1) * 0.25)
+
(CASE(TEXT( Motivation_Impression__c ),"Low", 1,"Medium", 2,"High", 3,1) * 0.25)) – 1) / 2 * 9 + 1, 1)
יצירת משרה חדשה
מענה לדרישה: יצירת Global Action
מענה לדרישה:
- הורדה והתקנת אפליקציה
- הוספת הקומפוננטה בדף המועמדות למשרה.
- הגדרת תנאי תצוגה ל- קומפוננטה
- וולידציה על מנת לאכוף את האפשרות להוספת חתימה תהיה זמינה אך ורק למועמדים שעברו את שלב הצעת השכר
- וולידציה על מנת לאכוף קבלה למשרה אם לא קיימת חתימה של המועמד
- בניית FLOW תומך לאישור ועדכון הרשומה
- התקנת תוסף Refresher ושפעול Apex – מרענן את הרשומה ללא צורך ב- F5
1) רק כאשר תנאי הוולידציה של השדה (Formula) Allow Signature יתקיימו
OR(ISPICKVAL(Application_Process__c, "Offer"),ISPICKVAL(Application_Process__c, "Accepted"))
2) סטטוס הפעולה – Offer
3) שדה שנתקבל חתימה מהמועמד: False = Candidate Signature Received
4) שדה המציג קישור לקובץ החתימה יופיע רק לאחר חתימה ו שדה
True = Candidate Signature Received
5) כותרת " 
החתימה התקבלה בהצלחה" תופיע רק לאחר חתימה ו שדה
True = Candidate Signature Received
6) הוספת: Record Refresher וכתיבת Apex (AppSignatureUpdate) שמבצע Refresh לרשומה במקום (F5)
הוספת שדות:
- שדה Candidate Signature Received מסוג: CheckBox לחיווי שתקבלה חתימה מהמועמד
- שדה: Candidate Signature Date מסוג: Date/Time – לתיעוד תאריך ושעת החתימה
וולידציות:
AND(ISPICKVAL( Application_Process__c , "Hired"),Candidate_Signature_Received__c = False)
וולידציה: הוספת חתימה תהיה זמינה אך ורק למועמדים שעברו את שלב הצעת השכר
מבוסס על לוגיקה של שדה Allow Signature מסוג: Formula CheckBox
OR(ISPICKVAL(Application_Process__c, "Offer"),ISPICKVAL(Application_Process__c, "Accepted"))
וולידציה חסימת שינוי לאחר קבלת חתימה
AND(PRIORVALUE(Candidate_Signature_Received__c) = TRUE, OR(ISCHANGED(Candidate_Signature_Received__c), ISCHANGED(Candidate_Signature_Date__c)))
הוספת שדות:
שדה Candidate Signature Received מסוג: CheckBox לחיווי שתקבלה חתימה מהמועמד
שדה: Candidate Signature Date מסוג: Date/Time – לתיעוד תאריך ושעת החתימה
כתיבת APEX לריענון הרשומה במקום F5
PushTopic pt = new PushTopic();
pt.Name = 'AppSignatureUpdate';
// חשוב: השדות והאובייקט מדויקים (ל Application__c)
pt.Query = 'SELECT Id, Name, Candidate_Signature_Received__c FROM Application__c';
pt.ApiVersion = 59.0;
// הגדרות שליחה
pt.NotifyForOperationUpdate = true; // רוצים עדכון
pt.NotifyForOperationCreate = true;
pt.NotifyForFields = 'Referenced'; // התרעה רק אם השדה בשאילתה השתנה
insert pt;
System.debug('PushTopic Created: ' + pt.Name);
אוטומציה (FLOW) לעדכון :
עדכון שדות:
- Candidate Signature Received
- Candidate Signature Date
תהליך ה- FLOW
טריגר אובייקט Application כשיש עדכון ברשומהבדיקת CheckBox – AllowSignature
Get Records – לאובייקט: Content Document Link אם הקובץ מקושר לרשומה
LinkedEntityId = {!$Record.Id}
Get Records – לאובייקט: Content Document (Beta) אם סיומת הקובץ png (זוהי סיומת הקובץ שהחתימה יוצרת)
תנאי (Decision) שכל (AND) התנאים מתקיימים
בדיקה שהקישור לרשומה (קיים) ולא ריק
{!GET_ContentDocumentLink.Id} Is Null False
בדיקה שסיומת הקובץ אכן png
{!Get_Content_Document.FileExtension} Equals png
בדיקה ששם הקובץ מתחיל ב Signature
{!Get_Content_Document.Title} Starts With Signature
Update Records
Candidate Signature Received = True
Candidate Signature Date = {!$Flow.CurrentDateTime}
תהליך ה- FLOW
טריגר אובייקט Application כשיש עדכון ברשומהבדיקת CheckBox – AllowSignature
Get Records – לאובייקט: Content Document Link אם הקובץ מקושר לרשומה
LinkedEntityId = {!$Record.Id}
Get Records – לאובייקט: Content Document (Beta) אם סיומת הקובץ png (זוהי סיומת הקובץ שהחתימה יוצרת)
תנאי (Decision) שכל (AND) התנאים מתקיימים
בדיקה שהקישור לרשומה (קיים) ולא ריק
{!GET_ContentDocumentLink.Id} Is Null False
בדיקה שסיומת הקובץ אכן png
{!Get_Content_Document.FileExtension} Equals png
בדיקה ששם הקובץ מתחיל ב Signature
{!Get_Content_Document.Title} Starts With Signature
Update Records
Candidate Signature Received = True
Candidate Signature Date = {!$Flow.CurrentDateTime}
מענה לדרישה:
האובייקט Assignment כולל קישור ל־Application, שדה Type מסוג Picklist, ושדה Status שבו אחת האפשרויות היא "נשלח" .
בנוסף, הדרישה כאן היא תהליך אוטומטי שמקל על המשתמש ביצירת כמה מטלות בית בבת אחת מתוך רשומת Application עצמה, ולכן הפתרון הנכון הוא Screen Flow שמופעל מכפתור/Action על רשומת המועמדות. זה מתאים לדרישה העסקית של בחירה ידנית של סוגי המטלות ואז יצירה אוטומטית של הרשומות.
השתמשתי ב-3 Checkbox נפרדים במסך:
chkDataAnalysis
chkTrailhead
chkExcel
כי כל אחד מהם מחזיר Boolean ברור: True / False
ואז אני בונה בעצמי Text Collection של סוגי המטלות שנבחרו, ועליו עושה Loop.
צעד 1 – יצירת Resources
1. recordIdText, input
2. txtSelectedTypesText Collection Variable
זה האוסף שעליו נעשה Loop.
3. varAssignmentRecord Variable של Assignment
4. colAssignments
Record Collection של Assignment
צעד 2 – Screen
מסך אחד עם 3 Checkbox:
- Data analysis
- Trailhead
- Excel
צעד 3 – הוספת Decision
בדיקה אם נבחר Data analysis אם כן בצע Assignment של הערך Data analysis
ל- Collection של הרשומות txtSelectTypes
צעד 4 – הוספת Decision
בדיקה אם נבחר Trailhead אם כן בצע Assignment של הערך Trailhead
ל- Collection של הרשומות txtSelectTypes
צעד 5 – הוספת Decision
בדיקה אם נבחר Excel אם כן בצע Assignment של הערך Excel
ל- Collection של הרשומות txtSelectedTypes
כך ה-Collection יכיל רק את הבחירות האמיתיות של המשתמש.
צעד 6 – הוספת Loop
דרך פעולה ה- Loop עובר על ה- Collection – שב- txtSelectedTypes, ובכל איטרציה מכניס את הערך למשתנה שהלולאה יוצרת: Current Item from LOOP_Assignment_Types, כך ה- Flow יוצר רשומה לכל סוג מטלה.
צעד 7 – הוספת Assignment בתוך הנתיב For each
כך יווצר אובייקט חדש להשמה (Assignment) לכל רשומה / איטרציה שהלולאה רצה
צעד 8 – הוספת Assignment
כדי הכניס את הרשומה שבנינו אל האוסף colAssignments
צעד 9 – Create Records
ליצירת הרשומות בפעולה אחת
צעד 10 – Display Screen
על מנת להציג למשתמש שהרשומות נוצרו בהצלחה !
מענה לדרישה:
הפתרון הנכון לדעתי הוא Record-Triggered Flow על אובייקט Assignment:
- יופעל After Save
- יופעל כאשר נוצרת מטלה בסטטוס נשלח
- יכיל 3 Scheduled Paths:
- אחרי 3 ימים → מייל תזכורת למועמד
- אחרי 7 ימים → מייל תזכורת לבעלי המשרה
- אחרי 14 ימים → אם עדיין "נשלח", שינוי סטטוס ל־"לא הושלמה"
זה הפתרון הנכון כי:
- הכול יושב על הרשומה שצריכה להימדד בזמן
- אין צורך בלולאות
- אין צורך ב־Scheduled Flow שרץ על כל המערכת
- כל מטלה מנהלת לעצמה את הלו"ז האוטומטי שלה
צעד 1 – הגדרת Start
Object – Assignment
Trigger the Flow When – A record is created
Condition Requirements – All Conditions Are Met (AND)
תנאי: Status__c Equals Sent
Optimize the Flow For – Actions and Related Records
כלומר: After Save
למה זו ההגדרה הנכונה
כי אנחנו רוצים:
- לשלוח מיילים
- לעדכן רשומה בעתיד
- להשתמש ב־Scheduled Paths
כל אלה דורשים After Save.
צעד 2 – יצירת 3 Scheduled Paths
After 7 Days, After 3 Days, After 14 Days
בכולם ההגדרה Assignment__c: Created Date
Days After
השוני היחידי הוא בהגדרת ה- Offset Number – בהתאמה ל PATH
צעד 3 – ענף של 3 ימים הוספת Decision
בדיקה שהסטטוס עדיין במצב Sent כיוון שייתכן כי בינתיים המטלה הושלמה וכשיגיע ה Scheduled Path יגיע בזמן שלו, ואנו לא רוצם לשלוח מייל מיותר.
צעד 4 – ענף של 3 ימים הוספת רכיב Action – Send Email, למועמד
שליחת מייל למועמד
הממוען: {!Candidate.Email)
נושא: תזכורת להשלמת מטלת הבית {Assignment.Type!}
גוף המייל: שלום {Candidate Name!},
זוהי תזכורת להשלמת מטלת הבית שנשלחה אליך לפני 3 ימים.
נשמח להשלמתה בהקדם.
צעד 5 – ענף של 7 ימים הוספת Decision
בדיקה שהסטטוס עדיין במצב Sent כיוון שייתכן כי בינתיים המטלה הושלמה וכשיגיע ה Scheduled Path יגיע בזמן שלו, ואנו לא רוצם לשלוח מייל מיותר.
צעד 6 – ענף של 7 ימים הוספת רכיב Action – Send Email לבעלים של המשרה (Job.Owner)
שליחת מייל למועמד
הממוען: {!Owner.Email)
נושא: מטלת הבית {Assignment.Type!} עדיין לא הושלמה
גוף המייל: שלום {Owner Name!},
מטלת הבית של המועמד (Candidate.Name) עדיין בסטטוס "נשלח" לאחר 7 ימים.
מומלץ לבדוק האם נדרש מעקב מול המועמד.
צעד 7 – ענף של 14 ימים הוספת Decision
בדיקה שהסטטוס עדיין במצב Sent
לאחריו Update Record
וביצוע עדכון לרשומה ל-
Status= Not Completed
הפתרון שלי מבוסס על:
תהליך אוטומטי על מועמדות למשרה (Application):
כאשר מועמד התקבל למשרה, צריך:
- לשנות את סטטוס המשרה ל-סגורה
- לשלוח מייל למועמד שהתקבל
- לכל שאר המועמדויות של אותה משרה שלא התקבלו, לשנות סטטוס ל-נדחה
- ליצור Task כדי ליצור קשר עם אותם מועמדים ולעדכן אותם טלפונית
למה הפתרון הנכון כאן הוא Flow על Application
לפי מודל הנתונים בפרויקט:
- המשרה מנוהלת באובייקט Job
- המועמדות מנוהלת באובייקט Application
- ה-Application הוא זה שמחבר בין מועמד למשרה, וגם בו נשמר שלב התהליך/ההחלטה
לכן, האירוע שמפעיל את האוטומציה צריך להיות:
כאשר Application משנה סטטוס ל-"התקבל".
זה עדיף על Flow על Job, כי ההחלטה על קבלה מתקבלת ברמת המועמדות, לא ברמת המשרה
פלואו Record-Triggered Flow על האובייקט Application:
הטריגר
כאשר רשומת מועמדות מתעדכנת ו-Application Process = Hired
מה ה-Flow יעשה
- יעדכן את המשרה המקושרת ל-Closed
- ישלח מייל למועמד שהתקבל
- ישלוף את כל שאר המועמדויות של אותה משרה
- יעדכן אותן ל-Rejected
- ייצור Task לכל אחת מהן
שלב 1 — יצירת Flow חדש
הגדרות טריגר
Trigger the Flow When: A record is updated
Condition Requirements:
Application Process Equals Hired
When to Run the Flow for Updated Records:
Only when a record is updated to meet the condition requirements
Optimize the Flow for:
Actions and Related Records
הסיבות לבחירה הנ"ל
כי אנחנו גם:
- מעדכנים רשומות קשורות
- יוצרים Tasks
- שולחים מייל
כל אלה מחייבים After Save Flow.
שלב 2 — הוספת Get Records למשרה של המועמדות
הבאתה המשרה כ-Get Records.
זה נותן Flow יציב וברור יותר, וגם מקל על המשך הבנייה.
מה עושים
הוסף אלמנט: Get Records
Object Job
Filter : Id Equals {!$Record.Job__c}
בהמשך אשתמש:
- לעדכן את סטטוס המשרה
- להשתמש בשם המשרה במייל
שלב 3 — עדכון המשרה Closed"
הוסף אלמנט: Update Records
How to Find Records to Update
Use the IDs and all field values from a record or record collection
Record: {!Get_Related_Job}
Set Field Values: Status = Closed
על פי הדרישה אומרת במפורש:
אם מועמד התקבל למשרה — סטטוס המשרה צריך להשתנות לסגורה
שלב 4 — יצירת תבניות טקסט למייל הזכייה
כדי שהמייל ייראה טוב ומקצועי, השתמשתי ב-Text Template.
ב-Manager > New Resource > Text Template
Subject API/Label: TT_Accepted_Subject
תוכן:
התקבלת למשרה {!Get_Related_Job.Name}
Body API/Label: TT_Accepted_Body
שלום {!$Record.Candidate__r.Name},בשמחה רבה אנו מודיעים לך שהתקבלת למשרה {!Get_Related_Job.Name}.
פרטי המשרה:
שם המשרה: {!Get_Related_Job.Name}
תיאור: {!Get_Related_Job.Description__c}
טווח שכר: {!Get_Related_Job.Salary_Range__c}
מאחלים לך הצלחה רבה בהמשך הדרך!
בברכה,
צוות הגיוס
Get Records שלב 5 – הוספת
Get Records :הוספת
Object Candidate
Filter: Id Equals {!$Record.Candidate__c}
שלב 6 — שליחת המייל למועמד שהתקבל
הוסף אלמנט: Action
>Send Email
Configuration:
Recipient Address List = Get_Candidate.Email__c
Subject = TT_Accepted_Subject
Body = TT_Accepted_Body
שלב 7 — שליפת כל שאר המועמדויות של אותה משרה
הוסף: Get Records
Object Application
Filters
- Job__c Equals {!$Record.Job__c}
- Id Not Equals {!$Record.Id}
- Application_Process__c Not Equals Rejected
שלב 8 — יצירת משתנים Collection לעדכונים ולמשימות
Record Collection Variable עבור Applications
- Resource Type: Variable
- API Name: varApplicationsToReject
- Data Type: Record
- Object: Application
- Allow multiple values: Checked
Record Collection Variable עבור Tasks
- Resource Type: Variable
- API Name: varTasksToCreate
- Data Type: Record
- Object: Task
- Allow multiple values: Checked
שלב 9 – לולאה על שאר המועמדויות
הוסף: Loop
Collection Variable
Get Other Applications
שלב 10 — בתוך הלולאה: הכנת המועמדות לעדכון ל"Rejected"
בתוך הלולאה nבצע שתי פעולות:
- הכנת רשומת ה-Application לעדכון
- הכנת Task
10.1 Assignment לעדכון ה-Application
הוסף Assignment
פעולות
על ה-Current Item from Loop:
- Application_Process__c = Rejected
ואז:
- Add Current Item to varApplicationsToReject
שלב 11 — בתוך הלולאה: הכנת Task
יצירת משתנה נוסף:
Variable
- API Name: varSingleTask
- Data Type: Record
- Object: Task
- Available for multiple values: לא מסומן
אחר הוספת Assignment
שדות ל-Task
- Subject = ליצור קשר עם מועמד שלא התקבל
- Status = Not Started
- Priority = Normal
- WhatId = {!Loop_Other_Applications.Id}
אם המערכת מאפשרת לקשר ל-Application - OwnerId = {!Loop_Other_Applications.OwnerId}
זה הפתרון הכי בטוח בפרויקט כזה - Description = ליצור קשר עם המועמד ולעדכן כי המשרה אוישה על ידי מועמד אחר.
אחר כך:
- Add varSingleTask to varTasksToCreate
שלב 12 — אחרי הלולאה: עדכון מרוכז של כל המועמדויות
הוספת: Update Records
Record or Record Collection varApplicationsToReject
כך כל שאר המועמדויות של אותה משרה יעברו ל-Rejected.
שלב 13 — אחרי הלולאה: יצירת כל המשימות
הוסף: Create Records
How Many Records to Create
Multiple
Record Collection
varTasksToCreate
כדי לייצר משימה לכל מועמד שלא התקבל
סדר האלמנטים המלא ב-Flow
כך ה-Flow צריך להיראות:
Start
→ Get Related Job
→ Get Candidate (אם צריך)
→ Close Job
→ Send Acceptance Email
→ Get Other Applications
→ Loop Other Applications
→ Prepare Rejected Application
→ Prepare Rejection Task
→ חזרה ללולאה
→ Reject Other Applications
→ Create Follow Up Tasks
למה זה פתרון טוב גם עסקית וגם טכנית
- טריגר נכון — ההחלטה מתקבלת ברמת Application
- סגירת Job אוטומטית — מונעת המשך טיפול מיותר במשרה
- מייל למועמד שהתקבל — משרת חוויית מועמד
- דחייה אוטומטית לאחרים — שומרת על דאטה נקי
- Task למעקב אישי — עונה בדיוק לדרישה של פנייה אישית למועמדים שלא התקבלו
- Bulk-safe — בגלל שימוש ב-collections במקום פעולות DML בתוך הלולאה