WEBVTT

00:00:00.000 --> 00:00:02.060
ברוכים הבאים ל-Microsoft Knowledge Nuggets.

00:00:02.200 --> 00:00:03.040
אני מו פיטרז.

00:00:03.140 --> 00:00:05.920
הנושא של היום הוא נושא של עיתים קרובות מבלבל אנשים.

00:00:06.160 --> 00:00:07.420
מה זה בעצם Dataverse?

00:00:07.640 --> 00:00:13.080
האם זה בסיס נתונים, אפליקציה או שירות Dynamics 365 נסתר שרק אנשי אית צריכים להבין?

00:00:13.240 --> 00:00:14.800
הנה ההגדרה הפשוטה ביותר.

00:00:14.960 --> 00:00:18.700
Dataverse הוא תשתית הנתונים המשותפת שמאחורי חוויות רבות ב-Dynamics 365.

00:00:19.200 --> 00:00:22.040
חישבו על Dynamics 365 כעל בניין משרדים.

00:00:22.180 --> 00:00:25.960
מחירות, שירות לקוחות ואפליקציות אחרות הם החדרים שבהם אנשים עובדים,

00:00:25.960 --> 00:00:29.140
בעוד ש-Dataverse הוא מערכת התיוק והחוקים שמאחורי הקירות.

00:00:29.240 --> 00:00:36.180
עד סוף הפרק הזה, תדעו איך נתוני Dynamics חיים וכיצד עדכון לקוח אחד יכול להופיע בעבודת המחירות, באוטומציה ובדיווח.

00:00:36.320 --> 00:00:39.960
אבל לפני שנצלול לשמות של מוצרים, בואו נתחיל עם הבלגן העסקי.

00:00:40.120 --> 00:00:41.800
זה פותר מקום אחד משותף.

00:00:42.740 --> 00:00:47.720
במקום עותקים נפרדים, דמיינו חברה עם צוות מחירות, צוות תמיכה וצוות כספים.

00:00:47.920 --> 00:00:50.440
המחירות שומרות פרטי לקוח בגיליון אלקטרוני.

00:00:50.440 --> 00:00:52.640
התמיכה עובדת בכלי ניהול פניות נפרד.

00:00:52.760 --> 00:00:55.080
לכשפים יש שמות לקוחות במערכת משלהם.

00:00:55.220 --> 00:00:57.820
מי שהוא אחר שומר שרשורי אימייל בתיבת דואר משותפת.

00:00:57.980 --> 00:01:00.760
בעוד שאדם אחר שומר הערות בתיקייה שאף אחד אחר לא יכול למצוא.

00:01:00.860 --> 00:01:02.800
אותו לקוח קיים כעת בחמישה מקומות.

00:01:02.960 --> 00:01:07.120
המבנה הזה מרגיש נורמלי בהתחלה כי כל צוות רואה רק את החלק של העבודה שלפניו.

00:01:07.260 --> 00:01:08.140
אבל הנה העניין.

00:01:08.320 --> 00:01:12.500
ברגע של לקוח משנה את מספר הטלפון, הכתובת, שם החברה או איש הקשר הראשי שלו, הבעיות מתחילות.

00:01:12.500 --> 00:01:14.480
המחירות מעדכנות את הגיליון האלקטרוני.

00:01:14.600 --> 00:01:15.580
התמיכה לא רואה זאת.

00:01:15.720 --> 00:01:17.960
הכספים עדיין שולחים מסמכים לכתובת הישנה.

00:01:18.100 --> 00:01:24.080
ואז מי שהוא מייצר רשימה, מנקה אותה ידנית, שולח אותה במייל, ופתאום שלושה אנשים מאמינים שכל אחד מהם מחזיק בעותק הנכון.

00:01:24.240 --> 00:01:25.620
באיזו רשימה כדאי לבטוח?

00:01:25.800 --> 00:01:28.260
השאלה הזו מבזבזת יותר זמן ממה שאתם עשויים לחשוב.

00:01:28.440 --> 00:01:30.140
צוותים עוצרים כדי להשוות רשומות.

00:01:30.300 --> 00:01:32.920
מנהלים שואלים מדוע דוח לא תואם למערכת המחירות.

00:01:32.920 --> 00:01:37.600
נציג תמיכה פותח פנייה עבור לקוח שהפרטים שלו כבר יושבים במקום אחר, רק מעט שונים.

00:01:37.800 --> 00:01:39.280
אף אחד לא מנסה ליצור בלגן.

00:01:39.460 --> 00:01:40.780
הבלגן נובע מעותקים.

00:01:40.980 --> 00:01:46.160
לפני עשרים שנה, מערכות נפרדות, פירושן שרתים נפרדים, בסיסי נתונים נפרדים וצוותים נפרדים ששומרים את המידע שלהם.

00:01:46.280 --> 00:01:49.920
חיבור ביניהם דרש עבודה מותאמת אישית, איבום מתוזמן והרבה בדיקות ידניות.

00:01:50.160 --> 00:01:54.040
שינוי במקום אחד עשוי להגיע למערכת אחרת מחר, בשבוע הבא, או לעולם לא.

00:01:54.040 --> 00:01:57.740
דייטוורס מעניק לאפליקציות עסקיות מקום משותף לסוג כזה של מידע.

00:01:57.860 --> 00:02:02.380
במילים פשוטות, דייטוורס היא פלטפורמת נתוני הענן של מייקרוסופט למידע עסקי.

00:02:02.520 --> 00:02:10.580
היא מאחסנת את המידע הזה בטבלאות מובנות, כך שלנתונים יש צורה ברורה במקום לחיות כהערות אקראיות, קבצים רופפים וחרטיסיות גיליון אלקטרוני מנותקות.

00:02:10.680 --> 00:02:15.420
אפשר לחשוב על זה כארון הטיוק של החברה, שכלים מאושרים רבים יכולים להשתמש בו בו זמני.

00:02:15.420 --> 00:02:17.500
לקוח מופיע פעם אחת בדטוורס.

00:02:17.620 --> 00:02:22.060
אותו לקוח יכול להופיע בדיינמיקס 365 סיילס כשאיש מחירות עובד על עסקה.

00:02:22.180 --> 00:02:27.760
אותם פרטי לקוח יכולים להופיע בדיינמיקס 365 קסטומר סארוויס כשנציג מטפל בבקשת תמיכה.

00:02:27.900 --> 00:02:34.300
אפליקציית פאור אפ יכולה להשתמש באותו מידע לקוח עבור עובד שטח או מנהל תיק לקוח, בלי שאף אחד יצטרך להעתיק את הנתונים לאפליקציה חדשה.

