Selamat datang di Microsoft Nuggets, saya Mo Peters. Topik hari ini seringkali membingungkan banyak orang. Apa sebenarnya Dataverse itu? Apakah itu basis data, aplikasi, atau layanan Dynamics 365 tersemunya yang hanya perlu dipahami oleh staff IT? Ini definisi yang paling sederhana. Dataverse adalah fondasi data bersama di balik banyak pengalaman Dynamics 365. Anggaplah Dynamics 365 sebagai sebuah gedung perkantar. Penjualan, layanan pelanggan, dan aplikasi lain adalah ruangan tempat orang bekerja, sementara Dataverse adalah sistem pengarsipan dan aturan di balik dindingnya. Di akhir episode ini, Anda akan tahu di mana data Dynamics tersimpan dan bagaimana satu pembaruan pelanggan dapat muncul dalam pekerjaan penjualan, otomatisasi, dan pelaporan. Namun sebelum kita membahas nama produk, mari kita mulai dengan masalah bisnis. Ini memberikan solusi satu. Tempat bersama. Alih-alih salinan terpisah.

Bayangkan sebuah perusahaan dengan tim penjualan, tim dukungan, dan tim keuangan. Penjualan menyimpan detail pelanggan di lembar sebarang. Dukungan bekerja di alat pengulangan kasus yang terpisah. Keuangan memiliki nama pelanggan dalam sistemnya sendiri. Orang lain menyimpan utas email di kotak surat bersama, sementara orang lain menyimpan catatan di folder yang tidak bisa ditemukan orang lain. Pelanggan yang sama sekarang ada di 5 tempat. Pengaturan itu terasa normal. Pada awalnya, karena setiap tim hanya melihat bagian pekerjaan di depan mereka. Tetapi inilah masalahnya. Segera setelah pelanggan mengubah nomor telepon, alamat, nama perusahaan, atau kontak utama mereka, masalah pun dimulai. Penjualan berbaru sebaru. Dukungan tidak melihatnya. Keuangan tetap mengirim dokumen ke alamat lama. Kemudian seseorang mengekspor daftar, membersihkannya secara manual, mengirimkannya melalui email, dan tiba-tiba tiga orang yakin sadar mereka adalah yang benar.

Daftar mana yang harus Anda percaya? Pertanyaan itu membuang lebih banyak waktu daripada yang Anda kira. Staff berhenti untuk membandingkan catatan. Manager bertanya mengapa laporan tidak cocok dengan sistem penjualan. Akin dukungan membuka kasus untuk pelanggan yang detailnya sudah ada di tempat lain, hanya sedikit berbeda. Tidak ada yang berniat membuat kekacauan. Kacauan itu muncul dari sebut. 20 tahun lalu, sistem terpisah, berarti server terpisah, basis data terpisah, dan tim terpisah yang menyimpan informasinya sendiri. Menghubungkannya memerlukan pekerjaan kustom, importer jadwal, dan banyak pemeriksaan manual. Perubahan di satu tempat mungkin sampai ke sistem lain besok, minggu depan, atau tidak sama sekali. Dataverse memberikan aplikasi bisnis tempat bersama untuk jenis informasi ini. Dalam bahasa yang sederhana, Dataverse adalah platform data cloud Microsoft untuk informasi bisnis.

Dataverse menyimpan informasi tersebut dalam tabel terstruktur, sehingga data memiliki bentuk yang jelas alih-alih tersimpan sebagai catatan acak, file lepas, dan tiap lembar sebar yang terputus. Anda bisa menganggapnya sebagai lemari arsip perusahaan, namun yang bisa digunakan oleh beberapa alat yang disetujui secara bersama. Seorang pelanggan muncul satu kali di data. Pelanggan tersebut dapat muncul di Dynamics 365 Sales saat tenaga penjual mengerjakan sebuah kesepakatan. Data pelanggan yang sama dapat muncul di Dynamics 365 Customer Service saat agen menangani permintaan dukungan. Sebuah power app dapat menggunakan informasi pelanggan yang sama untuk pekerja lapangan atau manajer akun tanpa harus menyalin datanya ke aplikasi baru terlebih dahulu. Satu baris pelanggan, satu titik referensi bersama. Ini bukan berarti setiap tim tiba bisa melihat segalanya. Akses tetap memerlukan aturan, dan kita akan membahasnya sebentar.

