Selamat datang di Microsoft Nugget. Saya Mirko Peters. Topik hari ini seringkali membingungkan banyak orang. Apa sebenarnya Dataverse itu? Apakah itu bahasa data aplikasi atau layanan Dynamics 365 tersembunyi yang hanya perlu dipahami staff IT? Ini definisi yang paling sederhan. Dataverse adalah fondasi data bersama dibalik banyak pengalaman Dynamics 365. Bayangkan Dynamics di garung kantor, penjualan, layanan pelanggan, dan aplikasi lain adalah ruangan tempat orang bekerja, sementara Dataverse adalah sistem pengarsipan dan aturan dibalik dindingnya. Di akhir episode ini, Anda akan tahu di mana Data Dynamics berada dan bagaimana satu pembaraan pelanggan bisa muncul dalam pekerjaan penjualan, otomatisasi, dan pelaporan. Namun sebelum kita membahas nama produk, mari mulai dengan masalah bisnis yang diselesaikannya. Satu tempat bersama. Bukan seringan yang terpisah-pisah. Bayangkan sebuah perusahaan dengan tim penjualan, tim dukungan, dan tim keuangan. Penjualan menyimpan detail pelanggan di spreadsheet. Tim dukungan bekerja di alat penguruan kasus yang terpisah. Tim keuangan memiliki nama pelanggan di sistemnya sendiri. Orang lain menyimpan rangkaian email di kotak surat bersama, sementara orang lain menyimpan catatan di folder yang tidak bisa ditemukan siapapun. Pelanggan sama kini ada di matempat berbeda. Pengaturan itu terasa normal pada awalnya, karena setiap tim hanya melihat bagian pekerjaan di permata mereka saja. Namun masalahnya, segera setelah pelanggan mengubah nama telepon, alamat, nama perusahaan, atau kontak utama mereka, masalah pun dimulai. Penjualan memperbarui spreadsheet, dukungan tidak melihatnya, keuangan masih mengirim dokumen ke alamat lama. Lalu seseorang mengekspor daftar, merapikannya secara manual, mengirimnya lewat email, dan tiba-tiba tiga orang meyakini salinan mereka masing-masing adalah yang paling benar. Daftar mana yang harus Anda percaya? Pertanyaannya itu membuang lebih banyak waktu daripada yang adik. Tapi nanti bekerja untuk membandingkan catatan. Manager bertanya mengapa laporan tidak cocok dengan sistem penjual. Agen dukungan membuka kasus untuk pelanggan yang detailnya sudah ada di tempat lain hanya sedikit. Berbeda, tidak ada yang berniat menciptakan kacau. Kacauan itu muncul kanaknya. 20 tahun lalu, sistem terpisah berarti server terpisah, basis data terpisah, dan tim terpisah yang menyimpan informasinya sendiri. Menghubungkannya, membutuhkan pekerjaan custom, importer jadwal, dan banyak pemeriksaan manual. Perubahan di suatu tempat mungkin sampai ke sistem lain besok, minggu depan, atau tidak sama sekali. Dataverse memberi aplikasi bisnis tempat bersama untuk jenis informasi ini. Singkatnya, Dataverse adalah platform data cloud Microsoft untuk informasi bisnis. Ia menyimpan informasi tersebut dalam tabel terstruktur, sehingga data memiliki bentuk yang jelas alih-alih hanya berupa catatan acak, file lepas, dan tab spreadsheet yang terputus. Anda bisa menganggapnya sebagai lemari arsip perusahaan yang dapat digunakan oleh beberapa perangkat resmi secara bersama. Seorang pelanggan muncul sekali Dataverse. Pelanggan tersebut bisa muncul di Dynamics 365 Customer Service mengerjakan kesepakatan. Detail pelanggan yang sama bisa muncul di Dynamics 365 Customer Service saat agen menangani permintaan dukungan. Power App dapat menggunakan informasi pelanggan yang sama untuk pekerja lapangan atau manajer akun tanpa harus menyalin data ke aplikasi baru terlebih dahulu. Satu baris pelanggan, satu titik referensi bersama. Ini tidak berarti setiap tim tiba-tiba bisa melihat segalanya. Akses tetap memerlukan aturan dan kita akan membahasnya sebentar. Artinya aplikasi resmi dapat bekerja dari informasi bisnis yang sama alih-alih membangun versinya sendiri yang tumpang tindih. Ilah sebabnya Dynamics 365 dan Dataverse sangat cocok satu sama lain. Aplikasi Dynamics 365 seperti Sales dan Customer Service menggunakan Dataverse untuk menyimpan dan mengamankan data yang mereka kelola. Namun begini, saat seseorang berbicara tentang integrasi Dynamics 365 dengan Dataverse, mereka sering membayangkan dua produk terpisah yang memerlukan konektor di antaranya. Untuk banyak aplikasi Dynamics 365, situasinya tidak seperti itu. Datanya sudah ada dalam Dataverse. Anda tidak perlu menarik daftar pelanggan dari Dynamics 365, menyalahnya ke basis data lain dan berharap kedua sisi tetap sinkron. Anda dapat membangun di atas fundasi yang sama menggunakan informasi bisnis yang sudah digunakan oleh Dynamics 365. Hal itu mengubah pembicaraan kita. Alih-alih bertanya, bagaimana cara menyingkronkan kedua daftar pelanggan ini? Anda bisa bertanya siapa saja orang dan aplikasi yang perlu bekerja dengan catatan pelanggan ini dan apa saja yang boleh mereka lakukan. Saat ini, Dataverse tidak menggantikan setiap sistem yang diperusahaan. Bisnis mungkin masih menggunakan perangkat lunak keuangan, alat industri, sistem kudang, situs web, atau aplikasi lama yang memiliki datanya sendiri. Dataverse bukanlah perkat ajaib yang menghapus setiap sistem luar dalam semalam. Yang ia berikan adalah tempat umum bagi data bisnis yang perlu dibagikan oleh aplikasi-aplikasi yang terubah. Detail pelanggan, pekerjaan penjualan, dukungan, tugas, dan tindak lanjut. Catatan-catatan tersebut bisa tersimpan bersama dalam satu sumber yang dapat dibaca dan berbeda berangkat. Jadi mari buka lemari arsip itu bersama saya. Setelah Anda melihat bagaimana Dataverse mengatur informasi di dalamnya, keseluruhan koneksi Dynamics 365 akan jauh lebih mudah dipahami. Lemari arsip, tabel, baris, kolom, dan relasi. Mari kita buka lemari arsip itu. Di dalam Dataverse, informasi tersimpan dalam tab. Bayangkan seperti lemari sungguhan dengan laci-laci yang terpisah. Satu laci menyimpan perusahaan, yang lain menyimpan orang, dan yang ketiga menyimpan permintaan dukungan. Anda tidak membuang setiap kertas ke dalam satu laci besar dan berharap seseorang bisa merapikannya Anda. Setiap laci memiliki tugasnya masing-masing. Jadi Dataverse sebuah tabel menampung satu jenis informasi bisnis. Tabel akun biasanya menampung perusahaan tempat Anda bekerja sama. Tabel kontak menampung data perorangan. Tabel prospek menampung calon pelanggan sebelum mereka menjadi pelanggan nyata. Tabel kasus menampung permintaan dukungan. Sementara tabel aktivitas dapat melacak pekerjaan seperti panggilan, seperti panggilan, suril, janji temu, dan tugas. Itu adalah tabel standar. Microsoft menyertakannya, karena sebagian besar bisnis perlu melacak pelanggan, orang, pekerjaan, dan pecakap. Anda tidak perlu repot membuat tabel baru untuk sesuatu yang umum jika tabel standar sudah sesuai untuk tugas tersebut. Namun setiap perusahaan juga memiliknya sendiri. Perusahaan pelatihan mungkin perlu melacak kursus dan sertifikat. Bisnis properti mungkin memerlukan data gedung, unit, dan inspeksi. Produsen mungkin melacak pemeriksaan peralatan atau kunjungan layanan. Dalam kasus tersebut, Anda dapat membuat tabel kustom yang sesuai dengan pekerjaan yang sebenarnya dari perusahaan Anda. Bayangkan tabel kustom seperti menambahkan laci baru ke lemari, lalu memberinya label yang jelas. Sekarang setiap tabel berisi baris. Satu baris adalah satu item di dalam laci tersebut. Misalnya, satu baris di tabel kontak bisa mewakili Maria Gomez seseorang di perusahaan pelanggan. Barisnya menyimpan detail pribadinya, terpisah dari semua kontak lain di sistem. Kolom menjelaskan detail yang ingin Anda simpan untuk setebut. Baris kontak Maria mungkin memiliki kolom untuk nama depan, nama belakang, alamat surel, nomer telepon, jabatan, perusahaan, perusahaan, pemilik data, dan status. Kolom menentukan jenis informasi yang sesuai di tempat tersebut sehingga kolom surel mengharapkan alamat surel dan kolom status dapat menampung pilihan status yang disetujui. Begitulah cara informasi bisnis mendapatkan bentuk yang andal. Tanpa kolom, satu orang mungkin mengetik nomor telepon di kotak catatan, orang lain mungkin menambahkannya ke kolom nama, dan orang lain mungkin tidak memasukkannya sama sekali. Dengan tabel kontak yang jelas, semua orang bekerja dengan kumpulan detail yang sama di tempat yang sama. Struktur tersebut juga membantu aplikasi memahami datanya. Sebuah formulir dapat menampilkan kotak yang tepat, laporan dapat mengelompokkan kontak berdasarkan status, dan otomatisasi dapat bereaksi saat pemilik beru. Informasi tidak hanya disimpan begitu saja, tetapi memiliki label yang memberi tahu alat yang terhubung tentang artis setiap bagian. Mulailah dengan tabel standar kapanpun tabel tersebut sesuai dengan kebutuhan bisnisan. Jika Anda menjual ke perusahaan, akun dan kontak sudah mendeskripsikan pola yang dipahami sebagian besar orang. Jika Anda menangani dukungan pelanggan, kasus memberi Anda titik awal. Kemudian, tambahkan tabel kustom hanya jika bisnis Anda memiliki informasi yang tidak sesuai dengan pola bawaan. Ini menghindari masalah umum, yaitu membuat lima tabel berbeda yang semuanya berarti pelanggan. Satu tim menyebutnya klien, tim lain menyebutnya master pelanggan, tim ketiga menyebutnya kontak mitra.io. Segera orang tidak tahu tabel mana yang harus mereka gunakan. Tabel standar yang jelas dan tabel kustom dengan nama yang tepat membuat lemari ini tetap mudah dipahami saat lebih banyak orang mengembangkan. Bagian selanjutnya adalah saat laci-laci tersebut mulai bekerja bersama. Sebuah kontak menjadi milik sebuah akun. Maria bekerja untuk contoso LPD. Daripada mengetik ulang alamat, nomor telepon utama, dan detail perusahaan contoso ke dalam baris Maria, dataverse dapat membuat hubungan antara tabel kontak dan tabel akun. Maria tertaut ke contoso, dan tautan itu penting karena informasi perusahaan tersebut pada perusahaan tersebut. Jika contoso mengubah alamat kantor, seseorang cukup memperbarui baris akun sekali saja, setiap kontak terkait tetap dapat merujuk ke perusahaan yang sama tanpa harus membawa salinah sendiri. Hubungan juga menghubungkan kasus dukungan dengan pelanggan yang mengajukannya. Hubungan dapat menghubungkan peluang penjualan dengan panggilan, email, rapat, dan tugas seputar kesepakatan tersebut. Saat tenaga penjual membuka peluang, mereka dapat melihat aktivitas yang terhubung dengannya alih-alih mencari melalui catatan dan kalender yang tidak relevan. Informasi tersebut memiliki kontak. Anda tidak hanya melihat nomor kasus, Anda melihat pelanggan mana yang memilikinya. Anda tidak hanya melihat kontak, Anda dapat melihat perusahaan yang terhubung dengan orang tersebut. Tautan tersebut menjaga data tetap berguna tanpa perlu mengetik ulang fakta yang sama di beberapa tempat. Satu catatan kecil mengenai penaman sebelum Anda membaca panduan lama atau menonton video lama. Anda mungkin mendengar kata entitas bidang rekam. Itu adalah istilah data verse yang lebih lama. Microsoft sekarang menggunakan tabel alih-alih entitas, kolom alih-alih bidang, dan baris alih rekam. Artinya tidak berubah. Panduan lama yang menyuruh Anda membuat entitas sebenarnya berbicara tentang membuat tabel, bidang adalah kolom, dan rekam adalah baris. Mengetahui kedua rangkaian kata tersebut mencegah Anda mengira telah menemukan produk yang berbeda. Jadi, tabel mengatur informasi dan hubungan menghumpungkannya. Namun lemari yang teratur tetap memerlukan kontrol. Seseorang harus memutuskan apa yang boleh dimasukkan, diubah, dan diakses oleh orang dengan aman. Aturan dan meja reseksionis. Data ribalik data verse hanya berfungsi jika orang yang tepat dapat mengerjakannya dengan aman. Perwakilan penjualan memerlukan detail pelanggan, agen dukungan memerlukan rewrite kasus, manajer memerlukan tampilan yang lebih luas, dan mitra eksternal mungkin hanya memerlukan akses ke bagian kecil dari proses tersebut. Mereka tidak seharusnya melihat informasi yang selalu. Pikirkan catatan pelanggan dengan catatan kontak pribadi, harga yang dinegosiasikan, dan kasus dukungan yang terbuka. Memberikan akses penuh kepada setiap pengguna akan menciptakan cepat. Membatasi semua orang terlalu ketat, sehingga mereka tidak bisa bekerja justru menciptakan masalah lain. Data verse memberi Anda kendali untuk hal. Dan kendali pertama dimulai dari identitas. Saat Anda masuk dengan akun perusahaan, Microsoft Enter ID akan mengidentifikasi Anda. Anggaplah Enter ID sebagai meja resepsionis di pintu masuk kantor. Anda tiba menunjukkan kartu pengenal, dan resepsionis memeriksa siapa Anda sebelum Anda bisa masuk. Data verse menggunakan identitas tersebut untuk mengetahui pengguna mana yang sedang bekerja dengan data. Data verse tidak berhenti hanya dengan bertanya apakah orang ini diizinkan masuk. Data verse juga bertanya, apa yang boleh dilakukan orang ini setelah mereka masuk? Disitulah peran keamanan berperan. Peran keamanan adalah sekumpulan izin yang ditautkan ke suatu pekerjaan atau tanggung jawab. Anda bisa membuat satu peran untuk staff penjualan, satu untuk aking layanan pelanggan, dan satu lagi untuk manajer. Sebagai contoh, seorang staff penjualan mungkin diizinkan untuk membaca, membuat, dan memperbarui akun kontak prospek dan peluang. Mereka mungkin tidak diizinkan untuk menghapus informasi pelanggan yang penting. Seorang agen dukungan mungkin dapat membuat dan memperbarui kasus tetapi tidak mengubah peluang menjual. Izin tersebut dapat mencakup membaca, membuat, mengubah, dan menghapus baris. Itu berarti akses tidak bergantung pada seseorang yang harus mengingat tombol mana yang harus disembunyikan di setiap aplikasi. Izin tersebut melekat pada data itu sendiri. Jadi batasan yang sama berlaku dimanapun data data verse tersebut muncul, kemudian Anda bisa mempersempit akses lebih jauh lagi. Keamanan tingkat baris menentukan baris individual mana yang dapat dikerjakan oleh seseorang. Staff penjualan mungkin hanya melihat pelanggan yang mereka miliki, sementara manajer penjualan dapat melihat baris pelanggan yang dimiliki oleh semua orang di tim mereka. Keduanya menggunakan tabel akun yang sama. Mereka hanya tidak melihat bagian yang sama dari tabel. Pengaturan itu membantu orang fokus pada pekerjaan mereka sendiri sambil mereka pendangan yang dibutuhkan menit. Hal ini juga mengurangi kemungkinan seseorang membuka informasi tentang pelanggan yang tidak perlu mereka akses. Beberapa informasi membutuhkan perlindungan yang lebih ketat. Keamanan tingkat kolom dapat melindungi kolom individual di dalam tabel. Mungkin seorang pengguna bisa membuka baris pelanggan tetapi tidak boleh melihat pengenal pribadi angka gaji detail bank atau catatan keuangan pribadi. Baris pelanggan tetap tersedia untuk pekerjaan yang perlu mereka akut. Kolom yang dilindungi tetap dibatasi. Untuk perusahaan yang lebih besar, unit bisnis dapat menciptakan batasan antar bagian organisasi. Sebuah perusahaan mungkin memisahkan wilayah divisi atau anak perusahaan yang bekerja dengan kelompok pelanggan yang berbeda. Unit bisnis membantu membentuk bagaimana akses pekerja di seluruh batasan tersebut. Ini tidak berarti setiap bisnis membutuhkan peta keamanan yang rumit. Tim kecil mungkin hanya memerlukan beberapa peran yang jelas. Perusahaan yang lebih besar mungkin butuh lebih banyak lapisan karena tim, wilayah, dan tanggung jawabnya berbeda. Intinya adalah data first dapat menyesuaikan akses dengan cara bisnis sebenarnya bekerja. Kontrol akses melindungi siapa yang dapat menjangkau data, tetapi aturan juga melindungi kualitas data itu sendiri. Aturan bisnis dapat mengharuskan seseorang, memasukkan nomor telepon sebelum menyimpan kontak baru. Aturan ini dapat memeriksa kondisi seperti mengharuskan adanya alasan saat suatu kasus di. Aturan ini juga dapat mengubah apa yang dilihat mengguna berdasarkan informasi yang mereka masukkan. Aturan yang sama berlaku di semua aplikasi yang menggunakan tabel tersebut. Ini penting karena Anda tidak ingin satu aplikasi menerima data yang tidak lengkap sementara aplikasi lain menolaknya. Aturan tersebut melekat pada informasi bisnis, bukan pada satu layar yang kebetulan menampilkan. Data first juga dapat menjalankan logika di balik layar untuk membantu menjaga konsistensi proses bisnis. Detail yang perlu Anda ingat sangat sederhana. Data hadir dengan aturan, bukan hanya penyimpanan. Jadi fondasinya mencakup informasi orang yang diizinkan bekerja dengannya dan aturan yang menjaganya tetap dapat digunakan. Setelah Dynamics 365 bekerja pada fondasi yang sama, ia tidak memerlukan jembatan tradisional hanya untuk menjangkau data bisnisnya sendiri. Apa arti integrasi Dynamics 365 sebenarnya? Kebanyakan orang mendengar integrasi Dynamics 365 dengan data first dan membayangkan dua sistem terpisah yang digabungkan oleh konektor. Satu sistem menyimpan data pelanggan, sistem lain memerlukan salinannya, jadi seseorang menyiapkan sinkronisasi, menunggu prosesnya berjalan, dan berharap tidak ada yang gagal. Gambaran itu masuk akal untuk banyak alat bisnis. Namun di sini, untuk Dynamics 365 Sales dan Dynamics 365 Customer Service koneksinya jauh lebih erat dari itu, aplikasi-aplikasi ini menggunakan data first sebagai fondasi data bersama mereka. Keduanya bukan dua basis data terpisah yang saling bertukar baris pelanggan hanya agar bisa saling memahami. Mereka bekerja dari informasi bisnis yang sama sejak awal. Mari kita buat lebih konkret. Bayangkan Anda seorang staff penjualan dan Anda membuat perusahaan baru di Dynamics 365 Sales. Anda menambahkan kontak utama dan mulai mengerjakan calon kesepakatan. Detail tersebut segera menjadi bagian dari data bersama yang digunakan aplikasi. Kemudian, pelanggan tersebut menghubungi dukungan. Agen dukungan dapat bekerja dengan detail perusahaan dan kontak yang persisam. Tidak ada yang perlu mengekspor daftar dari penjualan atau membuat ulang pelanggan di dalam alat dukungan terpisah. Agen cukup menghubungkan kasus dukungan ke pelanggan tersebut dan melihat riwayat yang membantu mereka memahami apa yang sedang terjadi. Sales melihat kesepakatan, dukungan melihat kasus, dan kedua tim bekerja di sekitar pelanggan yang sama. Hal ini tidak berarti setiap layar terlihat sama atau setiap tim mengikuti proses yang sama. Sales membutuhkan prospek, peluang, panggilan, dan rapat. Layanan pelanggan membutuhkan kasus, antrean, dan riwayat lain. Setiap aplikasi Dynamics 365 memberikan alat yang dirancang khusus untuk pekerjaan penguat. Meskipun informasi bisnis dibaliknya dapat terhubung kemanapun dibutuhkan. Fondasi bersama itulah yang sering dimaksud orang saat mereka berbicara tentang integrasi Dynamics 365 dan Dataverse. Ini bukan sekadar memindahkan data dari titik A ke titik B. Ini tentang bagaimana aplikasi bekerja dengan baris hubungan, aturan, dan kontrol akses yang sama sejak awal. Mari kita bahas perjalanan penjualan yang sederhana. Prospek masuk dari situs web atau sebuah acara. Seorang tenaga penjualan melindaklanjutnya prospek tersebut mempelajari orang tersebut dan mengubahnya menjadi hubungan pelanggan serta peluang. Panggilan, email, janji temu, dan tugas semuanya dapat terhubung ke pekerjaan tersebut. Jadi tim tidak perlu mencari di alat terpisah untuk menyusun ceritanya. Jika pelanggan nantinya memerlukan bantuan, kasus dukungan dapat terhubung kembali ke pelanggan yang sama. Agen dukungan tidak hanya melihat nama dan alamat email. Mereka dapat bekerja sesuai konteks dengan hubungan pelanggan yang telah teridentifikasi. Sementara itu, tim penjualan dapat melihat bahwa pelanggan memiliki masalah layanan yang terbuka dan menghindari pembicaraan pembaruan tanpa mengetahui adanya masalah. Satu hubungan pelanggan dapat mendukung berbagai jenis pekerjaan yang jauh lebih bermanfaat daripada sekadar menyamakan nama pelanggan di dua sistem. Anda mungkin juga mendengar istilah komandata modal yang terkadang singkat CDM. Jangan biarkan namanya terdengar lebih misterius daripada yang sebenarnya. Ini hanya berarti Microsoft menyediakan pola tabel bisnis umum untuk hal-hal yang dilacak banyak perusahaan seperti akun, kontak, aktivitas, dan kasus. Pola ini memberikan bahasa awal yang sama bagi aplikasi berbasis Dynamics 365 dan Dataverse. Akun berarti sebuah perusahaan, kontak berarti seorang individu. Aktivitas melacak pekerjaan terkait hubungan bisnis. Anda dapat menyesuaikan pengaturan untuk perusahaan Anda dan menambahkan tabel Anda sendiri jika diperlukan, tetapi Anda tidak perlu selalu mulai dari nol. Saat satu aplikasi memahami tabel akun dan aplikasi lain menggunakan tabel yang sama, keduanya merujuk pada jenis informasi bisnis yang sama. Hal ini juga mengubah apa yang dapat Anda bangun. Misalkan tim lapangan Anda membutuhkan aplikasi sederhana untuk mencari pelanggan, mengonfirmasi kunjungan, dan menambahkan catatan setelah janji temu. Anda dapat membangun power app yang bekerja dengan tabel Dataverse yang sama yang sudah digunakan oleh Dynamics 365. Tidak perlu mengekspor pelanggan ke daftar baru hanya untuk aplikasi tersebut. Pekerja lapangan membuka aplikasi mencari pelanggan dan memperbarui informasi kunjungan. Data tetap terhubung dengan hubungan pelanggan yang sudah digunakan tim penjualan atau layanan pelanggan sesuai aturan keamanan yang kita bahas sebelumnya. Untuk pekerjaan bisnis yang lebih terstruktur, Anda dapat membangun aplikasi berbasis. Aplikasi berbasis model dimulai dengan model Dataverse. Anda memilih tabel Dataverse, menentukan hubungan, mengatur formulir dan tampilan, serta menerapkan peran keamanan. Power Apps kemudian menggunakan struktur tersebut untuk menciptakan pengalaman aplikasi bisnis yang berfungsi. Bayangkan seperti menata meja kerja di sekitar alat dan bahan yang benar-benar digunakan tim Anda. Tabel mendeskripsikan pekerjaan, hubungan menghubungkan bagian-bagian. Formulir memberi orang cara untuk memasukkan dan meninjodik. Tampilan membantu mereka menemukan perhatian. Keamanan menentukan apa yang bisa dibuka atau diubah oleh setiap orang. Aplikasi berbasis model dapat berdampingan dengan Dynamics 365, karena keduanya bekerja dengan data. Mungkin Dynamics 365 Sales menangani proses penjualan penuh, sementara aplikasi model yang lebih kecil memberi manajer kontrak tempat terfokus untuk melacak perjanjian pelanggan. Keduanya dapat bekerja dengan data pelanggan terkait tambah membuat basis data pelanggan kedua. Tentu saja akses tersebut tetap memerlukan kehatian. Hanya karena sebuah aplikasi dapat bekerja dengan tabel Dataverse bukan berarti setiap pengguna harus mengedit setiap baris atau melihat setiap kolom. Peran akses baris dan aturan bisnis tetap mengendalikan apa yang terjadi. Aplikasi lapangan dapat memberikan detail pelanggan dan tindakan yang tepat kepada seseorang tanpa mengekspos data perusahaan lainnya. Jadi, integrasi Dynamics 365 dengan Dataverse kini bukan lagi sekadar kabel yang menghubungkan dua ruangan yang jauh. Aplikasi Dynamics 365, aplikasi kustom, dan proses bisnis semuanya dapat bekerja dari fondasi bersama yang sama. Begitu Anda melihatnya, pertanyaan berikutnya menjadi jelas. Apa lagi yang bisa Anda gunakan dari pembaruan pelanggan yang sama di seluruh platform Microsoft yang terhubung? Bagaimana platform yang terhubung bekerja dalam pekerjaannya? Pembaruan pelanggan bersama menjadi berguna saat alat di sekitarnya dapat merespon. Power Automate menangani pekerjaan tindak lanjut dengan memantau perubahan pada baris Dataverse dan memulai tindakan saat perubahan itu terjadi. Misalnya, Prospe baru masuk ke Dynamics 365 Sales. Sebuah alur dapat memberitahu tenaga penjual yang ditugaskan, mengirim pesan di Teams, atau membuat tugas tindak lanjut. Tidak ada yang perlu memantau kotak masuk bersama-sama. Prospek berubah, dan langkah berikutnya dimulai secara otomatis. Power Automate tidak memerlukan salinan terpisah dari prospek tersebut hanya untuk melakukan pekerjaan itu. Ia dapat bereaksi terhadap baris di Dataverse menggunakan detail pelanggan kepemilikan yang sama dengan digunakan aplikasi penjualan. Hal itu menjaga otomatisasi tetap dekat dengan proses bisnis alih-alih mengandalkan seseorang untuk mengekspor file dan memulai rangkaian email manual. Kemudian ada Power BI. Manager penjualan mungkin ingin mempunyai jalur penjualan pipeline. Manager layanan pelanggan mungkin perlu melihat berapa banyak kasus yang masuk minggu ini. Kasus mana yang masih terbuka atau pelanggan mana yang paling sering menghubungi dukungan. Power BI dapat melaporkan data bisnis Dataverse sehingga tim tersebut dapat melihat pekerjaan yang sedang berlangsung tanpa perlu mengekspor spetsheet baru setiap Jumat sore. Laporan tersebut diambil dari data bisnis yang sudah digunakan orang. Itu berarti bagian jalur penjualan dapat berubah seiring dengan majunya peluang. Dasbor kasus dapat menunjukkan beban kerja saat ini seiring agen memperpadui kasus. Intinya sekarang adalah dasbor menggantikan orang yang memeriksa detail secara manual. Hal ini memberi mereka pandangan yang lebih jelas tentang pekerjaan sebelum mereka memutuskan apa yang perlu diperhatikan. Power Apps menambahkan jalur lain ke dalam proses yang sama. Bayangkan seorang pekerjaan lapangan tiba di lokasi pelanggan. Mereka tidak memerlukan seluruh pengalaman penjualan Dynamics 365. Mereka mungkin hanya perlu menemukan pelanggan meninjau detail kunjungan mengonfirmasi apa yang terjadi dan menambahkan catatan atau foto. Power Apps yang terfokus dapat memberi mereka pengalaman yang lebih ringkas tersebut. Tim akun mungkin memerlukan aplikasi untuk meninjau perjanjian pelanggan. Seorang manajer mungkin memerlukan aplikasi sederhana untuk menyetujui. Setiap aplikasi dapat berfokus pada satu pekerjaan sambil bekerja dengan informasi Dataverse yang dikontrol sama di balik layar. Orang tersebut melihat alat yang sesuai dengan kesehatan. Bisnis tetap menyimpan informasi yang terhubung. Terkadang informasi tersebut berawal dari luar Dataverse. Perusahaan mungkin memiliki daftar dari sumber daring yang perlu menjadi bagian dari data bisnisnya. Power Query dapat membawa data dari sumber daring yang didukung membersihkannya selama impor dan memuatnya ke dalam tabel Dataverse yang tepat. Ini berguna ketika sumber luar menyimpan informasi yang perlu digunakan oleh alat Dynamics dan power platform Anda. Anda tetap perlu memutuskan apa yang termasuk dalam Dataverse dan bagaimana hal itu harus terhubung ke tabel. Mengimpor data tanpa pemikiran tersebut hanya akan memindahkan kebingungan ke lokasi baru. Mari kita biarkan auto menyatukan kepingan-kepingan itu Dynamics 365 dan aturan penugasan memeriksa siapa yang harus memiliki prospek tersebut mungkin berdasarkan wilayah atau produk. Pemilik menerima pesan tim melalui alur Power Automate sehingga mereka tahu ada pekerjaan yang menunggu. Saat tenaga penjual memperbarui prospek dan memindahkannya melalui proses penjualan, dasbor Power BI berubah untuk menunjukkan kepada tim bagaimana alur penjualan autom saat ini. Satu pembaruan memulai pekerjaan yang bermanfaat di beberapa tempat. Power Automate memindahkan pekerjaan dari satu langkah berikutnya. Power BI membantu orang melihat pekerjaan tersebut. Power Apps memberikan tim tertentu cara yang fokus untuk berpartisipasi. Dataverse menjaga informasi bisnis tetap terorganisir dan aman saat alat tersebut bekerja. Perbedaan itu penting. Otomatisasi bukanlah sistem pengarsipan dan dasbor bukanlah basis data pelanggan. Setiap alat memiliki tugas terpisah namun semuanya dapat bekerja dari sumbernya. Mengetahui hal itu membantu Anda memilih alat yang tepat daripada menganggap setiap lembar kerja atau daftar sederhana dapat menjalankan seluruh proses bisnis. Kapan Dataverse cocok digunakan dan apa yang dilanikan? Ini masalahnya. Pilih Dataverse ketika banyak orang dan aplikasi perlu bekerja dengan data bisnis yang terhubung. Anda pemerhukan atas yang jelas dan proses yang dapat diubung. Dataverse menanganinya tetapi tidak menggantikan segalanya. Excel tetap menjadi pilihan utama Anda untuk analisis pribadi dan daftar cepat. Daftar SharePoint berfungsi baik untuk kelecakan tim yang sederhana. Dan jika Anda seorang pengembang yang butuhkan kontrol mendalam, SQL tetap menjadi pilihan yang kuat. Jadi kapan Dataverse benar-benar cocok? Saat data Anda perlu terhubung di seluruh aplikasi Dynamics 365 otomatisasi dan laporan tanpa membuat salinan lagi. Disitulah keunggulannya. Namun, sebalik kesimpul. Satu fondasi banyak alat bisnis. Jadi inilah intinya. Dynamics 365 dan Dataverse bekerja paling baik ketika semua data, aturan, keamanan, aplikasi, otomatisasi, dan laporan Anda berbagi satu fondasi yang sama. Berlanggananlah ke Microsoft Knowledge Nuggets di M365.fm untuk panduan yang lebih sederhana tentang Dynamics 365, Power Platform, dan Microsoft 365. Lalu tonton episode kami tentang aplikasi berbasis model untuk melihat bagaimana tablet Dataverse berubah menjadi aplikasi bisnis yang berfungsi.