00:02:34.440 --> 00:02:37.140
שורה אחת של לקוח, נקודת ייחוס אחת משותפת.

00:02:37.140 --> 00:02:39.320
זה לא אומר שכל צוות רואה פתאום את הכל.

00:02:45.420 --> 00:02:47.380
במקום לבנות גרסאות מתחרות משלהן.

00:02:47.540 --> 00:02:51.360
זו הסיבה שדיינמיקס 365 ודטוורס משתלבים יחד בצורה כל כך טבעית.

00:02:51.560 --> 00:02:56.660
אפליקציות דיינמיקס 365, כמו סיילס וקוסטומר סארוויס, משתמשות בדטוורס כדי להחסן ולהבטח את הנתונים שעליהם עובדו.

00:02:56.740 --> 00:02:57.620
אבל הנה העניין.

00:02:57.800 --> 00:03:04.080
כשמדברים על אינטגרציה בין דיינמיקס 365 לדטוורס, לעתים קרובות מדמיינים שני מוצרים נפרדים שזקוקים למחבר ביניהם.

00:03:04.080 --> 00:03:07.340
עבור אפליקציות רבות של דיינמיקס 365, המצב אינו כזה.

00:03:07.480 --> 00:03:09.460
הנתונים כבר נמצאים בתוך דייטוורס.

00:03:09.580 --> 00:03:16.040
אתה לא מושך רשימת לקוחות מתוך דיינמיקס 365, מעתיק אותה למסעד נתונים אחר ומקווה ששני הצדדים יישארו מעודכנים.

00:03:16.240 --> 00:03:21.360
אפשר לבנות על אותה תשתית תוך שימוש באותו מידע עסקי שדיינמיקס 365 כבר משתמש בו.

00:03:21.500 --> 00:03:22.800
זה משנה את כל השיחה.

00:03:22.920 --> 00:03:26.280
במקום לשאול איך אנחנו מסנקרנים בין שתי רשימות הלקוחות האלה,

00:03:26.280 --> 00:03:31.560
אפשר לשאול אילו אנשים ואפליקציות צריכים לעבוד עם רשומת הלקוח הזו ומה מותר לכל אחד מהם לעשות.

00:03:31.660 --> 00:03:34.900
כמובן, דייטוורס לא מחליף כל מערכת שהחברה מחזיקה.

00:03:35.040 --> 00:03:42.160
עסק עשוי להמשיך להשתמש בתוכנות פיננסיות, כלי תעשייה, מערכות מחסן, אתרים או יישומים ישנים שמחזיקים נתונים משלהם.

00:03:42.320 --> 00:03:45.960
דייטוורס הוא לא דבק קסם שמעלים כל מערכת חיצונית בין לילה,

00:03:46.080 --> 00:03:50.720
מה שהוא נותן לחזה מקום משותף לנתונים עסקיים שאפליקציות מחוברות צריכות לחלוק.

00:03:50.720 --> 00:03:54.900
פרטי לקוח, עבודת מחירות, עבודת תמיכה, משימות ומעקבים.

00:03:55.020 --> 00:03:59.020
הרשומות האלה יכולות לחיות יחד במקור אחד, שכלים מאושרים יכולים לקרוא ולעד כן.

00:03:59.200 --> 00:04:01.400
אז בואו נפתח יחד את ארון התיוק הזה.

00:04:01.580 --> 00:04:04.700
ברגע שתראה איך דייטוורס מארגן את המידע בפנים,

00:04:05.000 --> 00:04:11.700
החיבור לכל דיינמיקס 365 הופך להרבה יותר קל להבנה, תבלעות, שורות, עמודות וקשרים.

00:04:11.940 --> 00:04:13.520
בואו נפתח את ארון התיוק הזה.

00:04:13.720 --> 00:04:15.900
בתוך דייטוורס המידע נמצא בתבלעות.

00:04:15.900 --> 00:04:18.560
תחשוב על זה כמו ארון אמיתי עם מגירות נפרדות.

00:04:18.660 --> 00:04:22.660
מגירה אחת מכילה חברות, אחרת מכילה אנשים ושלישית מכילה בקשות תמיכה.

00:04:22.760 --> 00:04:26.740
אתה לא זורק כל נייר לתוך מגירה אחת ענקית ומקווה שמישהו יסדר את זה אחר כך.

00:04:26.880 --> 00:04:28.140
לכל מגירה יש תפקיד.

00:04:28.260 --> 00:04:30.800
אז בדייטוורס תבלה מכילה סוג אחד של מידע עסקי.

00:04:30.920 --> 00:04:33.440
תבלת חשבונות מכילה בדרך כלל חברות שאתה עובד איתן.

00:04:33.560 --> 00:04:35.580
תבלת אנשי קשר מכילה אנשים פרטיים.

00:04:35.580 --> 00:04:39.160
תבלת לידים מכילה לקוחות פוטנציאליים לפני שהם הופכים ללקוחות בפועל.

00:04:39.240 --> 00:04:45.560
תבלת מקרים מכילה בקשות תמיכה, בעוד שתבלת פעילויות יכולה לעקוב אחר עבודה כמו שיחות, אימיילים, פגישות ומשימות.

00:04:45.680 --> 00:04:47.020
אלו הן תבלעות סטנדרטיות.

00:04:47.220 --> 00:04:51.740
מייקרוסופט כוללת אותן כי רוב העסקים צריכים לעקוב אחר לקוחות, אנשים, עבודה ושיחות.

00:04:51.840 --> 00:04:56.020
אתה לא צריך להתחיל בהמצאת תבלה חדשה למה שהוא נפוץ כשתבלה סטנדרטית כבר מתאימה לעבודה.

00:04:56.020 --> 00:04:58.440
אבל לכל חברה יש גם את העבודה הייחודית שלה.

00:04:58.520 --> 00:05:01.500
חברת הדרכה עשויה להזדקק למעקב אחר קורסים ותעודות.

00:05:01.620 --> 00:05:04.640
עסק נדלן עשוי להזדקק למבנים, יחידות ובדיקות.

00:05:04.840 --> 00:05:07.600
יצרה נעשוי לעקוב אחר בדיקות ציוד או ביקורי שירות.

00:05:07.780 --> 00:05:12.220
במקרים אלו, תוכל ליצור תבלעות מותאמות אישית שמתאימות לעבודה שהחברה שלך באמת עושה.

00:05:12.320 --> 00:05:16.460
חשוב על תבלה מותאמת אישית כעל הוספת מגירה חדשה לארון ואז מתן תווית ברורה לה.