Artinya, aplikasi yang disetujui dapat bekerja menggunakan informasi bisnis yang sama alih-alih membangun versinya sendiri yang saling bersaing. Inilah sebabnya mengapa Dynamics 365 Dataverse sangat cocok satu sama lain. Aplikasi Dynamics 365 seperti Sales dan Customer Service menggunakan Dataverse untuk menyimpan dan mengamankan data yang mereka kelola. Tapi begini masalahnya, saat seseorang berbicara tentang mengintegrasikan Dynamics 365 dengan Dataverse, mereka sering membayangkan dua produk terpisah yang memerlukan konektor di antaranya. Untuk banyak aplikasi Dynamics 365 begini, situasinya tidak demikian. Datanya sudah tersimpan di dalam Dataverse. Anda tidak perlu menarik daftar pelanggan keluar dari Dynamics 365, menyalinya ke basis data lain, dan berharap kedua sisi tetap sinkron. Anda dapat membangun data sfondasi yang sama menggunakan informasi bisnis yang sudah digunakan oleh Dynamics 365.

Hal itu mengubah percakapan. Alih bertanya, bagaimana kita 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? Sekarang Dataverse tidak menggantikan setiap sistem yang dimiliki perusahaan. Bisnis mungkin masih menggunakan perangkat lunak keuangan, alat industri, sistem gudang, situs web, atau aplikasi lama yang menyimpan data mereka sendiri. Dataverse bukanlah perangkat ajaib yang menghapus setiap sistem luar dalam semalam. Yang diberikannya kepada Anda adalah tempat umum untuk data bisnis yang perlu dibagikan oleh aplikasi yang terhubung. Detail pelanggan, pekerjaan penjualan, pekerjaan dukungan, tugas, dan tindak lanjut. Catatan tersebut dapat tersimpan bersama dalam satu sumber yang bisa dibaca dan diperbarui oleh alat yang disini. Jadi mari buka lemari arsep itu bersama saya.

Setelah Anda melihat bagaimana Dataverse mengatur informasi di dalamnya, keseluruhan koneksi Dynamics 365 menjadi jauh lebih mudah dipahami tabel. Baris, kolom, dan hubungan dalam lemari arsep tersebut. Mari kita buka lemari arsep itu. Di dalam Dataverse, informasi tersimpan di dalam tanpa. Anggap saja seperti lemari, sungguhan dengan laci-laci terpisah. Satu laci menyimpan data perusahaan, laci lainnya menyimpan data orang, dan laci ketiga menyimpan permintaan dukungan. Anda tidak akan membuang semua kertas ke dalam satu laci besar dan berharap seseorang bisa menyortirnya nanti. Setiap laci memiliki tugas. Jadi di Dataverse, buat tabel menampung satu jenis informasi bisnis. Tabel akun biasanya menampung perusahaan tempat Anda bekerja sama. Tabel kontak menampung orang-orang secara individu. Tabel prospek menampung calon pelanggan sebelum mereka menjadi pelanggan nyata. Tabel kasus menampung permintaan dukungan.

Sementara tabel aktivitas dapat melacak pekerjaan seperti panggilan, email, janji temu, dan tugas. Itu adalah tabel standar. Microsoft menyertakannya karena sebagian besar bisnis perlu melacak pelanggan, orang pekerjaan, dan percakapan. Anda tidak perlu mulai dengan membuat tabel baru untuk sesuatu yang umum dan perusahaan juga memiliki pekerjaan. Perusahaan pelatihan mungkin perlu melacak kursus dan sertifikat. Bisnis properti mungkin memerlukan bangunan, 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 dilakukan perusahaan. Anggaplah 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. Bagi contoh, satu baris dalam tabel kontak bisa mewakili Maria Gomez seseorang di perusahaan pelanggan.

Barisnya menyimpan detail dirinya sendiri yang terpisah dari setiap kontak lain di sistem. Kolom menjelaskan detail yang ingin Anda simpan untuk setiap baris. Baris kontak Maria mungkin memiliki kolom untuk nama depan, nama belakang, alamat email, nomor telepon, jabatan perusahaan, pemerik catatan, dan status. Kolom menetapkan jenis informasi yang seharusnya berada di tempat. Jadi, kolom email mengharapkan alamat email dan kolom status dapat menampung pilihan status yang disetujui. Begitulah cara informasi bisnis mendapatkan bentuk yang ada. Tanpa kolom, satu orang mungkin mengetik nomor telepon ke dalam 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 itu juga membantu aplikasi memahami data tersebut. Formulir dapat menampilkan kotak yang tepat lapar mengelompokkan kontak berdasarkan status, dan otomatisasi dapat bereaksi saat pemilik berubah.

