WEBVTT 00:00:04.020 --> 00:00:10.940 ברוכים הבאים לפינות הידע של מייקרוסופט. אני מרקו פיטרז. נושא היום הוא נושא שלעיתים קרובות מבלבל אנשים. 00:00:11.180 --> 00:00:18.200 מה זה בעצם דייטא ורס? האם זה בסיס נתונים, אפליקציה או שירות דיינמיקס 365 נסתר שרק אנשי אית צריכים להבין? 00:00:18.200 --> 00:00:27.120 הנה ההגדרה הפשוטה ביותר. דייטא ורס הוא תשתית הנתונים המשותפת שעומדת מאחורי חוויות רבות בדיינמיקס 365. חישבו על דיינמיקס 365 כעל בניין משרדים. 00:00:27.120 --> 00:00:34.220 מחירות, שירות לקוחות ואפליקציות אחרות הם החדרים שבהם אנשים עובדים. בעוד דייטא ורס הוא מערכת התיקייה והכללים שמאחורי הקירות. 00:00:34.380 --> 00:00:41.300 עד סוף הפרק הזה תדעו היכן הנתונים של דיינמיקס חיים וכיצד עדכון לקוח אחד יכול להופיע בעבודת מחירות באוטומציה ובדיווח. 00:00:41.300 --> 00:00:45.680 אבל לפני שנצלול לשמות של מוצרים, בואו נתחיל בבלגן העסקי שזה פותר. 00:00:46.180 --> 00:00:52.820 מקום אחד משותף. במקום עותקים נפרדים. דמיינו חברה עם צוות מחירות, צוות תמיכה וצוות כספים. 00:00:52.820 --> 00:00:57.840 צוות המחירות שומר פרטי לקוחות בגיליון אלקטרוני. צוות התמיכה עובד בכלי טיפול בפניות נפרד. 00:00:57.960 --> 00:01:05.920 לצוות הכספים יש שמות לקוחות במערכת משלו. מי שהוא אחר שומר שרשורי אימייל בתיבת דואר משותפת, בזמן שאדם אחר שומר הערות בתיקייה שאף אחד אחר לא יכול למצוא. 00:01:05.920 --> 00:01:12.440 אותו לקוח קיים עכשיו בחמישה מקומות. המבנה הזה מרגיש נורמלי בהתחלה כי כל צוות רואה רק את החלק של העבודה שנמצא מולו. 00:01:12.440 --> 00:01:18.140 אבל הנה העניין, ברגע שלקוח משנה את מספר הטלפון, הכתובת, שם החברה או איש הקשר הראשי שלו, הבעיות מתחילות. 00:01:18.240 --> 00:01:22.820 המחירות מעדכנים את הגיליון, התמיכה לא רואה זאת, הכספים עדיין שולחים מסמכים לכתובת הישנה. 00:01:22.820 --> 00:01:29.200 ואז מי שהוא מייצר רשימה, מנקה אותה ידנית, שולח אותה במייל ופתאום שלושה אנשים מאמינים כל אחד שהעותק שלו הוא הנכון. 00:01:29.340 --> 00:01:33.420 באיזו רשימה כדאי לבטוח? השאלה הזו מבזבזת יותר זמן ממה שאתם עשויים לחשוב. 00:01:33.580 --> 00:01:35.220 הצוות עוצר כדי להשוות רשומות. 00:01:35.400 --> 00:01:37.980 מנהלים שואלים למה דוח לא תואם למערכת המחירות. 00:01:38.160 --> 00:01:42.720 נציג תמיכה פותח פנייה עבור לקוח שהפרטים שלו כבר נמצאים במקום אחר, רק מעט שונים. 00:01:42.720 --> 00:01:44.400 אף אחד לא מנסה ליצור בלגן. 00:01:44.560 --> 00:01:45.860 הבלגן מגיע מאותקים. 00:01:46.020 --> 00:01:51.280 לפני עשרים שנה, מערכות נפרדות פירושן הישרתים נפרדים, בסיסי נתונים נפרדים וצוותים נפרדים ששומרים מידע משלהם. 00:01:51.280 --> 00:01:55.040 חיבור ביניהם דרש עבודה מותאמת אישית, עיבו מתוזמן והרבה בדיקות ידניות. 00:01:55.280 --> 00:01:59.240 שינוי במקום אחד עשוי להגיע למערכת אחרת מחר, בשבוע הבא או לעולם לא. 00:01:59.240 --> 00:02:02.900 דייטוורס מעניק לאפליקציות עסקיות מקום משותף לסוג זה של מידע. 00:02:03.020 --> 00:02:07.500 במילים פשוטות, דייטוורס הוא פלטפורמת נתוני הענן של מייקרוסופט למידע עסקי. 00:02:07.500 --> 00:02:15.680 הוא מאחסן את המידע הזה בטבלאות מובנות, כך שלנתונים יש צורה ברורה במקום לחיות כהערות אקראיות, קבצים רופפים וחרטיסיות גיליון אלקטרוני מנותקות. 00:02:15.680 --> 00:02:20.620 אפשר לחשוב על זה כערון הטיוק של החברה, אבל כזה שמספר כלים מאושרים יכולים להשתמש בו בו זמני. 00:02:20.740 --> 00:02:22.640 לקוח מופיע פעם אחת בדטוורס. 00:02:22.780 --> 00:02:27.180 אותו לקוח יכול להופיע בדיינמיקס 365 סיילס כשאיש מחירות עובד על עסקה. 00:02:27.180 --> 00:02:32.920 אותם פרטי לקוח יכולים להופיע בדיינמיקס 365 קסטומר סרוויס כשנציג מטפל בבקשת תמיכה. 00:02:32.920 --> 00:02:39.500 אפליקציית פאוור אפ יכולה להשתמש באותו מידע לקוח עבור עובד שטח או מנהל לקוח, בלי שמישהו יעתיק את הנתונים לאפליקציה חדשה קודם. 00:02:39.640 --> 00:02:42.340 שורת לקוח אחת, נקודת ייחוס משותפת אחת. 00:02:42.500 --> 00:02:44.480 זה לא אומר שכל צוות פתאום רואה הכל. 00:02:44.640 --> 00:02:47.260 עדיין צריך כללים לגישה, ונגיע לזה בקרוב. 00:02:47.260 --> 00:02:52.540 זה אומר שהאפליקציות מאושרות יכולות לעבוד מתוך אותו מידע עסקי במקום לבנות גרסה מתחרה משלהן. 00:02:52.540 --> 00:02:56.520 זו הסיבה שדיינמיקס 365 ודטאברס משתלבים יחד בצורה כל כך טבעית. 00:02:56.660 --> 00:03:02.020 אפליקציות דיינמיקס 365 כמו סיילס וקוסטומר סארוויס משתמשות בדטאברס כדי להכסן ולהבטח את הנתונים שעליהם הן עובדות. 00:03:02.160 --> 00:03:06.580 אבל הנה העניין, כשמישהו מדבר על אינטגרציה של דיינמיקס 365 עם דטאברס, 00:03:06.580 --> 00:03:09.240 ולרוב מדמיין שני מוצרים נפרדים שזקוקים למחבר ביניהם. 00:03:09.360 --> 00:03:12.600 עבור אפליקציות דיינמיקס 365 רבות, זה לא המצב. 00:03:12.720 --> 00:03:14.500 הנתונים כבר נמצאים בדטאברס. 00:03:14.500 --> 00:03:21.100 אתם לא מושכים רשימת לקוחות מדיינמיקס 365, מעתיקים אותה למסעד נתונים אחר ומקווים ששני הצדדים יישארו מעודכנים. 00:03:21.280 --> 00:03:26.600 אתם יכולים לבנות על אותו בסיס תוך שימוש באותו מידע עסקי שדיינמיקס 365 כבר משתמש בו. 00:03:26.760 --> 00:03:27.840 זה משנה את השיחה. 00:03:27.840 --> 00:03:36.720 במקום לשאול איך אנחנו מסנקרנים את שתי רשימות הלקוחות האלה, אפשר לשאול אילו אנשים ואפליקציות צריכים לעבוד עם רשומת הלקוח הזו ומה מותר לכל אחד מהם לעשות. 00:03:36.720 --> 00:03:40.060 עכשיו, דייטאברס לא מחליף כל מערכת שבבעלות החברה. 00:03:40.160 --> 00:03:47.360 עסק עשוי עדיין להשתמש בתוכנה פיננסית, כלי תעשייה, מערכות מחסן, אתרי אינטרנט או אפליקציות ישנות שמחזיקות נתונים משלהן. 00:03:47.520 --> 00:03:51.040 דייטאברס הוא לא דבק קסם שמסיר כל מערכת חיצונית בין לילה. 00:03:51.040 --> 00:04:00.020 מה שהוא נותן לכם זה מקום משותף לנתונים העסקיים שאפליקציות מקושרות צריכות לחלוק, פרטי לקוח, עבודת מחירות, עבודת תמיכה, משימות ומעקבים. 00:04:00.020 --> 00:04:04.180 הרשומות האלה יכולות לחיות יחד עם מקור אחד שכלים מאושרים יכולים לקרואו ליד כן. 00:04:04.340 --> 00:04:06.200 אז, פיתחו איתי את ארון הטיוק הזה. 00:04:06.360 --> 00:04:13.140 ברגע שתראו איך דייטאברס מארגן את המידע בפנים, כל החיבור של דיינמיקס 365 הופך להרבה יותר קל להבנה. 00:04:13.460 --> 00:04:16.760 ארון הטיוק, טבלאות, שורות, עמודות וקשרים. 00:04:16.980 --> 00:04:18.540 בואו נפתח את ארון הטיוק הזה. 00:04:18.720 --> 00:04:20.780 בתוך דייטאברס המידע יושב בטבלאות. 00:04:20.960 --> 00:04:23.220 חישבו על זה כמו ארון אמיתי עם מגירות נפרדות. 00:04:23.380 --> 00:04:27.800 העוץ, מגירה אחת מכילה חברות, אחרת מכילה אנשים ושלישית מכילה בקשות תמיכה. 00:04:27.800 --> 00:04:31.980 אתם לא זורקים כל נייר למגירה אחת ענקית ומקווים שמישהו יצליח למיין את זה אחר כך. 00:04:32.100 --> 00:04:33.360 לכל מגירה יש תפקיד. 00:04:33.500 --> 00:04:36.000 אז בדייטאברס, טבלה מחזיקה סוג אחד של מידע עסקי. 00:04:36.000 --> 00:04:38.580 טבלת חשבונות מכילה בדרך כלל חברות שאתם עובדים איתן. 00:04:38.720 --> 00:04:40.720 טבלת אנשי קשר מחזיקה אנשים פרטיים. 00:04:40.900 --> 00:04:44.240 טבלת לידים מחזיקה לקוחות פוטנציאליים לפני שהם הופכים ללקוחות אמיתיים. 00:04:44.400 --> 00:04:46.260 טבלת מקרים מחזיקה בקשות תמיכה. 00:04:46.260 --> 00:04:50.680 בעוד טבלת פעילויות עוקבת אחר עבודה כמו שיחות, אימיילים, פגישות ומשימות. 00:04:50.760 --> 00:04:52.140 אלו הן טבלעות סטנדרטיות. 00:04:52.300 --> 00:04:56.800 מייקרוסופט כוללת אותן כי רוב העסקים צריכים לעקוב אחר לקוחות, אנשים, עבודה ושיחות. 00:04:56.800 --> 00:05:01.180 אין צורך להתחיל בהמצאת טבלה חדשה למה שהוא נפוץ כשכבר יש טבלה סטנדרטית שמתאימה לתפקיד. 00:05:01.300 --> 00:05:03.580 אבל לכל חברה יש גם את העבודה הייחודית לה. 00:05:03.720 --> 00:05:06.580 חברת הדרכה עשויה להזדקק למעקב אחר קורסים ותעודות. 00:05:06.580 --> 00:05:09.700 עסק נדלן עשוי להזדקק למבנים, יחידות ובדיקות. 00:05:09.880 --> 00:05:12.660 יצרה נשוי לעקוב אחר בדיקות ציוד או ביקורי שירות. 00:05:12.840 --> 00:05:17.420 במקרים אלו, תוכלו ליצור טבלעות מותאמות אישית שמתאימות לעבודה שהחברה שלכם באמת עושה. 00:05:17.420 --> 00:05:21.620 חישבו על טבלה מותאמת אישית כעל הוספת מגירה חדשה לארון ואז מתן תווית ברורה לה. 00:05:21.740 --> 00:05:23.400 כעת, כל טבלה מכילה שורות. 00:05:23.620 --> 00:05:25.480 שורה היא פריט אחד בתוך אותה מגירה. 00:05:25.480 --> 00:05:30.640 למשל, שורה אחת בטבלת אנשי הקשר יכולה לייצג את מריה גומז, אדם בחברת לקוח. 00:05:30.800 --> 00:05:34.580 השורה שלה מחזיקה את הפרטים שלה בנפרד מכל איש קשר אחר במערכת. 00:05:34.700 --> 00:05:37.460 עמודות מתארות את הפרטים שברצונכם לשמור עבור כל שורה. 00:05:37.460 --> 00:05:44.760 שורת איש הקשר של מריה עשויה לכלול עמודות לשם פרטי, שם משפחה, כתובת אימייל, מספר טלפון, תפקיד, חברה, בעל הרשומה וסטטוס. 00:05:44.760 --> 00:05:52.300 עמודה מגדירה את סוג המידע ששייך לאותו מקום, כך שעמודת אימייל מצפה לכתובת אימייל, ועמודת סטטוס יכולה להחזיק אפשרויות סטטוס מאושרות. 00:05:52.400 --> 00:05:54.540 כך המידע העסקי מקבל מבנה אמין. 00:05:54.540 --> 00:06:02.400 ללא עמודות, אדם אחד עלול להקליד מספר טלפון בתיבת הערות, אחר עשוי להוסיף אותו לסדה שם, ומישהו אחר עלול לא להזין אותו כלל. 00:06:02.540 --> 00:06:06.580 עם טבלת אנשי קשר ברורה, כולם עובדים עם אותה מערכת פרטים באותה מקומות. 00:06:06.720 --> 00:06:09.380 המבנה הזה גם עוזר לאפליקציות להבין את הנתונים. 00:06:09.560 --> 00:06:15.720 טופס יכול להציג את הטבות הנכונות, דוח יכול לקבץ אנשי קשר לפי סטטוס, ואוטומציה יכולה להגיב כשבעלים משתנה. 00:06:15.860 --> 00:06:20.180 המידע לא רק מאוכסן, יש לו טביות שאומרות לחלים מחוברים מה כל חלק אומר. 00:06:20.180 --> 00:06:24.000 התחילו עם טבלעות סטנדרטיות בכל פעם שהן מתאימות לצורך העסקי שלכם. 00:06:24.100 --> 00:06:28.460 אם אתם מוכרים לחברות, חשבונות ואנשי קשר כבר מתארים דפוס שרוב האנשים מבינים. 00:06:28.620 --> 00:06:31.880 אם אתם מטפלים בתמיכת לקוחות, מקרים נותנים לכם נקודת התחלה. 00:06:32.020 --> 00:06:37.060 לאחר מכן, הוסיפו טבלעות מותאמות אישית רק במקום שבו לעסק שלכם יש מידע שלא מתאים לדפוסים המובנים. 00:06:37.220 --> 00:06:41.320 זה מונע בעיה נפוצה, יצירת חמש טבלעות שונות שכולן מייצגות לקוח. 00:06:41.320 --> 00:06:46.680 צוות אחד קורא לזה לקוח, אחר קורא לזה אב טיפוס של לקוח, ושלישי קורא לזה איש קשר של שותף. 00:06:46.800 --> 00:06:49.500 מהר מאוד, אנשים לא יודעים באיזו טבלה עליהם להשתמש. 00:06:49.660 --> 00:06:54.860 טבלעות סטנדרטיות ברורות וטבלעות מותאמות אישית בעלות שמות קפדניים שומרות על הארון מובן ככל שיותר אנשים בונים עליו. 00:06:54.960 --> 00:06:57.880 החלק הבא הוא המקום שבו המגירות האלה מתחילות לעבוד יחד. 00:06:57.980 --> 00:06:59.440 איש קשר שייך לחשבון. 00:06:59.560 --> 00:07:01.480 מריה עובדת עבור קונטוסו בעם. 00:07:01.480 --> 00:07:09.280 במקום להקליד שוב את הכתובת, מספר הטלפון הראשי ופרטי החברה של קונטוסו בשורה של מריה, דייטא ורס יכול ליצור קשר בין טבלת אנשי הקשר לטבלת החשבונות. 00:07:09.380 --> 00:07:13.640 מריה מקושרת לקונטוסו, והקישור הזה חשוב כי מידע החברה נשאר עם החברה. 00:07:13.740 --> 00:07:21.280 אם קונטוסו משנה את כתובת המשרד, מי שהוא מעדכן את שורת החשבון פעם אחת, וכל איש קשר קשור עדיין יכול להצביע על אותה חברה מבלי לשאת עותק ישן משלו. 00:07:21.280 --> 00:07:24.340 קשרים גם מחברים מקרה תמיכה ללקוח שהאלה אותו. 00:07:24.340 --> 00:07:29.500 הם יכולים לחבר הזדמנות מחירה לשיחות, אימיילים, פגישות ומשימות סביב העסקה הזו. 00:07:29.600 --> 00:07:36.280 כאשר איש מחירות פותח הזדמנות, הוא יכול לראות את הפעילות הקשורה אליה, במקום לחפש ביומנים ובהערות לא קשורים. 00:07:36.440 --> 00:07:37.600 למידע יש הקשר. 00:07:37.800 --> 00:07:41.580 אתה לא רק מסתכל על מספר מקרה, אתה רואה לאיזה לקוח הוא שייך. 00:07:41.740 --> 00:07:45.900 אתה לא רק צופה באיש קשר, אתה יכול לראות את החברה המחוברת לאותו אדם. 00:07:45.900 --> 00:07:50.740 הקישורים האלה שומרים על הנתונים שימושיים מבלי להקליד שוב ושוב את אותן עובדות במספר מקומות. 00:07:50.740 --> 00:07:54.300 הערת שמות קטנה לפני שתקרא מדריכים ישנים או תצפה בסרטונים ישנים. 00:07:54.500 --> 00:07:57.500 ייתכן שתשמע את המילים ישות, entity, שדה, field ורשומה, record. 00:07:57.660 --> 00:07:59.080 אלו מונחי Dataverse ישנים. 00:07:59.280 --> 00:08:04.380 מייקרוסופט משתמשת כעת בטבלה, במקום, ישות עמודה, במקום, שדה ושורה, במקום, רשומה. 00:08:04.500 --> 00:08:05.780 המשמעות לא השתנתה. 00:08:06.320 --> 00:08:12.920 מדריך ישן שאומר לך ליצור ישות מדבר למעשה על יצירת טבלה, שדה הוא עמודה ורשומה היא שורה. 00:08:12.920 --> 00:08:17.280 הכרת שתי קבוצות המילים חוסכת ממך את המחשבה שמצאת המוצר אחר. 00:08:20.740 --> 00:08:27.240 ארון מאורגן היטב עדיין זקוק לבקרות, מי שהוא חייב להחליט מה האנשים יכולים להזין, לשנות ולגשת אליו בבטחה. 00:08:27.360 --> 00:08:28.760 הכללים ודלפק הקבלה. 00:08:28.960 --> 00:08:33.280 מאחורי הקלעים, הנתונים בדטאברס עובדים רק כשהאנשים הנכונים יכולים לעבוד איתם בבטחה. 00:08:33.400 --> 00:08:41.460 איש מחירות צריך פרטי לקוח, סוכן תמיכה צריך היסטוריית מקרים, מנהל צריך מבט רחב יותר, ושותף חיצוני עשוי להזדקק לגישה רק לחלק קטן מהתהליך. 00:08:41.460 --> 00:08:43.460 הם לא אמורים לראות כולם את אותו מידע. 00:08:43.460 --> 00:08:48.500 חשוב על רשומת לקוח עם הערת קשר פרטית, מחיר מוסכם ומקרה תמיכה פתוח. 00:08:48.700 --> 00:08:51.480 מתן גישה מלאה לכל משתמש ייצור סיכון במהירות. 00:08:51.660 --> 00:08:55.300 הגבלת כולם בצורה הדוקה מדי עד שלא יוכלו לבצע את עבודתם יוצרת בעיה אחרת. 00:08:55.460 --> 00:08:57.380 דייטאברס מעניקה לך בקרות למצבים אלו. 00:08:57.500 --> 00:08:59.240 והבקרה הראשונה מתחילה בזהות. 00:08:59.420 --> 00:09:03.260 כשאתה מתחבר עם חשבון החברה שלך, מייקרוסופט אינטרה איי די מזהה אותך. 00:09:03.260 --> 00:09:06.340 תחשוב על אינטרה איי די כעל דלפק הקבלה בכניסה למשרד. 00:09:06.460 --> 00:09:10.300 אתה מגיע, מציג את התג שלך, והפקיד בודק מי אתה לפני שתוכל להיכנס. 00:09:10.480 --> 00:09:13.840 דייטאברס משתמשת בזהות הזו כדי לדעת איזה משתמש עובד עם הנתונים. 00:09:14.040 --> 00:09:16.600 היא לא עוצרת בשאלה האם מותר לאדם הזה להיכנס. 00:09:16.760 --> 00:09:19.820 היא גם שואלת מה מותר לאדם הזה לעשות לאחר שהיכנס. 00:09:19.980 --> 00:09:21.980 כאן נכנסים לתמונה תפקידי הבטחה. 00:09:22.120 --> 00:09:25.860 תפקיד הבטחה הוא קבוצה של הרשאות המקושרות לתפקיד או לאחריות. 00:09:25.860 --> 00:09:30.560 תוכל ליצור תפקיד אחד לצוות מחירות, אחר לנציגי שירות לקוחות, ואחר למנהלים. 00:09:30.720 --> 00:09:32.640 כל תפקיד יכול לשלוט בגישה לטבלה. 00:09:32.780 --> 00:09:38.040 למשל, נציג מחירות עשוי לקבל הרשאה לקרוא, ליצור ולהדכן חשבונות, אנשי קשר, לידים והזדמנויות. 00:09:38.180 --> 00:09:40.760 ייתכן שלא יורשה לו למחוק מידע חשוב של לקוחות. 00:09:40.920 --> 00:09:44.780 נציג תמיכה עשוי ליצור ולהדכן פניות, אך לא לשנות הזדמנות מחירה. 00:09:44.780 --> 00:09:48.580 ההרשאות יכולות לחסות קריאה, יצירה, שינוי ומחיקה של שורות. 00:09:48.680 --> 00:09:52.480 זה אומר שהגישה לא תלויה בכך שמי שהוא יזכור אילו כפתורים להסתיר בכל אפליקציה. 00:09:52.640 --> 00:09:54.520 ההרשאות נמצאות בתוך הנתונים עצמם. 00:09:54.680 --> 00:09:57.880 לכן, אותם מעקות בטיחות חלים בכל מקום שבו מופיעים נתוני דאטוורס. 00:09:58.000 --> 00:10:00.160 לאחר מכן, ניתן לצמצם את הגישה עוד יותר. 00:10:00.340 --> 00:10:03.580 הבטחה ברמת השורה קובעת אם אילו שורות בודדות אדם יכול לעבוד. 00:10:03.580 --> 00:10:06.040 נציג מחירות עשוי לראות רק את הלקוחות שבבעלותו, 00:10:06.200 --> 00:10:09.440 בעוד שמנהל מחירות יכול לראות את שורות הלקוחות שבבעלות כל הצוות שלו. 00:10:09.560 --> 00:10:11.600 שניהם משתמשים באותה טבלת חשבונות. 00:10:11.640 --> 00:10:13.360 הם פשוט לא רואים את אותו חלק ממנה. 00:10:13.440 --> 00:10:17.420 המבנה הזה עוזר לאנשים להתמקד בעבודה שלהם תוך מתן המבט הנדרש למנהלים. 00:10:17.640 --> 00:10:21.720 זה גם מפחית את הסיכוי שמישהו יפתח מידע על לקוח שאין לו סיבה לגשת אליו. 00:10:21.840 --> 00:10:24.180 מידע מסוים זקוק להגנה הדוקה עוד יותר. 00:10:24.180 --> 00:10:27.700 הבטחה ברמת העמודה יכולה להגן על עמודות בודדות בתוך טבלה. 00:10:27.840 --> 00:10:29.720 אולי משתמש יכול לפתוח שורת לקוח, 00:10:29.940 --> 00:10:33.800 אך לא אמור לראות מזהה אישי, נתון שכר, פרטי בנק או הערה פיננסית פרטית. 00:10:33.960 --> 00:10:37.020 שורת הלקוח נשארת זמינה לצורך העבודה שעליהם לבצע. 00:10:37.160 --> 00:10:39.040 העמודה המוגנת נשארת מוגבלת. 00:10:39.160 --> 00:10:40.360 עבור חברות גדולות יותר, 00:10:40.580 --> 00:10:43.360 יחידות עסקיות יכולות ליצור גבולות בין חלקים בארגון. 00:10:43.360 --> 00:10:48.000 חברה עשויה להפריד עזורים, חטיבות או חברות בנות שעובדות עם קבוצות לקוחות שונות. 00:10:48.080 --> 00:10:51.500 יחידות עסקיות עוזרות לעצב כיצד הגישה פועלת מעבר לגבולות הללו. 00:10:51.600 --> 00:10:54.200 אין זה אומר שכל עסק זקוק למפת הבטחה מסובכת. 00:10:54.340 --> 00:10:56.860 צוות קטן עשוי להזדקק למספר תפקידים ברורים בלבד. 00:10:57.020 --> 00:11:01.040 חברה גדולה יותר עשויה להזדקק ליותר שכבות בגלל הבדלים בצוותים, בעזורים ובחריות. 00:11:01.040 --> 00:11:04.640 הנקודה היא שדטאברס יכול להתאים את הגישה לאופן שבו העסק פועל בפועל. 00:11:04.740 --> 00:11:06.960 בקרת גישה מגינה על מי יכול להגיע לנתונים, 00:11:07.220 --> 00:11:09.260 אך כללים מגינים גם על איכות הנתונים עצמם. 00:11:09.440 --> 00:11:13.520 חוק עסקי יכול לחייב מישהו להזין מספר טלפון לפני שהוא שומר איש קשר חדש. 00:11:13.660 --> 00:11:16.780 הוא יכול לבדוק תנאי, כמו דרישה על הסיבה בעת סגירת פנייה. 00:11:16.880 --> 00:11:20.280 הוא יכול גם לשנות את מה שמשתמשים רואים בהתבסס על המידע שהם מזינים. 00:11:20.440 --> 00:11:23.320 אותו חוק חל על כל האפליקציות שמשתמשות בטבלה הזו. 00:11:23.320 --> 00:11:27.920 זה חשוב כי אתה לא רוצה שהאפליקציה אחת תקבל נתונים חלקיים בעוד שאחרת תדחה אותם. 00:11:28.020 --> 00:11:31.420 החוק שייך למידע העסקי, לא למסך אחד שקורא ומציג אותו. 00:11:31.600 --> 00:11:36.140 דטאברס יכול גם להריץ לוגיקה מאחורי הקלעים כדי לעזור לשמור על תהליכים עסקיים עקביים. 00:11:36.360 --> 00:11:38.260 הפרט שאתה צריך לזכור הוא פשוט. 00:11:38.440 --> 00:11:40.960 הנתונים מגיעים עם כללים לא רק כאיכסון. 00:11:41.120 --> 00:11:46.540 אז, התשתית כוללת את המידע, האנשים המורשים לעבוד איתו, והכללים ששומרים עליו שמיש. 00:11:46.540 --> 00:11:53.040 ברגע שדיינמיקס 365 עובד על אותה תשתית, הוא לא זקוק לגשר מסורתי רק כדי להגיע לנתונים העסקיים שלו. 00:11:53.160 --> 00:11:59.820 מה שאינטגרציית דיינמיקס 365 אומרת באמת, רוב האנשים שומעים אינטגרציית דיינמיקס 365 עם דייטאברס, 00:12:00.020 --> 00:12:02.460 ומדמיינים שתי מערכות נפרדות המחוברות על ידי מחבר. 00:12:02.640 --> 00:12:06.180 מערכת אחת מחזיקה את נתוני הלקוח, מערכת אחרת צריכה עותק, 00:12:06.340 --> 00:12:10.560 אז מי שהוא מגדיר סינקרון מחכה שהוא ירוץ ומקווה ששום דבר לא ייקשל בדרך. 00:12:10.560 --> 00:12:19.180 התמונה הזו היגיונית עבור הרבה כלים עסקיים, אבל כאן, ב-TMS, עבור דיינמיקס 365 סיילס ודיינמיקס 365 קסטומר סארוויס, 00:12:19.380 --> 00:12:20.640 החיבור קרוב הרבה יותר מזה. 00:12:20.800 --> 00:12:24.080 אפליקציות אלו משתמשות בדטאברס כתשתית הנתונים המשותפת שלהן. 00:12:24.220 --> 00:12:28.960 הן אינן שני מסדי נתונים נפרדים שמעבירים שורות לקוחות הלוך ושוב רק כדי להבין אחד את השני. 00:12:29.120 --> 00:12:31.520 הן עובדות מאותו מידע עסקי כבר מההתחלה. 00:12:31.720 --> 00:12:33.360 בואו נהפוך את זה לקונקרטי. 00:12:33.360 --> 00:12:39.160 דמיין שאתה איש מחירות ואתה יוצר חברה חדשה בדיינמיקס 365 סיילס. 00:12:39.280 --> 00:12:42.320 אתה מוסיף את איש הקשר הראשי ומתחיל לעבוד על עסקה אפשרית. 00:12:42.480 --> 00:12:46.140 הפרטים האלה הופכים מיד לחלק מהנתונים המשותפים שבהם משתמשת האפליקציה. 00:12:46.300 --> 00:12:48.360 מאוחר יותר, אותו לקוח פונה לתמיכה. 00:12:48.520 --> 00:12:51.880 סוכן התמיכה יכול לעבוד עם אותם פרטי חברה ואיש קשר בדיוק. 00:12:51.880 --> 00:12:56.600 אף אחד לא צריך לייצר רשימה מהמחירות או ליצור את הלקוח שוב בתוך כלי תמיכה נפרד. 00:12:56.600 --> 00:13:02.240 הסוכן פשוט מחבר את פניית התמיכה לאותו לקוח ורואה את ההיסטוריה שעוזרת לו להבין מה ה-TMS שקורה. 00:13:02.400 --> 00:13:06.780 המחירות רואות את העסקה, התמיכה רואה את הפנייה, ושני הצוותים פועלים סביב אותו הלקוח. 00:13:06.980 --> 00:13:11.440 זה לא אומר בהכרח שכל מסך נראה זהה או שכל צוות פועל לפי אותו תהליך בדיוק. 00:13:11.620 --> 00:13:14.840 אנשי מחירות, זקוקים ללידים, הזדמנויות, שיחות ופגישות. 00:13:14.840 --> 00:13:17.820 שירות לקוחות זקוק לפניות, תורים והיסטוריית שירות. 00:13:17.820 --> 00:13:22.020 כל אפליקציית דיינמיקס 365 מעניקה לאנשים כלים שנבנו עבור תפקידם. 00:13:22.180 --> 00:13:25.140 בעוד שהמידע העסקי שמאחורי הקלעים יכול להתחבר לכל מקום, 00:13:25.380 --> 00:13:30.640 בסיס משותף זה הוא מה שאנשים מתכוונים אליו כשהם מדברים על אינטגרציית דיינמיקס 365 ודטאברס. 00:13:30.820 --> 00:13:34.200 זה לא עניין של העברת נתונים מנקודה א' לנקודה בית. 00:13:34.200 --> 00:13:39.820 הכל נובע מאפליקציות שעובדות עם אותן שורות, קשרים, כללים ובקרות גישה מההתחלה. 00:13:40.160 --> 00:13:42.180 בואו נעבור על תהליך מחירה פשוט. 00:13:42.180 --> 00:13:44.780 ליד מגיע מאתר אינטרנט או מאירוע. 00:13:45.360 --> 00:13:50.900 איש מחירות עובד עם אותו ליד, לומד עליו יותר, והופך את הליד לקשר עסקי ולהזדמנות. 00:13:51.120 --> 00:13:54.940 שיחות, אימיילים, פגישות ומשימות יכולים כולם להתחבר לעבודה הזו. 00:13:55.040 --> 00:13:58.860 כך הצוות לא צריך לחפש בחלים נפרדים כדי להרכיב את התמונה המלאה. 00:13:58.860 --> 00:14:03.500 אם הלקוח זקוק לעזרה מאוחר יותר, פניית שירות יכולה להתחבר בחזרה לאותו לקוח. 00:14:03.660 --> 00:14:06.300 נציג התמיכה לא רואה רק שם וכתובת אימייל. 00:14:06.300 --> 00:14:10.600 הוא יכול לעבוד בהקשר של מערכת היחסים עם הלקוח שכבר זוהתה. 00:14:10.720 --> 00:14:17.380 בינתיים, צוות המחירות יכול לראות של הלקוח יש פניית שירות פתוחה ולהימנע משיחת חידוש מבלי לדעת שיש בעיה. 00:14:17.520 --> 00:14:23.720 קשר לקוח אחד יכול לתמוך בסוגי עבודה שונים, וזה שימושי בהרבה מאשר רק לשמור שם לקוח תואם בשתי מערכות. 00:14:23.720 --> 00:14:28.440 אולי תשמעו גם את המונח מודל נתונים משותף, Common Data Model, המקוצר לעתים ל-CDM. 00:14:28.580 --> 00:14:31.240 אל תתנו לשם להישמע מסתורי יותר ממה שהוא באמת. 00:14:31.440 --> 00:14:36.380 זה פשוט אומר שמייקרוסופט מספקת תבניות טבלאות עסקיות נפוצות לדברים שחברות רבות עוקבות אחריהם, 00:14:36.580 --> 00:14:38.660 כמו חשבונות, אנשי קשר, פעילויות ופניות. 00:14:38.860 --> 00:14:43.500 תבניות אלו נותנות לדיינמיקס 365 ולאפליקציות מבוססות Dataverse, שפה משותפת להתחלה. 00:14:43.500 --> 00:14:44.800 חשבון פירושו חברה. 00:14:44.900 --> 00:14:46.300 איש קשר פירושו אדם. 00:14:46.400 --> 00:14:49.200 פעילות עוקבת אחר עבודה סביב מערכת יחסים עסקית. 00:14:49.360 --> 00:14:53.620 אתם יכולים להתאים את ההגדרות לחברה שלכם ולהוסיף טבלאות משלכם בעת הצורך, 00:14:53.840 --> 00:14:55.280 אך לא תתחילו מאפס בכל פעם. 00:14:55.480 --> 00:14:59.540 כשהאפליקציה אחת מבינה טבלת חשבונות ואפליקציה אחרת משתמשת באותה טבלה, 00:14:59.840 --> 00:15:01.880 שתיהן מתייחסות לאותו סוג של מידע עסקי. 00:15:02.040 --> 00:15:03.820 זה גם משנה את מה שאתם יכולים לבנות. 00:15:03.820 --> 00:15:07.140 נניח שהצוות בשטח זקוק לאפליקציה פשוטה כדי לאתר לקוח, 00:15:07.140 --> 00:15:09.300 לאשר ביקור ולהוסיף הערה לאחר הפגישה. 00:15:09.420 --> 00:15:14.020 אתם יכולים לבנות פאוור אפ שעובדת עם אותן טבלאות דייטאברס שכבר נמצאות בשימוש בדיינמיקס 365. 00:15:14.540 --> 00:15:17.980 אין צורך לייצא את הלקוחות לרשימה חדשה רק עבור האפליקציה הזו. 00:15:18.120 --> 00:15:22.200 עובד השטח פותח את האפליקציה, מוצא את הלקוח ומעדכן את פרטי הביקור. 00:15:22.200 --> 00:15:26.760 הנתונים נשארים מחוברים לכשרי הלקוחות שבהם משתמשים המחירות או שירות הלקוחות, 00:15:26.960 --> 00:15:29.020 בחפוף לכללי האבטחה שסקרנו קודם. 00:15:29.160 --> 00:15:32.540 לצורך עבודה עסקית מובנת יותר, ניתן לבנות אפליקציה מונחת מודל. 00:15:32.680 --> 00:15:34.880 אפליקציה מונחת מודל מתחילה במודל נתונים. 00:15:35.080 --> 00:15:36.620 אתה בוחר את טבלאות האדטאברס, 00:15:36.800 --> 00:15:37.860 מגדיר את הקשרים ביניהן, 00:15:37.960 --> 00:15:40.060 מקים תפסים ותצוגות ומכיל תפקידי הבטחה. 00:15:40.180 --> 00:15:43.820 פאוור אפס משתמשת אז במבנה הזה כדי ליצור חוויית אפליקציה עסקית פעילה. 00:15:43.820 --> 00:15:47.820 חשוב על זה כעל סידור שולחן עבודה סביב הכלים והחומרים שהצוות שלך באמת משתמש בהם. 00:15:47.820 --> 00:15:50.960 הטבלאות מתארות את העבודה והקשרים מחברים בין החלקים. 00:15:51.120 --> 00:15:53.600 תפסים מאפשרים לאנשים להזין ולעיין בפרטים. 00:15:53.760 --> 00:15:56.420 תצוגות עוזרות להם למצוא את השורות שדורשות תשומת לב. 00:15:56.560 --> 00:15:59.040 הבטחה קובעת מה כל אדם יכול לפתוח או לשנות. 00:15:59.260 --> 00:16:03.800 אפליקציה מונחת מודל יכולה לפעול לצד דיינמיקס 365 מכיוון ששתיהן עובדות עם דייטוורס. 00:16:03.800 --> 00:16:07.240 אולי דיינמיקס 365 סיילס מטפלת בתהליך המחירה המלא. 00:16:07.440 --> 00:16:11.900 בעוד שאפליקציה מונחת מודל קטנה יותר נותנת למנהלי חוזים מקום ממוקד למעקב אחר הסכמי לקוחות. 00:16:12.020 --> 00:16:15.800 שתיהן יכולות לעבוד עם נתוני לקוחות קשורים מבלי ליצור מאגר לקוחות שני. 00:16:15.940 --> 00:16:18.280 כמובן, גישה כזו עדיין דורשת זהירות. 00:16:18.520 --> 00:16:21.380 רק בגלל שהאפליקציה יכולה לעבוד עם טבלת דייטוורס, 00:16:21.380 --> 00:16:24.940 זה לא אומר שכל משתמש צריך לערוך כל שורה או לראות כל עמודה. 00:16:25.080 --> 00:16:28.620 התפקיד, הגישה לשורות והכללים העסקיים עדיין שולטים במה שקורה. 00:16:28.620 --> 00:16:32.920 אפליקציית שטח יכולה לתת למי שהוא בדיוק את פרטי הלקוח והפעולות שהוא צריך, 00:16:33.100 --> 00:16:35.200 מבלי לחשוף את שאר החברה או את הנתונים שלה. 00:16:35.320 --> 00:16:40.920 לכן, האינטגרציה של דיינמיקס 365 עם דייטוורס היא כעת כבל שמחבר בין שני חדרים רחוקים. 00:16:40.920 --> 00:16:46.580 אפליקציות דיינמיקס 365, אפליקציות מותאמות אישית ותהליכים עסקיים יכולים כולם לעבוד מאותו בסיס משותף. 00:16:46.660 --> 00:16:49.280 ברגע שרואים זאת, השאלה הבאה הופכת לברורה. 00:16:49.280 --> 00:16:54.820 באילו עוד דרכים ניתן להשתמש באותו עדכון לקוח ברחבי מייקרוסופט או הפלטפורמה המחוברת. 00:16:55.020 --> 00:16:57.840 כיצד הפלטפורמה המחוברת עובדת בעבודה אמיתית? 00:16:57.980 --> 00:17:01.660 עדכון לקוח משותף הופך לשימושי כאשר הכלים סביבו יכולים להגיב. 00:17:01.660 --> 00:17:07.360 Power Automate מטפל בעבודת ההמשך על ידי ניטור שינויים בשורת דייטוורס והפעלת פעולה כשהשינוי הזה קורה. 00:17:07.520 --> 00:17:11.140 לדוגמה, ליד חדש נכנס לדיינמיקס 365 סיילס. 00:17:11.140 --> 00:17:16.120 זרימת עבודה יכולה להודיע לאיש המחירות המוקצה, לפרסם הודעה בטימס או ליצור משימת המשך. 00:17:16.240 --> 00:17:19.160 אף אחד לא צריך לצפות בתיבת דואר נכנס משותפת כל היום. 00:17:19.300 --> 00:17:22.120 הליד משתנה והשלב הבא מתחיל באופן אוטומטי. 00:17:22.120 --> 00:17:26.780 Power Automate לא זקוק לאותק נפרד של הליד רק כדי לבצע את העבודה הזו. 00:17:26.880 --> 00:17:32.020 הוא יכול להגיב לשורה בדטוורס באמצעות אותם פרטי לקוח ובעלות שבהם משתמשת אפליקציית המחירות. 00:17:32.020 --> 00:17:38.040 זה שומר על האוטומציה קרובה לתהליך העסקי, במקום להסתמך על מישהו שיצא קובץ ויתחיל שרשרת מיילים ידני. 00:17:38.240 --> 00:17:39.480 אז יש את Power Buy. 00:17:39.660 --> 00:17:42.420 מנהל מחירות עשוי לרצות לראות את הצינור הנוכחי. 00:17:42.420 --> 00:17:49.680 מנהל שירות לקוחות עשוי להזדקק לראות כמה פניות הגיעו השבוע, אילו פניות נותרו פתוחות או אילו לקוחות פונים לתמיכה הכי הרבה. 00:17:49.680 --> 00:17:57.660 Power Buy יכול להפיק דוחות על נתונים עסקיים מדטוורס, כך שהצוותים יכולים לראות את העבודה שמתבצעת מבלי להכין דוחות אקסל חדשים בכל יום שישי אחר הצהריים. 00:17:57.820 --> 00:18:00.760 הדוח שואב מהנתונים העסקיים שאנשים כבר משתמשים בהם. 00:18:00.760 --> 00:18:03.940 זה אומר שתרשים הצינור יכול להשתנות ככל שהזדמנויות מתקדמות. 00:18:04.100 --> 00:18:07.960 לוח מכוונים של פניות יכול להציג את עומס העבודה הנוכחי ככל שנציגים מעדכנים פניות. 00:18:08.160 --> 00:18:12.180 הנקודה היא שלוח מכוונים מחליף את הצורך של אנשים לבדוק את הפרטים בעצמם. 00:18:12.180 --> 00:18:16.440 הוא נותן להם תמונה ברורה יותר של העבודה לפני שהם מחליטים מה דורש תשומת לב. 00:18:16.580 --> 00:18:19.320 Power Apps מוסיף דרך נוספת לתוך אותו תהליך. 00:18:19.520 --> 00:18:22.140 דמיינו עובד שטח שמגיע לאתר של לקוח. 00:18:22.140 --> 00:18:25.640 הוא לא צריך את כל חוויית המחירות של Dynamics 365. 00:18:26.240 --> 00:18:31.820 הוא עשוי להזדקק רק למציאת הלקוח, עיון בפרטי הביקור, אישור מה קרה והוספת הערה או תמונה. 00:18:32.000 --> 00:18:35.440 אפליקציית Power Apps ממוקדת יכולה לספק לו את החוויה המצומצמת הזו. 00:18:35.440 --> 00:18:38.680 צוות ניהול לקוחות עשוי להזדקק לאפליקציה לבדיקת הסכמי לקוחות. 00:18:38.860 --> 00:18:41.460 מנהל עשוי להזדקק לאפליקציה פשוטה לאישור בקשות. 00:18:41.460 --> 00:18:46.560 כל אפליקציה יכולה להתמקד במשימה אחת בעוד שהיא עובדת עם אותו מידע מנוהל בדטאברס מאחורי הקלעים. 00:18:46.680 --> 00:18:48.700 האדם רואה את הכלי שמתאים ליום שלו. 00:18:48.840 --> 00:18:50.580 העסק שומר על המידע המקושר. 00:18:50.740 --> 00:18:53.120 לפעמים המידע הזה מתחיל מחוץ לדטאברס. 00:18:53.120 --> 00:18:57.720 לחברה עשויה להיות רשימה ממקור מקוון שצריכה להפוך לחלק מהנתונים העסקיים שלה. 00:18:57.720 --> 00:19:04.620 Power Query יכול להביא נתונים ממקורות מקוונים נתמכים, לנקות אותם במהלך העיבוב ולטעון אותם לטבלה הנכונה בדטאברס. 00:19:04.800 --> 00:19:10.200 זה שימושי כאשר מקור חיצוני מחזיק מידע שכלי הדיינמיקס והאאור פלטפורם שלך צריכים להשתמש בו. 00:19:10.360 --> 00:19:14.600 אתה עדיין צריך להחליט מה שייך לדטאברס ואיך זה צריך להתחבר לטבלאות הקיימות. 00:19:14.600 --> 00:19:18.640 ייבון נתונים ללא מחשבה כזו פשוט מעביר את הבלבול למיקום חדש. 00:19:18.640 --> 00:19:22.020 תן לאותום, אוטום, לחבר את החלקים לזרימה יומיומית אחת. 00:19:22.140 --> 00:19:28.180 ליד חדש נכנס לדיינמיקס 365 וכלל הקצאה בודק מי צריך לטפל בליד הזה, אולי על בסיס אזור או מוצר. 00:19:28.300 --> 00:19:32.520 הבעלים מקבל הודעת טימס דרך זרימת Power Automate, כך שהוא יודע שיש עבודה שממתינה. 00:19:32.520 --> 00:19:35.580 ככל שהאיש מחירות מעדכן את הליד ומקדם אותו בתהליך המחירה, 00:19:35.760 --> 00:19:39.760 לוח המכוונים של Power Buy משתנה כדי להראות לצוות מהו הצינור הנוכחי של צוות אוטום. 00:19:39.900 --> 00:19:42.220 עדכון אחד מתחיל עבודה מועילה בכמה מקומות. 00:19:42.380 --> 00:19:44.900 Power Automate מעביר עבודה מצד אחד למשנהו. 00:19:45.020 --> 00:19:47.100 Power Buy עוזר לאנשים לראות את העבודה. 00:19:47.240 --> 00:19:50.400 Power Apps מעניקות לצוותים ספציפיים דרך ממוקדת להשתתף בתהליך. 00:19:50.580 --> 00:19:54.840 Dataverse שומר על המידע העסקי מאורגן ומאובטח בזמן שהכלים האלו מבצעים את עבודתם. 00:19:54.840 --> 00:19:56.420 להבדל הזה יש חשיבות. 00:19:56.560 --> 00:20:00.740 אוטומציה היא לא מערכת תיוק, ולוח מכוונים הוא לא מסד נתונים של לקוחות. 00:20:00.820 --> 00:20:04.160 לכל כלי יש תפקיד נפרד, אך כולם יכולים לעבוד מאותו מקור נתונים. 00:20:04.340 --> 00:20:06.380 ההבנה הזו עוזרת לבחור את הכלי הנכון, 00:20:06.540 --> 00:20:10.580 במקום להתייחס לכל גיליון אלקטרוני או רשימה כאל כלי לניהול תהליך עסקי שלם. 00:20:11.820 --> 00:20:14.300 מתי Dataverse מתאים ומה הוא אינו מחליף? 00:20:14.720 --> 00:20:15.480 הנה העניין. 00:20:15.660 --> 00:20:19.540 בחרו בדטאברס כאשר אנשים ויישומים מרובים צריכים לעבוד עם נתונים עסקיים מקושרים. 00:20:19.540 --> 00:20:22.480 אתם זקוקים לכללי גישה ברורים ותהליכים הניתנים לשכפול. 00:20:22.620 --> 00:20:25.200 Dataverse מטפל בכך, אך הוא לא מחליף את כל השאר. 00:20:25.320 --> 00:20:28.480 אקסל הוא עדיין הבחירה המועדפת לניתוח אישי ולרשימות מהירות. 00:20:28.620 --> 00:20:31.380 רשימות SharePoint עובדות היטב עבור מעקב צוותי פשוט. 00:20:31.540 --> 00:20:33.700 ואם אתם מפתחים הזקוקים לשליטה מעמיקה, 00:20:33.960 --> 00:20:35.240 SQL נותר בחירה חזקה. 00:20:35.320 --> 00:20:37.200 אז, מתי Dataverse באמת מתאים? 00:20:37.380 --> 00:20:40.400 כשהנתונים שלכם צריכים להתחבר בין יישומי Dynamics 365, 00:20:40.960 --> 00:20:42.900 אוטומציות ודוחות מבלי ליצור העתק נוסף. 00:20:42.900 --> 00:20:44.440 זה המקום שבו הוא מבריד. 00:20:44.540 --> 00:20:47.760 אבל, לסיכום, יסוד אחד, כלים עסקיים רבים. 00:20:47.980 --> 00:20:49.420 אז, זו השורה התחתונה. 00:20:49.620 --> 00:20:52.540 Dynamics 365 וDataverse עובדים בצורה הטובה ביותר 00:20:52.540 --> 00:20:54.680 כשכל הנתונים, הכללים, ההבטחה, היישומים, 00:20:54.820 --> 00:20:56.900 האוטומציות והדוחות שלכם חולקים בסיס משותף. 00:20:57.020 --> 00:21:00.080 הרשמו למיקרוסופט Knowledge Nuggets ב-M365.fm 00:21:00.080 --> 00:21:02.480 לקבלת מדריכים בשפה פשוטה על Dynamics 365, 00:21:02.940 --> 00:21:04.640 Power Platform ומיקרוסופט 365. 00:21:05.080 --> 00:21:07.480 לאחר מכן צפו בפרק שלנו על יישומים מונחי מודל 00:21:07.480 --> 00:21:09.960 כדי לראות איך תבלעות Dataverse הופכות ליישום עסקי עובד.