00:05:16.460 --> 00:05:18.280
כעת, כל תבלה מכילה שורות.

00:05:18.480 --> 00:05:20.260
שורה היא פריט אחד באותה מגירה.

00:05:20.360 --> 00:05:25.380
לדוגמה, שורה אחת בתבלת אנשי הקשר יכולה לייצג את מריה גומז, אדם בחברה של לקוח.

00:05:25.560 --> 00:05:29.480
השורה שלה מכילה את הפרטים האישיים שלה בנפרד מכל איש קשר אחר במערכת.

00:05:29.600 --> 00:05:32.340
עמודות מתארות את הפרטים שברצונך לשמור עבור כל שורה.

00:05:32.520 --> 00:05:39.520
שורת איש הקשר של מריה עשויה לכלול עמודות עבור שם פרטי, שם משפחה, כתובת אימייל, מספר טלפון, תפקיד, חברה, בעל הרשומה וסטטוס.

00:05:39.520 --> 00:05:42.220
עמודה מגדירה את סוג המידע ששייך לאותו מקום.

00:05:42.340 --> 00:05:47.180
לכן, עמודת אימייל מצפה לכתוב את אימייל ועמודת סטטוס יכולה להכיל את אפשרויות הסטטוס המאושרות.

00:05:47.360 --> 00:05:49.460
כך המידע העסקי מקבל מבנה המין.

00:05:49.660 --> 00:05:57.260
ללא עמודות, אדם אחד עלול להקליד מספר טלפון בתיבת הערות, אחר עשוי להוסיף אותו לסדה שם, ומישהו אחר עלול לא להזין אותו כלל.

00:05:57.380 --> 00:06:01.400
אם טבלת אנשי קשר ברורה, כולם עובדים עם אותו סט פרטים באותה מקומות.

00:06:01.400 --> 00:06:04.140
המבנה הזה גם עוזר לאפליקציות להבין את הנתונים.

00:06:04.300 --> 00:06:10.440
תופס יכול להציג את הטבות הנכונות, דוח יכול לקבץ אנשי קשר לפי סטטוס, ואוטומציה יכולה להגיב כאשר בעלים משתנה.

00:06:10.560 --> 00:06:12.120
המידע לא רק מאוחסן בחוץ.

00:06:12.320 --> 00:06:15.200
יש לו תוויות שאומרות לכלים המחוברים מה כל חלק אומר.

00:06:15.400 --> 00:06:18.880
התחל עם הטבלאות הסטנדרטיות בכל פעם שהן מתאימות לצורך העסקי שלך.

00:06:19.020 --> 00:06:23.380
אם אתה מוכר לחברות, חשבונות ואנשי קשר כבר מתארים דפוס שרוב האנשים מבינים.

00:06:23.380 --> 00:06:26.840
אם אתה מטפל בתמיכת לקוחות, מקרים נותנים לך נקודת התחלה.

00:06:26.940 --> 00:06:31.940
אז הוסף תבלאות מותאמות אישית רק במקום שבו לעסק שלך יש מידע שלא מתאים לדפוסים המובנים.

00:06:32.100 --> 00:06:36.320
זה מונע בעיה נפוצה, יצירת חמש תבלאות שונות שכולן מייצגות לקוח.

00:06:36.500 --> 00:06:41.500
צוות אחד קורא לזה לקוח, אחר קורא לזה אב לקוח, ושלישי קורא לזה איש קשר של שותף.

00:06:41.620 --> 00:06:44.360
מהר מאוד, אנשים לא יודעים באיזו תבלה עליהם להשתמש.

00:06:44.360 --> 00:06:49.680
טבלאות סטנדרטיות ברורות וטבלאות מותאמות שנקראות בכפידה שומרות על הארון מובן ככל שיותר אנשים בונים עליו.

00:06:49.760 --> 00:06:52.800
החלק הבא הוא המקום שבו המגירות הללו מתחילות לעבוד יחד.

00:06:52.920 --> 00:06:54.400
איש קשר שייך לחשבון.

00:06:54.580 --> 00:06:56.100
מריה עובדת עבור קונטוזו.

00:06:56.220 --> 00:07:00.760
במקום להקליד שוב את הכתובת, מספר הטלפון הראשי ופרטי החברה של קונטוזו בשורה של מריה,

00:07:01.060 --> 00:07:03.980
דייטווורס יכול ליצור קשר בין טבלת אנשי הקשר לטבלת החשבונו.

00:07:03.980 --> 00:07:08.180
מריה מקושרת לקונטוזו, ולקשר הזה יש חשיבות כי פרטי החברה נשארים עם החברה.

00:07:08.280 --> 00:07:11.820
אם קונטוזו משנה את כתובת המשרד, מי שהוא מעדכן את שורת החשבון פעם אחת.

00:07:11.900 --> 00:07:16.100
כל איש קשר קשור יכול להמשיך להפנות לאותה חברה מבלי לשאת עותק ישן משלו.

00:07:16.260 --> 00:07:19.180
קשרים גם מחברים מקרי תמיכה ללקוח שהעלה אותו.

00:07:19.340 --> 00:07:24.340
הם יכולים לחבר הזדמנות מחירה לשיחות, לאימיילים, לפגישות ולמשימות סביב העסקה הזו.

00:07:24.480 --> 00:07:26.320
כאשר איש מחירות פותח הזדמנות,

00:07:26.320 --> 00:07:31.040
הוא יכול לראות את הפעילות המקושרת אליה במקום לחפש ביומנים ובהערות לא קשורים.

00:07:31.180 --> 00:07:32.340
למידע יש הקשר.

00:07:32.520 --> 00:07:34.300
אתה לא מסתכל רק על מספר מקרה.

00:07:34.480 --> 00:07:36.640
אתה יכול לראות לאיזה לקוח הוא שייך.

00:07:36.800 --> 00:07:38.240
אתה לא רק צופה באיש קשר.

00:07:38.460 --> 00:07:40.880
אתה יכול לראות את החברה שמחוברת לאותו אדם.

00:07:41.060 --> 00:07:45.540
הכישורים האלה שומרים על הנתונים שימושיים בלי להקליד שוב ושוב את אותן עובדות בכמה מקומות.

00:07:45.740 --> 00:07:49.440
הערת שמות קטנה לפני שתקרא מדריכים ישנים או תצפה בסרטונים ישנים.

00:07:49.440 --> 00:07:52.220
ייתכן שתשמע את המילים ישות, שדה ורשומה.

00:07:52.220 --> 00:07:53.880
אלו מונחי Dataverse ישנים.