Informasi tidak sekadar disimpan begitu saja. Informasi tersebut memiliki label yang memberitahu alat yang terhubung mengenai artis tepek. Mulai dengan tabel standar, kapanpun tabel tersebut sesuai dengan kebutuhan bisnis. Jika Anda menjual ke perusahaan, akun dan kontak sudah menjelaskan pola yang dipahami sebagian besar orang. Jika Anda menangani dukungan pelanggan, kasus memberi Anda titik awal. Kemudian tambahkan tabel custom hanya jika bisnis Anda memiliki informasi yang tidak sesuai dengan pola bawaan. Ini menghindari masalah umum, yaitu membuat lima tabel berbeda yang semua yang berarti pelanggan. Satu tim menyebutnya klien, tim lain menyebutnya master pelanggan, tim ketiga menyebutnya kontak mitra EU. Lama kemudian orang tidak tahu tabel mana yang harus mereka guna. Tabel standar yang jelas dan tabel custom yang diberi nama dengan cermat menjaga lemari arsip tetap mudah dipahami seiring bertamanya punggung.

Bagian selanjutnya adalah saat laci-laci tersebut mulai bekerja sama. Sebuah kontak termasuk sebuah akun. Maria bekerja untuk kontor soluted. Alih-alih 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 tertauk contoso dan tautan itu penting karena informasi perusahaan tetap berada di perusahaan tersebut. Jika contoso mengganti alamat kantor, seseorang cukup memperbarui baris akun sekadu. Tiap kontak terkait tetap bisa merujuk ke perusahaan yang sama tanpa harus membawa salinan lamanya sendiri. Hubungan juga menghubungkan kasus dukungan dengan pelanggan yang mengajukannya. Hubungan tersebut dapat menghubungkan peluang penjualan dengan panggilan email, rapat, dan tugas putar kesepakatan itu. Saat tenaga penjualan buka peluang, mereka dapat melihat aktivitas yang terhubung dengannya alih-alih mencari melalui catatan dan kalender yang tidak terkait.

Informasi tersebut memiliki kontak. Anda tidak hanya melihat nomor kasus. Oh, Anda bisa melihat milik pelanggan mana kasus itu. Anda tidak hanya melihat kontak K.O. Anda bisa melihat perusahaan yang terhubung dengan orang tersebut. Tautan-tautan tersebut menjaga data tetap berguna tanpa harus berulang kali mengetik fakta yang sama di beberapa tempat. Satu catatan kecil tentang penamaan sebelum Anda membaca panduan lama atau menonton video lama. Anda mungkin mendengar kata entitas bidang dan catatan. Itu adalah istilah data verse yang lama. Microsoft sekarang menggunakan tabel sebagai pengganti entitas, kolom sebagai pengganti bidang, dan baris sebagai pengganti catatan. Maknanya tidak berubah. Oh, panduan lama yang menyuruh Anda membuat entitas sebenarnya sedang berbicara tentang membuat tabel. Bidang adalah kolom dan catatan adalah baris. Mengetahui kedua rangkaian kata tersebut akan menghindarkan Anda dari anggapan bahwa Anda penemukan berubah.

Jadi, tabel mengatur informasi dan hubungan yang terhubung. Namun, lemari yang terorganisasi dengan baik tetap merupakan kont. Seseorang harus memutuskan apa yang boleh dimasukkan, diubah, dan diakses oleh orang-orang dengan. Aturan dan meja resepsionis dibalik data tersebut. Data bersama hanya berfungsi jika orang yang tepat dapat mengerjakannya dengan apa. Perwakilan penjualan memerlukan detail pelanggan. Agen dukungan memerlukan riwayat kasus. Manager memerlukan pandangan yang lebih luas. Dan mitra eksternal mungkin hanya memerlukan akses ke sebagian kecil dari proses tersebut. Mereka tidak seharusnya melihat informasi yang sama. Bayangkan sebuah catatan pelanggan dengan catatan kontak pribadi, harga yang dinegosiasikan, dan kasus dukungan yang terbuka. Memberikan akses penuh kepada setiap pengguna akan menciptakan risiko dan ngajep. Membatasi semua orang terlalu ketat hingga tidak bisa bekerja akan menciptakan masalah lain.

Dataverse memberi Anda kendali untuk hal ini. Anda dipertama dimulai dengan identitas. Saat Anda masuk dengan akun perusahaan, Microsoft Enter ID akan mengidentifikasi Anda. Anggaplah Enter ID sebagai meja resepsionis di pintu masuk kantor. Anda datang menunjukkan kartu identitas dan resepsionis memeriksa siapa Anda sebelum Anda bisa masuk. Dataverse menggunakan identitas tersebut untuk mengetahui pengguna mana yang sedang menguadat. Sistem tidak hanya berhenti pada pertanyaan apakah orang ini diinikam. Sistem juga menanyakan apa yang boleh dilakukan orang ini setelah mereka masuk. Disitulah peran keamanan berperan. Peran keamanan adalah sekumpulan izin yang dikaitkan dengan pekerjaan atau tanggung jawab. Anda bisa membuat satu peran untuk staff penjualan, peran lain untuk agen layanan pelanggan dan lainnya untuk manajer. Setiap peran dapat mengontrol akses ke suatu tab. Misalnya, staff penjualan mungkin diizinkan membaca, membuat, dan memperbarui akun, kontak, prospek, dan peluang.

Mereka mungkin tidak diizinkan untuk menghapus informasi pelanggan yang penting. Agen dukungan dapat membuat dan memperbarui kasus tetapi tidak bisa mengubah peluang penjualan. Izin tersebut dapat mencakup membaca, membuat, mengubah, dan menghapus baris. Artinya, akses tidak bergantung pada seseorang yang harus mengingat tombol mana yang disembunyikan di setiap aplikasi. Izin tersebut melekat pada data itu sendiri. Jadi, batasannya sama berlaku dimanapun data-data verse tersebut muncul. Kemudian, Anda dapat mempersempit akses lebih jauh lagi. Keamanan baris menentukan baris individual mana yang bisa diolah oleh seseorang. Staff penjualan mungkin hanya melihat pelanggan yang mereka miliki sementara manajer penjualan bisa melihat baris pelanggan yang dimiliki tim mereka. Keduanya menggunakan tabel akun yang sama. Hanya saja mereka tidak melihat bagian yang sama. Pengaturan itu membantu orang fokus pada pekerjaan mereka sekaligus memberi manajer tampilan yang mereka butuh.

Hal ini juga mengurangi kemungkinan seseorang membuka informasi pelanggan yang tidak perlu mereka akses. Beberapa informasi memerlukan perlindungan yang lebih ketat. Keamanan tingkat kolom dapat melindungi kolom individual di dalam tabel. Mungkin pengguna bisa membuka baris pelanggan tetapi tidak boleh melihat pengenal pribadi, gaji, detail bank atau catatan keuangan pribadi. Baris pelanggan tetap tersedia untuk pekerjaan yang perlu mereka lakukan. Kolom yang dilindungi tetap dibatasi. Untuk perusahaan yang lebih besar unit bisnis dapat menciptakan batasan antar bagian organisasi. Perusahaan mungkin memisahkan wilayah, divisi atau anak perusahaan yang bekerja dengan kelompok pelanggan berbeda. Unit bisnis membantu cara kerja akses di seluruh batasan tersebut. Ini tidak berarti setiap bisnis memerlukan peta keamanan yang rumit. Tim kecil mungkin hanya memerlukan beberapa peran yang jelas.

Perusahaan yang lebih besar mungkin membutuhkan lebih banyak lapisan karena tim wilayah dan tanggung jawabnya berbeda. Intinya adalah data first dapat menyesuaikan akses dengan cara bisnis sebenarnya beroperasi. Kontrol akses melindungi siapa yang dapat menjangkau data namun aturan juga melindungi kualitas data itu sendiri. Aturan bisnis dapat mengharuskan seseorang memasukkan nomor telepon sebelum mereka menyimpan kontak-kontak. Aturan ini dapat memeriksa kondisi seperti mengharuskan adanya alasan satu-satu kasus itu. Aturan ini juga dapat mengubah apa yang dilihat mengguna berdasarkan informasi yang mereka masukkan. Aturan yang sama berlaku di seluruh aplikasi yang menggunakan tabel tersebut. Hal ini penting karena Anda tidak ingin satu aplikasi menerima data yang tidak lengkap sementara aplikasi lain menolak. Aturan tersebut melekat pada informasi bisnis bukan pada satu layar yang kebetulan menampilkannya.