00:07:54.080 --> 00:07:59.160
מייקרוסופט משתמשת כעת בטבלה במקום בישות, בעמודה במקום בשדה ובשורה במקום ברשומה.

00:07:59.280 --> 00:08:00.600
המשמעות לא השתנתה.

00:08:01.300 --> 00:08:04.900
מדריך ישן שאומר לך ליצור ישות מדבר על יצירת טבלה.

00:08:05.740 --> 00:08:08.000
שדה הוא עמודה ורשומה היא שורה.

00:08:08.220 --> 00:08:12.200
הכרת שתי הקבוצות של המילים תמנה ממך לחשוב שמצאת מוצר אחר.

00:08:12.340 --> 00:08:15.340
אז טבלאות מארגנות את המידע ואת הקשרים שביניהם.

00:08:15.340 --> 00:08:17.980
אבל ארון מאורגן היטב עדיין זקוק לבקרות.

00:08:17.980 --> 00:08:21.920
מי שהוא חייב להחליט מה האנשים יכולים להזין, לשנות ולגשת אליו בבטחה.

00:08:22.020 --> 00:08:24.300
הכללים ודלפק הקבלה שמאחוריי הנתונים.

00:08:24.500 --> 00:08:27.620
נתונים משותפים עובדים רק כשהאנשים הנכונים יכולים לעבוד איתם בבטחה.

00:08:27.700 --> 00:08:29.340
איש מחירות זקוק לפרטי לקוח.

00:08:29.520 --> 00:08:31.260
נציג תמיכה זקוק להיסטוריית מקרים.

00:08:31.460 --> 00:08:32.960
מנהל זקוק למבט רחב יותר.

00:08:33.200 --> 00:08:36.460
ושותף חיצוני עשוי להזדקק לגישה לחלק קטן בלבד מהתהליך.

00:08:36.600 --> 00:08:38.420
הם לא אמורים לראות כולם את אותו מידע.

00:08:38.420 --> 00:08:43.420
חשוב על רשומת לקוח עם הערת קשר פרטית, מחיר מוסכם ומקרה תמיכה פתוח.

00:08:43.580 --> 00:08:46.480
מתן גישה מלאה לכל משתמש ייצור סיכון מהר מאוד.

00:08:46.640 --> 00:08:50.220
הגבלת כולם בצורה כזו שהם לא יכולים לבצע את עבודתם יוצרת בעיה אחרת.

00:08:50.440 --> 00:08:52.200
דייטאברס מעניקה לך בקרות לכך.

00:08:52.340 --> 00:08:54.080
הבקרה הראשונה מתחילה בזהות.

00:08:54.260 --> 00:08:58.140
כשאתה נכנס עם חשבון החברה שלך, מייקרוסופט אינטרה איי די מזהה אותך.

00:08:58.300 --> 00:09:01.240
חשוב על אינטרה איי די כעל עמדת הקבלה בכניסה למשרד.

00:09:01.240 --> 00:09:05.200
אתה מגיע, מציג את התאג שלך, והפקיד בודק מי אתה לפני שתוכל להיכנס.

00:09:05.360 --> 00:09:08.800
דייטאברס משתמשת בזהות הזו כדי לדעת איזה משתמש עובד עם הנתונים.

00:09:09.000 --> 00:09:11.560
היא לא עוצרת בשאלה האם מותר לאדם הזה להיכנס.

00:09:11.720 --> 00:09:14.720
היא גם שואלת מה מותר לאדם הזה לעשות לאחר הכניסה.

00:09:14.840 --> 00:09:16.860
כאן נכנסים לתמונה תפקידי הבטחה.

00:09:17.000 --> 00:09:20.680
תפקיד הבטחה הוא קבוצת הרשאות המקושרת לתפקיד או לאחריות.

00:09:20.680 --> 00:09:25.440
ניתן ליצור תפקיד אחד לאנשי מחירות, אחר לנציגי שירות לקוחות ואחר למנהלים.

00:09:25.600 --> 00:09:27.540
כל תפקיד יכול לשלוט בגישה לטבלה.

00:09:27.680 --> 00:09:32.900
למשל, איש מחירות עשוי להיות מאושה לקרוא, ליצור ולהדכן חשבונות, אנשי קשר, לידים והזדמנויות.

00:09:33.040 --> 00:09:35.640
ייתכן שלא יורשה לו למחוק מידע חשוב על לקוחות.

00:09:35.820 --> 00:09:39.660
נציג תמיכה עשוי ליצור ולהדכן פניות, אך לא לשנות הזדמנות מחירה.

00:09:39.780 --> 00:09:43.420
ההרשאות יכולות לחסות קריאה, יצירה, שינוי ומחיקה של שורות.

00:09:43.420 --> 00:09:47.360
זה אומר שהגישה לא תלויה בכך שמישהו יזכור אילו כפתורים להסתיר בכל אפליקציה.

00:09:47.520 --> 00:09:49.380
ההרשאות נמצאות עם הנתונים עצמם.

00:09:49.540 --> 00:09:52.720
כך שאותן גבולות גזרה חלים בכל מקום שבו נתוני דאטה ורס מופיעים.

00:09:52.880 --> 00:09:54.940
לאחר מכן ניתן לצמצם את הגישה עוד יותר.

00:09:55.140 --> 00:09:58.340
הבטחת רמת שורה קובעת אם אילו שורות בודדות אדם יכול לעבוד.

00:09:58.500 --> 00:10:00.880
איש מחירות עשוי לראות רק את הלקוחות שבבעלותו,

00:10:01.080 --> 00:10:04.180
בעוד מנהל מחירות יכול לראות שורות לקוחות בבעלות כל הצוות שלו.

00:10:04.180 --> 00:10:06.440
שני האנשים משתמשים באותה טבלת חשבונות.

00:10:06.580 --> 00:10:08.240
הם פשוט לא רואים את אותו נתח ממנה.

00:10:08.240 --> 00:10:12.400
המבנה הזה עוזר לאנשים להתמקד בעבודה שלהם תוך מתן המבט שהמנהלים צריכים.

00:10:12.580 --> 00:10:16.660
זה גם מפחית את הסיכוי שמישהו יפתח מידע על לקוח שאין לו סיבה לגשת אליו.

00:10:16.800 --> 00:10:19.080
מידע מסוים דורש הגנה הדוקה עוד יותר.

00:10:19.280 --> 00:10:22.500
הבטחת רמת עמודה יכולה להגן על עמודות בודדות בתוך טבלה.

00:10:22.500 --> 00:10:26.040
אולי משתמש יכול לפתוח שורת לקוח אך לא אמור לראות מזהה אישי,

00:10:26.220 --> 00:10:28.760
נתון שכר, פרטי בנק או הערה פיננסית פרטית.