Data first juga dapat menjalankan logika di balik layar untuk membantu menjaga proses bisnis tetap konsisten. Detail yang perlu Anda ingat sederhana saja. Data ada dengan aturan bukan sekadar penyimpanan. Jadi fondasinya mencakup informasi orang yang diizinkan mengelolahnya dan aturan yang membuatnya tetap dapat digunakan. Begitu Dynamics 365 bekerja pada fondasi yang sama ia tidak memerlukan jembatan tradisional hanya untuk mengakses data bisnisnya sendiri. Apa? Arti integrasi Dynamics 365 yang sebenarnya kebanyakan orang mendengar integrasi Dynamics 365 dengan data first dan mereka membayangkan dua sistem terpisah yang dihubungkan oleh konektor. Satu sistem menyimpan data pelanggan sistem lain membutuhkan salinannya jadi seseorang menyiapkan sinkronisasi menunggu prosesnya berjalan dan berharap tidak ada yang gagal. Gambaran itu masuk akal untuk banyak ala bisnis. Namun inilah masalahnya 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. Mereka bukan basis data terpisah yang saling bertukar baris pelanggan hanya agar bisa saling memahami. Mereka bekerja dari informasi bisnis yang sama sejak awal. Artinya Anda seorang tenaga penjual dan Anda membuat perusahaan baru di Dynamics 365 Sales. Anda menambahkan kontak utama dan mulai mengerjakan kesepakatan yang mungkin terjadi. Detail tersebut segera menjadi bagian dari data bersama yang digunakan oleh aplikasi tersebut. Kemudian pelanggan tersebut menghubungi dukungan. Agen dukungan dapat bekerja dengan detail perusahaan dan kontak yang persis sama. Tidak ada yang perlu mengekspor daftar dari bagian 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.

Tim penjualan melihat kesepakatan. Tim dukungan melihat kasus tersebut dan kedua tim bekerja di sekitar pelanggan. Namun itu tidak berarti setiap layar terlihat identik atau setiap tim mengikuti proses yang sama. Tim penjualan membutuhkan prospek, peluang, panggilan, dan rapat. Layanan pelanggan memerlukan kasus antrean dan riwayat layan. Setiap aplikasi Dynamics 365 memberikan alat yang dirancang untuk pekerjaan mereka. Sementara informasi bisnis dibaliknya dapat terhubung kemanapun diperlukan. Landasan bersama itulah yang sering dimaksud orang saat membahas integrasi Dynamics 365 dan Dataverse. Ini bukan sekadar memindahkan data dari titik A ke titik B. Ini tentang aplikasi yang bekerja dengan baris hubungan aturan dan kontrol akses yang sama. Dari awal, biarkan staff melalui perjalanan penjualan yang sederhana. Prospek masuk dari situs web atau sebuah acara. Seorang tenaga penjualan menindaklanjuti prospek tersebut mempelajari orang itu dan mengubahnya menjadi hubungan pelanggan serta peluang bisnis.

Panggilan, email, janji temu, dan tugas semuanya dapat terhubung ke pekerjaan tersebut. Jadi, tim tidak perlu mencari di berbagai 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 saja. Mereka dapat bekerja sesuai konteks dengan hubungan pelanggan yang sudah teridentifikasi. Sementara itu, tim penjualan dapat melihat bahwa pelanggan memiliki masalah layanan yang terbuka dan menghindari percakapan pembaruan tanpa mengetahui masalah mereka sebelum. Satu hubungan pelanggan dapat mendukung berbagai jenis pekerjaan. Hal itu jauh lebih bermanfaat daripada sekadar menyimpan nama pelanggan yang sama di dua sistem. Dan Anda mungkin juga mendengar istilah common data model. Terkadang disingkat CDM. Jangan biarkan namanya terdengar lebih misterius dari 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-pola ini memberikan bahasa awal yang sama bagi aplikasi berbasis Dynamics 365 dan Dataverse. Akun berarti sebuah perusahaan. Kontak berarti seseorang. Aktivitas melacak pekerjaan seputar hubungan bisnis. Anda dapat menyesuaikan pengaturan untuk perusahaan Anda dan menambahkan tabel sendiri jika perlu namun Anda tidak perlu memulai dari nol setiap saat. Ketika satu aplikasi memahami tabel akun dan aplikasi lain menggunakan tabel yang sama, kedua aplikasi merujuk pada jenis informasi bisnis yang sama. Ini juga mengubah apa yang dapat Anda bangun. Misalkan tim lapangan Anda memerlukan aplikasi sederhana untuk mencari pelanggan, memanfirmasi kunjungan dan menambahkan catatan setelah janji temu. Anda dapat membuat power app yang bekerja dengan tabel Dataverse yang sama yang sudah digunakan oleh Dynamics 3.