00:10:28.760 --> 00:10:31.840
שורת הלקוח נשארת זמינה עבור העבודה שהם צריכים לבצע.

00:10:32.000 --> 00:10:33.900
העמודה המוגנת נשארת מוגבלת.

00:10:34.000 --> 00:10:38.220
עבור חברות גדולות יותר, יחידות עסקיות יכולות ליצור גבולות בין חלקי הארגון.

00:10:38.420 --> 00:10:42.900
חברה עשויה להפריד אזורים, חטיבות או חברות בנות שעובדות עם קבוצות לקוחות שונות.

00:10:42.900 --> 00:10:46.420
יחידות עסקיות עוזרות לעצב כיצד הגישה עובדת מעבר לגבולות אלו.

00:10:46.520 --> 00:10:48.980
זה לא אומר שכל עסק צריך מפת הבטחה מסובכת.

00:10:48.980 --> 00:10:51.640
צוות קטן עשוי להזדקק רק לכמה תפקידים ברורים.

00:10:51.800 --> 00:10:55.960
חברה גדולה עשויה להזדקק ליותר שכבות בגלל השוני בצוותים, בעזורים ובתחומי האחריות שלה.

00:10:56.080 --> 00:10:59.540
הנקודה היא שדטאברס יכולה להתאים את הגישה לאופן שבו העסק פועל בפועל.

00:10:59.540 --> 00:11:04.160
בקרת גישה מגינה על מי יכול להגיע לנתונים, אך כללים גם מגינים על איכות הנתונים עצמם.

00:11:04.280 --> 00:11:08.380
כלל עסקי יכול לחייב אדם להזין מספר טלפון לפני שמירת איש קשר חדש.

00:11:08.520 --> 00:11:11.680
הוא יכול לבדוק תנאי כגון דרישת סיבה בעת סגירת פנייה.

00:11:11.820 --> 00:11:15.240
הוא יכול גם לשנות את מה שהמשתמשים רואים בהתבסס על המידע שהם מזינים.

00:11:15.420 --> 00:11:18.060
אותו כלל חל על כל האפליקציות המשתמשות בטבלה זו.

00:11:18.060 --> 00:11:22.740
זה חשוב כי לא תרצה שהאפליקציה אחת תקבל נתונים לא מלאים בזמן שהאפליקציה אחרת תדחה אותם.

00:11:22.840 --> 00:11:26.380
הכלל שייך למידע העסקי לא למסך ספציפי שמציג אותו במקרה.

00:11:26.380 --> 00:11:31.060
דייטוורס יכולה גם להריץ לוגיקה מאחורי הקלעים כדי לעזור לשמור על תהליכים עסקיים עקביים.

00:11:31.260 --> 00:11:33.020
הפרט שצריך לזכור הוא פשוט.

00:11:33.200 --> 00:11:35.740
הנתונים מגיעים עם כללים לא רק כאיכסון.

00:11:35.740 --> 00:11:41.380
לכן, התשתית כוללת את המידע, האנשים המורשים לעבוד איתו, והכללים ששומרים עליו שמיש.

00:11:41.520 --> 00:11:47.900
ברגע שדיינמיקס 365 עובדת על אותה תשתית, היא לא זקוקה לגשר מסורתי רק כדי להגיע לנתונים העסקיים שלה.

00:11:48.020 --> 00:11:50.940
מה משמעות האינטגרציה של דיינמיקס 365 בפועל?

00:11:50.940 --> 00:11:57.360
רוב האנשים שומעים אינטגרציה של דיינמיקס 365 עם דייטוורס ומדמיינים שתי מערכות נפרדות המחוברות באמצעות מחבר.

00:11:57.360 --> 00:12:05.440
מערכת אחת מחזיקה את נתוני הלקוח, מערכת אחרת זקוקה לאותק, אז מי שהוא מגדיר סינקרון, מחכה שירוץ ומקווה ששום דבר לא ייקשל בדרך.

00:12:05.580 --> 00:12:08.080
התמונה הזו הגיונית עבור הרבה כלים עסקיים.

00:12:08.280 --> 00:12:15.500
אבל הנה העניין, עבור דיינמיקס 365 סיילס ודיינמיקס 365 קסטומר סארוויס, החיבור הרבה יותר קרוב מזה.

00:12:15.500 --> 00:12:19.100
אפליקציות אלו משתמשות בדטוורס כתשתית הנתונים המשותפת שלהן.

00:12:19.220 --> 00:12:23.920
הן אינן מסדי נתונים נפרדים המעבירים שורות לקוחות הלוך ושוב רק כדי להבין זה את זה.

00:12:24.080 --> 00:12:26.200
הן עובדות עם אותו מידע עסקי מההתחלה.

00:12:26.440 --> 00:12:34.140
המשמעות היא, אתה איש מחירות ואתה יוצר חברה חדשה בדיינמיקס 365 סיילס.

00:12:34.240 --> 00:12:37.180
אתה מוסיף את איש הקשר הראשי ומתחיל לעבוד על עסקה אפשרית.

00:12:37.360 --> 00:12:41.080
הפרטים הללו הופכים מיד לחלק מהנתונים המשותפים שהאפליקציה משתמשת בהם.

00:12:41.080 --> 00:12:43.200
מאוחר יותר אותו לקוח פונה לתמיכה.

00:12:43.320 --> 00:12:46.760
נציג התמיכה יכול לעבוד עם אותם פרטי חברה ואיש קשר בדיוק.

00:12:46.940 --> 00:12:51.580
אף אחד לא צריך לייצר רשימה מהמחירות או ליצור את הלקוח שוב בתוך כלי תמיכה נפרד.

00:12:51.720 --> 00:12:56.900
הנציג פשוט מחבר את פניית התמיכה לאותו לקוח ורואה את ההיסטוריה שעוזרת לו להבין מה קורה.

00:12:57.060 --> 00:12:58.500
המחירות רואות את העסקה.

00:12:58.640 --> 00:13:01.860
התמיכה רואה את הפנייה ושני הצוותים עובדים סביב אותו לקוח.

00:13:02.080 --> 00:13:06.240
זה לא אומר שכל מסך נראה זהה או שכל צוות עוקב אחרי אותו תהליך.

00:13:06.240 --> 00:13:12.700
המחירות זקוקות ללידים, הזדמנויות, שיחות ופגישות, שירות לקוחות זקוק לפניות, תורים והיסטוריית שירות.

00:13:12.820 --> 00:13:16.680
כל אפליקציית דיינמיקס 365 מספקת לאנשים כלים מובנים עבור תפקידם.