Tidak perlu mengekspor pelanggan ke daftar baru hanya untuk aplikasi tersebut. Pekerja lapangan membuka aplikasi menemukan pelanggan dan memperbarui informasi kunjungan. Data tetap terhubung dengan hubungan pelanggan yang sudah digunakan oleh bagian penjualan atau layanan pelanggan sesuai dengan aturan keamanan yang kita bahas sebelumnya. Untuk pekerjaan bisnis yang lebih terstruktur, Anda dapat membangun aplikasi berbasis model. Aplikasi berbasis model dimulai dengan model Dataverse. Anda memilih tabel Dataverse, menentukan hubungan antara tabel, mengatur formulir dan tampilan, serta menerapkan peran keamanan. Our apps kemudian menggunakan struktur tersebut untuk membuat pengalaman aplikasi bisnis yang fungsional. Bayangkan seperti mengatur meja kerja di sekitar alat dan bahan yang mudah-mudahan digunakan oleh tim Anda. Tabel menggambarkan pekerjaannya, hubungan menggambangkan buah yang tersebut.

Formulir memberikan tempat bagi pengguna untuk memasukkan tampilan membantu mereka menemukan baris yang memerlukan perhatian. Keamanan menentukan apa yang bisa dibuka atau diubah oleh setiap orang. Aplikasi berbasis model dapat berjalan berdampingan dengan Dynamics 365 karena keduanya bekerja dengan dataverse. Mungkin Dynamics 365 Sales menangani seluruh proses penjualan, sementara aplikasi berbasis model yang lebih kecil memberi manajer kontrak tempat terfokus untuk melacak perjanjian pelanggan. Keduanya dapat bekerja dengan data pelanggan terkait tanpa perlu membuat basis data pelanggan kedua. Tentu saja akses tersebut tetap memerlukan perhatian. Hanya karena sebuah aplikasi dapat bekerja dengan tabel dataverse bukan berarti setiap pengguna harus bisa mengedit setiap baris atau melihat setiap kolom. Akses baris berbasis peran dan aturan bisnis tetap mengendalikan apa yang terjadi. Aplikasi lapangan dapat memberikan detail pelanggan dan tindakan yang tepat bagi seseorang tanpa mengekspos data perusahaan lainnya.

Jadi integrasi Dynamics 365 dengan dataverse kini bukan lagi sekadar kabel yang menghubungkan dua ruangan yang berjauh. Aplikasi Dynamics 365, aplikasi custom, dan proses bisnis semuanya dapat bekerja dari fondasi bersama yang sama. Begitu Anda melihatnya, pertanyaan berikutnya menjadi jelas. Apalagi yang bisa menggunakan pembaruan pelanggan yang sama di seluruh platform Microsoft yang terhubung. Bagaimana cara kerja platform yang terhubung dalam pekerjanya? 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. Sebagai contoh, prospek baru masuk ke Dynamics 365 Sales. Allure Flow dapat memberitahu tenaga penjual yang ditugaskan mengirim pesan di Teams atau membuat tugas tindak lanjut. Tidak ada yang perlu memantau kotak masuk bersama sepanjang hari.

Prospek berubah dan langkah selanjutnya dimulai secara otomatis. Power Automate tidak memerlukan salinan terpisah dari prospek tersebut hanya untuk melakukan pekerjaan itu. Sistem dapat bereaksi terhadap baris di dataverse menggunakan detail pelanggan dan kepemilikan yang sama dengan yang digunakan aplikasi penjualan sehingga otomatisasi tetap dekat dengan proses bisnis alih-alih semangat proses bisnis alih-alih mengandalkan seseorang untuk meng-export file dan memulai rangkaian email manual. Lalu ada Power BI. Seorang manajer penjualan mungkin ingin melihat saluran paypalan saat ini. Seorang manajer 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 harus membuat ekspor spreadsheet baru setiap Jumat sore.