00:13:16.820 --> 00:13:19.960
בזמן שהמידע העסקי שמתחת יכול להתחבר לכל מקום שצריך.

00:13:20.100 --> 00:13:25.860
הבסיס המשותף הזה הוא מה שאנשים מתכוונים אליו לרוב כשהם מדברים על אינטגרציה של דיינמיקס 365 ודטאברס.

00:13:26.020 --> 00:13:29.400
זה לא עוסק רק בהעברת נתונים מנקודה א' לנקודה בית,

00:13:29.400 --> 00:13:33.620
אלא באפליקציות שעובדות עם אותן שורות, קשרים, חוקים ובקרות גישה.

00:13:33.720 --> 00:13:37.220
מההתחלה, אפשרו למשרדים לעבור דרך מסע מחירות פשוט.

00:13:37.380 --> 00:13:40.240
ליד, ליד, מגיע מאתר אינטרנט או מאירוע.

00:13:40.400 --> 00:13:45.720
איש מחירות עובד עם הליד הזה, לומד עליו יותר, והופך אותו לקשר עסקי ולהזדמנות.

00:13:45.940 --> 00:13:49.800
שיחות, אימיילים, פגישות ומשימות יכולים כולם להתחבר לעבודה הזו.

00:13:49.900 --> 00:13:53.820
כך, הצוות לא צריך לחפש בחלים נפרדים כדי להרכיב את התמונה המלאה.

00:13:53.820 --> 00:13:58.400
אם הלקוח זקוק לעזרה בהמשך, פניית תמיכה יכולה להתחבר חזרה לאותו לקוח.

00:13:58.600 --> 00:14:01.320
סוכן התמיכה לא רואה רק שם וכתובת אימייל.

00:14:01.800 --> 00:14:05.240
הוא יכול לעבוד בהקשר של קשר הלקוח שכבר מזוהה.

00:14:05.380 --> 00:14:12.160
בינתיים, צוות המחירות יכול לראות של הלקוח יש בעיית שירות פתוחה ולהימנע משיחת חידוש ללא ידיעת הבעיות הקודמות שלו.

00:14:12.300 --> 00:14:15.100
קשר לקוח אחד יכול לתמוך בסוגים שונים של עבודה.

00:14:15.100 --> 00:14:18.780
זה הרבה יותר שימושי מסתם לשמור שם לקוח תואם בשתי מערכות.

00:14:18.780 --> 00:14:23.020
ואולי תשמעו גם את המונח מודל נתוני משותף שלעיתי מקוצר ל-CDM.

00:14:23.140 --> 00:14:26.200
אל תתנו לשם הזה לגרום לזה להישמע מסתורי יותר ממה שזה.

00:14:26.380 --> 00:14:31.240
זה פשוט אומר שמייקרוסופט מספקת דפוסי תבלאות עסקיות נפוצות לדברים שחברות רבות עוקבות אחריהם,

00:14:31.420 --> 00:14:33.480
כמו חשבונות, אנשי קשר, פעילויות ופניות.

00:14:33.640 --> 00:14:37.920
דפוסים אלו מעניקים לאפליקציות המבוססות על דיינמיקס 365 ודטאברס שפה התחלתית משותפת.

00:14:37.920 --> 00:14:39.700
חשבון, אקאונט, מייצג חברה.

00:14:39.700 --> 00:14:44.320
איש קשר, קונטקט, מייצג אדם, פעילות, אקטיביטי, עוקבת אחר עבודה סביב קשר עסקי.

00:14:44.460 --> 00:14:48.580
ניתן להתאים את ההגדרות עבור החברה שלכם ולהוסיף תבלאות משלכם במידת הצורך,

00:14:48.740 --> 00:14:50.360
מבלי להתחיל מדף חלק בכל פעם.

00:14:50.540 --> 00:14:54.280
כשישומי אחד מבין תבלת חשבונות ואיסום אחר משתמש באותה תבלה,

00:14:54.620 --> 00:14:56.860
שניהם מתייחסים לאותו סוג של מידע עסקי.

00:14:56.860 --> 00:14:58.640
זה גם משנה את מה שניתן לבנות.

00:14:58.640 --> 00:15:02.140
נניח שצוות השטח שלכם זקוק לאפליקציה פשוטה כדי לחפש לקוח,

00:15:02.380 --> 00:15:04.260
לאשר ביקור ולהוסיף הערה לאחר הפגישה.

00:15:04.400 --> 00:15:08.740
ניתן לבנות פאוור אפ שעובד עם אותן תבלאות דייטוורס שכבר נמצאות בשימוש בדיינמיקס 365.

00:15:09.260 --> 00:15:12.700
אין צורך לייצא את הלקוחות לרשימה חדשה רק עבור אותה אפליקציה.

00:15:12.700 --> 00:15:16.920
איש השטח פותח את האפליקציה, מוצא את הלקוח ומעדכן את פרטי הביקור.

00:15:16.920 --> 00:15:21.700
הנתונים נשארים מקושרים לקשר עם הלקוח שבו המחירות או שירות הלקוחות כבר משתמשים,

00:15:21.920 --> 00:15:23.880
בחפוף לכללי ההבטחה שסקרנו קודם.

00:15:24.060 --> 00:15:27.300
עבור עבודה עסקית מובנית יותר, ניתן לבנות אפליקציה מונחת מודל.

00:15:27.460 --> 00:15:29.620
אפליקציה מונחת מודל מתחילה במודל נתונים.

00:15:29.620 --> 00:15:32.620
אתם בוחרים את תבלאות האדטוורס, מגדירים את היחסים ביניהן,

00:15:32.700 --> 00:15:34.840
מקימים תפסים ותצוגות ומכילים תפקידי הבטחה.

00:15:34.840 --> 00:15:38.640
לאחר מכן, Power Apps משתמשת במבנה הזה כדי ליצור חוויית אפליקציה עסקית מתפקדת.

00:15:38.800 --> 00:15:42.600
חישבו על זה כסידור של שולחן עבודה סביב הכלים והחומרים שהצוות שלכם באמת משתמש בהם.

00:15:42.640 --> 00:15:44.140
הטבלאות מתארות את העבודה.

00:15:44.340 --> 00:15:45.900
יחסים מחברים בין החלקים.

00:15:45.900 --> 00:15:48.560
תפסים נותנים לאנשים מקום להזין ולזכור פרטים.

00:15:48.700 --> 00:15:51.380
תצוגות עוזרות להם למצוא את השורות שדורשות תשומת לב.

00:15:51.480 --> 00:15:53.960
אבטחה קובעת מה כל אדם יכול לפתוח או לשנות.

00:15:53.960 --> 00:15:58.700
אפליקציה מונחת מודל יכולה לפעול לצד Dynamics 365 מכיוון ששתיהן עובדות עם DataVars.

00:15:58.840 --> 00:16:02.140
אולי Dynamics 365 Sales מטפלת בתהליך המחירה המלא.

00:16:02.140 --> 00:16:06.700
בעוד אפליקציה מונחת מודל קטנה יותר נותנת למנהלי חוזים מקום ממוקד למעקב אחר הסכמי לקוחות.

00:16:06.820 --> 00:16:10.860
שתיהן יכולות לעבוד עם נתוני לקוחות קשורים מבלי ליצור מסד נתונים שני של לקוחות.

00:16:11.020 --> 00:16:13.220
כמובן, גישה זו עדיין דורשת זהירות.

00:16:13.220 --> 00:16:19.820
רק בגלל שהאפליקציה יכולה לעבוד עם טבלת DataVars, זה לא אומר שכל משתמש צריך לערוך כל שורה או לראות כל עמודה.

00:16:19.820 --> 00:16:23.620
גישה לשורות מבוססת תפקידים וכללים עסקיים עדיין שולטים במה שקורה.

00:16:23.740 --> 00:16:30.020
אפליקציית שטח יכולה לתת למי שהוא בדיוק את פרטי הלקוח והפעולות שהוא צריך, מבלי לחשוף את שאר נתוני החברה.

00:16:30.140 --> 00:16:35.740
אז השילוב של Dynamics 365 עם DataVars הוא כעת כבל שמחבר בין שני חדרים מרוחקים.

00:16:35.740 --> 00:16:41.540
ישומי Dynamics 365, אפליקציות מותאמות אישית ותהליכים עסקיים יכולים כולם לעבוד מאותו בסיס משותף.

00:16:41.620 --> 00:16:44.180
ברגע שרואים זאת, השאלה הבאה הופכת ברורה.

00:16:44.560 --> 00:16:49.680
מה עוד יכול להשתמש באותו עדכון לקוח ברחבי הפלטפורמה המחוברת של מייקרוסופט?

00:16:49.840 --> 00:16:52.560
איך הפלטפורמה המחוברת עובדת בעבודה אמיתית?

00:16:52.740 --> 00:16:56.420
עדכון לקוח משותף הופך שימושי כאשר הכלים סביבו יכולים להגיב.

00:16:56.420 --> 00:17:02.320
Power Automate מטפל בעבודת ההמשך על ידי המתנה לשינוי בשורת DataVars והפעלת פעולה כאשר שינוי כזה קורה.

00:17:02.460 --> 00:17:05.420
לדוגמה, ליד חדש נכנס ל-Dynamics 365 Sales.

00:17:06.140 --> 00:17:10.940
זרימת עבודה יכולה להודיע לאיש המחירות שהוקצה, לפרסם הודעה ב-Teams או ליצור משימת המשך.

00:17:11.080 --> 00:17:14.040
אף אחד לא צריך להשגיח על תיבת דואר נכנס משותפת כל היום.

00:17:14.200 --> 00:17:17.040
הליד משתנה והשלב הבא מתחיל באופן אוטומטי.

00:17:17.160 --> 00:17:21.720
Power Automate לא זקוק לאותק נפרד של הליד רק כדי לבצע את העבודה הזו.

00:17:21.720 --> 00:17:27.000
הוא יכול להגיב לשורה ב-Dataverse תוך שימוש באותם פרטי לקוח ובעלות שבהם משתמש את אפליקציית המחירות,

00:17:27.200 --> 00:17:32.600
וזה שומר על האוטומציה הקרובה לתהליך העסקי במקום להסתמך על מישהו שיצא קובץ ויתחיל שרשרת מיילים ידני.

00:17:32.780 --> 00:17:34.240
אחר כך יש את Power Buy.

00:17:34.460 --> 00:17:37.340
מנהל מחירות עשוי לרצות לראות את צנרת המחירות הנוכחית.

00:17:37.540 --> 00:17:40.780
מנהל שירות לקוחות עשוי להזדקק לראות כמה פניות הגיעו השבוע,

00:17:40.780 --> 00:17:44.640
אילו פניות עדיין פתוחות או אילו לקוחות פונים לתמיכה בתדירות הגבוהה ביותר.

00:17:44.740 --> 00:17:47.300
Power Buy יכול להפיק דוחות על נתונים עסקיים מ-Dataverse,

00:17:47.540 --> 00:17:52.600
כך שהצוותים יכולים לראות את העבודה המתבצעת ללא צורך ביצירת דוחות אקסל חדשים בכל יום שישי אחר הצהריים.

00:17:52.760 --> 00:17:55.600
הדוח נשען על הנתונים העסקיים שאנשים כבר משתמשים בהם.

00:17:55.700 --> 00:17:58.980
משמעות הדבר היא שתרשים תהליך המחירה יכול להשתנות ככל שהזדמנויות מתקדמות.

00:17:58.980 --> 00:18:02.900
לוח מכוונים של פניות יכול להציג את עומס העבודה הנוכחי בזמן שהנציגים מעדכנים את הפניות.

00:18:03.060 --> 00:18:07.120
הנקודה היא שלוח מכוונים מחליף את הצורך של אנשים לבדוק את הפרטים בעצמם,

00:18:07.240 --> 00:18:11.440
ומעניק להם תמונה ברורה יותר של העבודה לפני שהם מחליטים מה דורש תשומת לב.

00:18:11.580 --> 00:18:14.120
Power Apps מוסיף נתיב נוסף לאותו תהליך.

00:18:14.260 --> 00:18:17.140
תארו לעצמכם עובד שטח שמגיע לאתר של לקוח.

00:18:17.320 --> 00:18:21.060
הוא לא זקוק לחוויה המלאה של Dynamics 365 Sales.

00:18:21.060 --> 00:18:26.780
ייתכן שהוא רק צריך למצוא את הלקוח, לעיין בפרטי הביקור, לאשר מה קרה ולהוסיף הערה או תמונה.

00:18:26.960 --> 00:18:30.400
אפליקציית Power App ממוקדת יכולה לספק לו את החוויה המצומצמת הזו.

00:18:30.520 --> 00:18:33.560
צוות לקוחות עשוי להזדקק לאפליקציה לבדיקת הסכמי לקוחות.

00:18:33.740 --> 00:18:36.320
מנהל עשוי להזדקק לאפליקציה פשוטה לאישור בקשות.