Laporan tersebut bersumber dari data bisnis yang sudah digunakan orang. Artinya, bagian alur kerja dapat berubah seiring dengan kemajuan peluang. Dashboard kasus dapat menunjukkan beban kerja saat ini seiring agen memperbarui kasus. Poinnya bukanlah dashboard menggantikan orang dalam memeriksa detail. Hal ini memberikan 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 pekerja lapangan tiba di lokasi pelanggan. Mereka tidak memerlukan pengalaman Dynamics 365 Sales. Mereka mungkin detail kunjungan mengonfirmasi apa yang terjadi dan menambahkan catatan atau foto. Power Apps yang terfokus dapat memberikan pengalaman yang lebih ringkas tersebut. Tim akun mungkin memerlukan aplikasi untuk meninjau perjanjian pelanggan. Seorang manajer mungkin memerlukan aplikasi sederhana untuk menyetujui pemilik.

Setiap aplikasi dapat berfokus pada satu pekerjaan sambil tetap bekerja dengan informasi dataverse terkontrol yang sama di balik layar. Pengguna melihat alat yang sesuai dengan keserian mereka. Bisnis menyimpan informasi yang saling terhukum tersebut. Terkadang informasi tersebut

menarik data dari sumber daring yang didukung, membersihkannya selama impor, dan memuatnya ke 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 keterkaitannya dengan tabel yang ada. Mengimpor data tanpa pemikiran tersebut hanya akan memindahkan kebingungan ke lokasi baru. Mari kita rangka potongan tersebut menjadi satu alur sehari-hari. Prospek baru masuk ke Dynamics 3. Aturan pendugasan memberi sesiapa yang harus memiliki prospek tersebut mungkin berdasarkan wilayah atau produk. Memiliki menerima pesan tim melalui alur Power Automate sehingga mereka tahu ada pekerjaan yang menunggu. Saat tab penjualan memperbarui prospek dan memindahkannya melalui proses penjualan, dashboard Power BI berubah untuk menunjukkan tim-tim kita dan alur kerja saat ini.

Satu pembaruan memulai pekerjaan bermanfaat di beberapa tempat. Power Automate memindahkan pekerjaan dari satu langkah ke langkah. Power BI membantu orang melihat pekerjaan tersebut. Power Apps memberikan cara yang terfokus bagi tim tertentu untuk ikut serta. Dataverse menjaga informasi bisnis tetap teratur dan aman saat alat-alat tersebut menjalankan tugasnya. Perbedaan itu penting. Otomatisasi bukanlah sistem pengarsipan dan dashboard bukanlah basis data pelanggan. Setiap alat memiliki tugas tersendiri namun semuanya bisa bekerja di sumber yang sama. Mengetahui hal itu membantu Anda memilih alat yang tepat alih-alih memperlakukan setiap lembar kerja atau daftar sederhana seolah-olah harus menjalankan seluruh proses bisnis. Kapan Dataverse cocok digunakan dan apa yang tidak digantikannya? Gini masalahnya. Pilihlah Dataverse jika banyak orang dan aplikasi perlu bekerja dengan data bisnis yang saling terhubung.

Anda membutuhkan akses yang jelas dan proses yang dapat diurut. Dataverse menangani hal itu namun tidak menggantikan segalanya. Excel tetap menjadi pilihan utama untuk analisis pribadi dan daftar cepat. Daftar SharePoint bekerja dengan baik untuk pelacakan tim yang sederhana. Dan jika Anda seorang pengembang yang membutuhkan kontrol mendalam SKR tetap menjadi pilihannya. Jadi kapan sebenarnya Dataverse cocok digunakan? Saat data Anda perlu terhubung

Disitulah ya bersinar. Kesimpulannya satu fondasi untuk banyak alat bisnis. Jadi inilah intinya. Dynamics 365 dan Dataverse bekerja paling baik jika semua data, aturan, keamanan, aplikasi, otomatisasi dan laporan Anda berbagi satu fondasi yang sama. Perlanggananlah ke Microsoft Knowledge Nuggets di M365FM untuk panduan yang lebih sederhana tentang Dynamics 365 Power Platform dan Microsoft 365 Power Platform. Kemudian tonton episode kami tentang model driven apps untuk melihat bagaimana tabel Dataverse berubah menjadi aplikasi bisnis yang fungsi.