00:18:36.500 --> 00:18:41.260
כל אפליקציה יכולה להתמקד במשימה אחת בזמן שהיא עובדת עם אותם נתוני Dataverse מבוקרים מאחורי הקלעים.

00:18:41.260 --> 00:18:43.760
המשתמש רואה את הכלי שמתאים ליום העבודה שלו.

00:18:43.840 --> 00:18:45.580
העסק שומר על המידע המקושר.

00:18:45.700 --> 00:18:48.080
לפעמים המידע הזה מתחיל מחוץ לדטאברס.

00:18:48.260 --> 00:18:52.600
לחברה עשויה להיות רשימה ממקור מקוון שצריכה להפוך לחלק מהנתונים העסקיים שלה.

00:18:52.720 --> 00:18:55.740
Power Query יכול ליבא נתונים ממקורות מקוונים נתמכים,

00:18:56.000 --> 00:18:59.520
לנקות אותם במהלך העיבוב ולטעון אותם לטבלה הנכונה בדטאברס.

00:18:59.680 --> 00:19:05.060
זה שימושי כאשר מקור חיצוני מכיל מידע שהכלים של Dynamics וPower Platform צריכים להשתמש בו.

00:19:05.060 --> 00:19:09.540
עדיין עליך להחליט מה שייך לדטאברס וכיצד הוא אמור להתחבר לטבלהות הקיימות.

00:19:09.660 --> 00:19:13.560
ייבון נתונים ללא מחשבה מקדימה פשוט מעביר את הבלבול למיקום חדש.

00:19:13.740 --> 00:19:16.340
בואו נחבר את החלקים לזרימת עבודה יומיומית אחת.

00:19:16.520 --> 00:19:18.760
ליד חדש נכנס לתוך Dynamics 365.

00:19:19.240 --> 00:19:23.160
חוק הקצאה בודק מי צריך להיות הבעלים של הליד, אולי בהתבסס על אזור המוצר.

00:19:23.180 --> 00:19:26.000
הבעלים מקבל הודעה בטימס דרך זרימת עבודה של Power Automate,

00:19:26.180 --> 00:19:27.560
כך שהוא יודע שיש עבודה שממתינה לו.

00:19:27.560 --> 00:19:30.880
כאשר איש המחירות מעדכן את הליד ומקדם אותו בתהליך המחירה,

00:19:31.080 --> 00:19:34.600
לוח המכוונים של Power Buy משתנה כדי להציג לצוות את הסטטוס העדכני.

00:19:34.720 --> 00:19:37.120
עדכון אחד מפעיל עבודה מועילה בכמה מקומות.

00:19:37.280 --> 00:19:39.800
Power Automate מעביר עבודה משלב אחד למשנהו.

00:19:39.900 --> 00:19:42.020
Power Buy עוזר לאנשים לראות את העבודה.

00:19:42.180 --> 00:19:45.140
Power Apps נותן לצוותים ספציפיים דרך ממוקדת לקחת חלק.

00:19:45.340 --> 00:19:49.720
Dataverse שומר על המידע העסקי מאורגן ומאובטח בזמן שהכלים האלו מבצעים את עבודתם.

00:19:49.860 --> 00:19:51.280
להבדל הזה יש חשיבות.

00:19:51.280 --> 00:19:55.620
אוטומציה היא לא מערכת התיוק ולוח מכוונים הוא לא מסד הנתונים של הלקוחות.

00:19:55.680 --> 00:19:59.040
לכל כלי יש תפקיד נפרד, אך כולם יכולים לעבוד מאותו מקור נתונים.

00:19:59.240 --> 00:20:01.360
הידיעה הזו עוזרת לך לבחור את הכלי הנכון,

00:20:01.480 --> 00:20:05.800
במקום להתייחס לכל גיליון אלקטרוני או רשימה פשוטה כאילו הם צריכים לנהל תהליך עסקי שלם.

00:20:06.680 --> 00:20:09.080
מתי Dataverse מתאים ומה הוא לא מחליף?

00:20:09.540 --> 00:20:10.320
הנה העניין.

00:20:10.500 --> 00:20:14.420
בחר בדטאברס כאשר אנשים ואפליקציות מרובים צריכים לעבוד עם נתונים עסקיים מקושרים.

00:20:14.420 --> 00:20:17.380
אתה זקוק לכללי גישה ברורים ולתהליכים שניתן לחזור עליהם.

00:20:17.500 --> 00:20:20.060
Dataverse מטפל בזה, אבל הוא לא מחליף את כל השאר.

00:20:20.180 --> 00:20:23.480
אקסל הוא עדיין הבחירה המועדפת עליך לניתוח אישי ולרשימות מהירות.

00:20:23.640 --> 00:20:26.280
רשימות SharePoint עובדות היטב למעקב צוותי פשוט,

00:20:26.460 --> 00:20:28.560
ואם אתה מפתח שזקוק לשליטה עמוקה,

00:20:28.820 --> 00:20:30.160
סיכואל נותר בחירה חזקה.

00:20:30.260 --> 00:20:31.980
אז מתי Dataverse באמת מתאים?

00:20:32.160 --> 00:20:34.780
כשהנתונים שלך צריכים להתחבר לדיינמיקס 365,

00:20:34.780 --> 00:20:36.940
לאפליקציות, לאוטומציה ולדוחות,

00:20:37.060 --> 00:20:38.040
מבלי ליצור עותק נוסף.

00:20:38.180 --> 00:20:39.360
שם הוא באמת זורח.

00:20:39.580 --> 00:20:42.320
סיכום, תשתית אחת, כלים עסקיים רבים.

00:20:42.800 --> 00:20:44.300
אז השורה התחתונה היא זו.

00:20:44.460 --> 00:20:47.300
דיינמיקס 365 ודטאברס עובדים בצורה הטובה ביותר

00:20:47.300 --> 00:20:49.480
כשכל הנתונים, הכללים, ההבטחה, האפליקציות,

00:20:49.640 --> 00:20:51.740
האוטומציה והדוחות שלך החולקים בסיס משותף אחד.

00:20:51.740 --> 00:20:54.780
הרשם למיקרוסופט Knowledge Nuggets ב-M365FM

00:20:54.780 --> 00:20:56.100
לקבלת מדריכים פשוטים נוספים

00:20:56.100 --> 00:20:59.360
על דיינמיקס 365, פאוור פלטפורם ומיקרוסופט 365.

00:20:59.820 --> 00:21:02.400
לאחר מכן צפה בפרק שלנו על אפליקציות מונחות מודל

00:21:02.400 --> 00:21:05.340
כדי לראות כיצד טבלאות דייטאברס הופכות לאפליקציה עסקית עובדת.