Pilih Objek yang Tepat
Juga tersedia dalam 28 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 5 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Di Mana Data Ini Tinggal? · Berikutnya: Bidang Juga Bagian dari Arsitektur
Pertanyaan yang dijawab modul ini: Objek Salesforce jenis apa yang seharusnya menjadi wujud konsep bisnis ini, dan apa yang diizinkan oleh lisensi?
Salah satu hal termudah di Salesforce adalah membuat objek kustom. Justru itulah sebabnya menurut saya kita membuat terlalu banyak objek kustom.
Anda sedang berada dalam sesi persyaratan dan seseorang berkata, “Kita perlu melacak distributor kita.” Objek kustom baru: Distributor. Selesai. Hanya saja, saya ingin arsitek mengajukan pertanyaan lain lebih dulu: apa itu distributor? Itu sebuah perusahaan. Salesforce sudah punya cara yang cukup baik untuk merepresentasikan perusahaan. Namanya Akun. Itu tidak berarti jawabannya selalu Akun. Tetapi jika saya harus menjelaskan mengapa sebuah perusahaan bukan Akun, saya ingin alasan yang lebih baik daripada “bisnis menyebut mereka distributor.”
Di sinilah model logis dari bab 2 bertemu platform, dan posisi awal saya sederhana: jika konsep bisnisnya cocok dengan rapi dengan tujuan yang dimaksud dari sebuah objek standar, mulailah dari sana.
Mulailah dari Maknanya
Section titled “Mulailah dari Maknanya ”Bahkan ketika sesuatu layak menjadi objek, ia tidak otomatis layak menjadi objek kustom. Tanyakan apa yang sebenarnya diwakilinya. Sebuah bisnis atau organisasi dalam bentuk apa pun? Mulailah dengan Akun. Seseorang yang bekerja dengan organisasi itu? Kontak. Sesuatu yang dimiliki atau dibeli pelanggan? Aset. Sesuatu yang sedang Anda coba jual? Sekarang Peluang layak masuk ke percakapan.
Itulah sebabnya kita melihat ke kapal induk lebih dulu, di modul 2. Model-model itu tidak cocok untuk setiap bisnis, tetapi kita tidak seharusnya mengabaikannya karena membangun sendiri terasa lebih rapi. Sebelum menekan New Custom Object (Objek Kustom Baru), tanyakan bagaimana Salesforce memodelkan konsep ini, apa yang sudah dibangun di sekitar model itu, dan apa yang akan Anda lepaskan jika menggantinya.
Uji Kecocokan yang Rapi
Section titled “Uji Kecocokan yang Rapi ”Uji saya adalah satu pertanyaan: apakah konsep bisnis ini cocok dengan rapi dengan tujuan yang dimaksud dari objek standar itu? Jika ya, kecenderungan saya adalah ke objek standar.
Distributor adalah perusahaan yang menjalin hubungan dengan kita, jadi Akun cocok dengan rapi. Saya tidak keberatan pengguna menyebut satu perusahaan distributor, yang lain pemasok, yang lain mitra ritel, dan yang lain pelanggan. Itu peran bisnis, dan tidak butuh empat objek fisik. Nama bisnis yang berbeda tidak otomatis berarti struktur data yang berbeda. Sebuah tipe, tipe rekaman, atau hubungan bisa membawa perbedaannya.
Uji ini juga berlaku ke arah sebaliknya. Di bab 1 saya meninggalkan Anda dengan sebuah pertanyaan: bisnis seorang pelanggan punya banyak lokasi pengiriman. Haruskah setiap lokasi menjadi Akun, atau objek kustom?
Akun memberi Anda banyak hal. Anda mendapat bidang-bidang alamat, dan semua yang sudah mengharapkan alamat Akun: laporan, peta, integrasi. Tetapi Anda juga mendapat bebannya: banyak bidang, berbagi, hierarki, kepemilikan, semua yang bergantung pada Akun, dan sebagian besar tidak relevan untuk sebuah alamat terpisah. Anda akan memikul banyak barang berat yang tidak akan Anda pakai, hanya demi sebuah alamat alternatif.
Objek kustom, sebagai anak dari Akun, bisa ringan: hanya bidang-bidang alamat, sebuah tempat yang kita kirimi, dengan siklus hidupnya sendiri yang bisa saya kendalikan secara mandiri.
Jadi ini soal keseimbangan: beban yang Anda pikul dibandingkan nilai yang Anda dapat. Jika yang saya butuhkan hanyalah sebuah alamat dengan siklus hidupnya sendiri, di situlah saya memilih kustom.
Sama halnya dengan sub-masalah pada sebuah kasus. Jika setiap sub-masalah memang benar-benar sebuah kasus, dikerjakan oleh seorang agen layanan, dengan status dan tingkat layanannya sendiri, susunlah secara bertingkat dengan Parent Case (Kasus Induk) dari modul 2. Tetapi jika itu hanya butir daftar periksa yang tidak pernah dikerjakan siapa pun sebagai kasus, kasus lengkap membawa banyak hal yang tidak akan pernah dipakainya, dan anak kustom yang sederhana mungkin lebih ringan. Bukan karena kustom lebih rapi. Melainkan karena maknanya berbeda, atau bebannya tidak sesuai.
Objek Standar Datang dengan Bawaan
Section titled “Objek Standar Datang dengan Bawaan ”Ketika memilih objek standar, Anda memilih lebih dari sekadar bidang-bidangnya. Anda memilih sesuatu yang sudah dipahami oleh produk-produk Salesforce: pelaporan, otomatisasi, hubungan bawaan, fitur produk, paket AppExchange, dan apa pun yang akan dibangun Salesforce berikutnya. Itu bisa sangat berharga.
Objek standar juga datang dengan pendapatnya sendiri: perilaku yang sudah ada, hubungan, pertimbangan keamanan, kadang persyaratan lisensi, dan fitur yang tidak Anda butuhkan. Jadi “selalu pakai objek standar” bukanlah aturan saya. Saya tidak punya aturan “selalu.” Saya punya kecenderungan: pakai objek standar ketika maknanya cocok dengan rapi dan perilaku platform di sekitarnya membantu desain, bukan melawannya. Jika saya menghabiskan lima tahun membuat Peluang berperilaku seperti sesuatu yang bukan peluang penjualan, saya tidak mendapat apa-apa dengan tetap memakai yang standar. Saya hanya membuat kompromi yang salah ke arah yang lain.
Aset Adalah Contoh yang Baik
Section titled “Aset Adalah Contoh yang Baik ”Aset adalah salah satu objek standar yang sering diabaikan orang. Cara paling sederhana saya menjelaskannya: ia adalah sesuatu yang dimiliki pelanggan. Mungkin mereka membelinya dari kita, mungkin tidak. Saya tetap peduli pada produk pesaing yang ada di lokasi pelanggan saya, karena saya merawatnya, atau mencoba menggantikannya, atau perlu memahami basis terpasang mereka. Jika saya membuat Customer_Product__c tanpa melihat Aset lebih dulu, saya telah melewatkan sebuah pertanyaan arsitektur. Aset tidak otomatis menang, tetapi layak dievaluasi.
Akun Pribadi: Kapan Orangnya Adalah Akunnya?
Section titled “Akun Pribadi: Kapan Orangnya Adalah Akunnya? ”Di modul 2 kita sudah berkenalan dengan akun pribadi (person account): akun dan kontak dalam satu rekaman, untuk pelanggan yang merupakan perorangan. Sekarang keputusannya.
Posisi saya: untuk B2C, sulit bekerja tanpanya. Begitu banyak yang tersedia langsung bersama Akun dan Kontak sehingga biaya dan bebannya sepadan. Dan memang ada biayanya: kira-kira dua kali lipat penyimpanan akun bisnis, sebuah sakelar yang tidak bisa Anda matikan, dan sebagian lisensi eksternal tidak bisa memakainya. Partner Community tidak bisa dipakai dengan akun pribadi (Experience Cloud User Licenses (opens in a new tab)). Jadi pertanyaannya bukan “apakah ada orang di database kita?” Setiap org punya orang. Pertanyaannya adalah “apakah orang itu benar-benar akunnya dalam bisnis ini?” Sebuah Kontak yang merupakan orang tidak menjadikannya akun pribadi. Hubungan bisnisnyalah yang menentukan.
Sekarang Saya Akan Memperumit Semuanya: Lisensi
Section titled “Sekarang Saya Akan Memperumit Semuanya: Lisensi ”Sejauh ini: temukan konsepnya, cari kecocokan standar yang paling rapi, pilih kustom ketika maknanya tidak cocok. Sekarang pertanyaan lanjutan dari arsitek: siapa yang perlu memakainya? Anda bisa merancang model yang indah lalu mendapati separuh orang yang butuh datanya tidak punya lisensi untuk objek-objek yang Anda pilih. Lisensi adalah bagian dari model data.
Tiga Lisensi Internal
Section titled “Tiga Lisensi Internal ”Mulailah dari orang-orang Anda sendiri. Di dalam perusahaan, ada tiga tipe lisensi yang saya ingin dikuasai betul oleh setiap arsitek, karena lisensi menentukan apa yang bisa dilihat dan dilakukan setiap pengguna, dan dengan demikian apa yang bisa diandalkan model data Anda.
Sales Cloud (kini Agentforce Sales). Pengguna ini punya lisensi pengguna Salesforce penuh: objek CRM standar, dan aplikasi standar atau kustom apa pun. Itu berarti prospek, peluang, dan prakiraan (forecast) di atas akun dan kontak, bahkan kasus: seorang sales bisa melihat kasus terbuka pelanggan sebelum menelepon. Membuat dan menjalankan kampanye butuh satu bagian lagi, lisensi fitur Marketing User.
Service Cloud (kini Agentforce Service). Lisensi pengguna Salesforce yang sama, disiapkan untuk layanan. Kasus ada di pusatnya, dikerjakan di Service Console: lisensi fitur Service Cloud User-lah yang membuka Salesforce Console for Service. Di sinilah perjanjian tingkat layanan (SLA) tinggal, melalui manajemen hak layanan (entitlement management) dan milestone, dan di sinilah Knowledge masuk, yang di sebagian besar edisi dibeli sebagai add-on.
Platform (Salesforce Platform). Untuk orang yang butuh aplikasi kustom Anda, bukan CRM. Mereka mendapat akun, kontak, laporan, dasbor, dokumen, dan setiap aplikasi kustom di org. Yang tidak mereka dapat: prakiraan, prospek, kampanye, dan peluang. Harganya lebih murah, dan justru itulah sebabnya begitu banyak aplikasi kustom besar berjalan di atasnya, dan justru itulah sebabnya ia bisa menjebak model data Anda.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| Lisensi pengguna | Salesforce | Salesforce | Salesforce Platform |
| Dibuat untuk | Menjual | Melayani pelanggan | Aplikasi kustom |
| Akun, kontak | Ya | Ya | Ya |
| Prospek, peluang, prakiraan | Ya | Ya | Tidak |
| Kasus | Ya, untuk melihat kasus pelanggan | Di pusatnya, di Service Console | Tidak |
| Perjanjian tingkat layanan | Tidak | Ya, hak layanan dan milestone | Tidak |
| Objek dan aplikasi kustom | Ya | Ya | Ya |
Bacalah tabel itu seperti seorang arsitek membacanya. Jika sekelompok besar pengguna memakai Platform, desain apa pun yang menaruh pekerjaan mereka di Peluang sudah rusak sebelum dimulai. Jika para eksekutif butuh angka SLA, lisensi yang mereka pakai menentukan apakah mereka bisa melihatnya. Ketiga tipe ini menggerakkan perilaku.
Ketika Lisensi Menentukan Objeknya
Section titled “Ketika Lisensi Menentukan Objeknya ”Peluang adalah korban yang paling sering saya temui. Anda sudah melihatnya di tabel: pengguna Platform tidak mendapatkannya (Standard User Licenses (opens in a new tab)), dan pengguna Customer Community juga tidak bisa bekerja dengannya. Jadi persyaratannya kelihatan seperti Peluang, seseorang berkata “ayo pakai Peluang,” lalu saya bertanya siapa yang butuh akses. Jika populasi besar memakai lisensi Platform atau Customer Community, lisensi bukan lagi detail pengadaan. Ia adalah batasan arsitektur, dan biasanya mendorong desain ke arah objek kustom.
Ini juga berlaku ke atas. Di kelas saya bertanya: CEO ingin dasbor yang cantik; lisensi Sales atau Service? Pengguna Sales bisa melihat objek-objek penjualan dan bahkan kasus, jadi untuk dasbor penjualan dan jumlah kasus terbuka, Sales sudah cukup. Tetapi begitu sang eksekutif menginginkan KPI SLA (berapa lama sampai sebuah kasus melanggar tingkat layanannya), data itu berada di entitlement dan milestone, dan manajemen entitlement butuh Agentforce Service, yang dulu bernama Service Cloud (Supported Editions for Service Features (opens in a new tab)). Sekarang Anda harus menaikkan lisensi para eksekutif. Dengarkan persyaratan bisnisnya, dan ketahui lisensi mana yang berada di bawah data yang dibutuhkannya.
Stadion
Section titled “Stadion ”Saya membayangkan lisensi seperti kursi di stadion. Semua orang menonton pertandingan yang sama. Jika saya membeli kursi mahal di tengah, saya bisa melihat kedua tim dari dekat. Jika saya berada di tribun pojok atas, kursinya tidak empuk dan saya menonton lewat teropong.
Itulah lisensi eksternal, untuk orang di luar perusahaan: pelanggan dan mitra yang login ke situs Experience Cloud. Ada tiga yang ingin saya kenalkan kepada Anda.
Customer Community: tribun atas. Dibuat untuk pengguna eksternal dalam jumlah besar yang butuh kasus dan knowledge: pelanggan yang mengecek kasus dukungannya. Harga kursinya sekitar separuhnya dan bisa diberikan kepada pengguna dalam jumlah sangat besar. Apa yang hilang di atas sana? Laporan, dasbor, dan tabel berbagi (share table): berbagi berbasis peran yang didapat tingkat yang lebih tinggi. Lisensi ini bisa dipakai dengan akun pribadi.
Customer Community Plus: kira-kira di tengah. Salesforce menggambarkannya sebagai lisensi untuk pengguna eksternal yang butuh laporan, dasbor, dan berbagi standar: pelanggan yang mengelola akses orang lain, atau perlu melihat angka-angkanya.
Partner Community: lebih dekat lagi, untuk bisnis-ke-bisnis, dengan akses ke data penjualan. Mitra mengerjakan prospek dan peluang: mereka mendaftarkan kesepakatan, dan menjalankan kampanye bersama Anda. Itulah kursi eksternal yang menjangkau objek-objek penjualan. Satu catatan: lisensi ini tidak bisa dipakai dengan akun pribadi (Experience Cloud User Licenses (opens in a new tab)).
Kesalahannya adalah merancang seolah semua orang punya tiket mahal, lalu mendapati saat implementasi bahwa sebagian besar pengguna Anda tidak bisa masuk ke bagian tempat Anda menaruh data mereka. Lalu Anda punya tiga pilihan: membeli kursi yang berbeda, memindahkan pengalamannya, atau merancang ulang modelnya. Ketiganya adalah arsitektur.
Cara Mereka Membayar Mengubah Desainnya
Section titled “Cara Mereka Membayar Mengubah Desainnya ”Ada pertanyaan lain yang sering dilupakan orang: bagaimana pengguna ini akan login? Lisensi eksternal hadir dalam dua bentuk. Berbasis anggota (member-based): Anda membayar per pengguna, yang cocok untuk 500 mitra yang login setiap hari. Berbasis login (login-based): Anda membeli sejumlah login per bulan, yang cocok untuk lima juta pelanggan yang login beberapa kali setahun. Login lebih dari sekali pada hari yang sama tetap dihitung satu login (Experience Cloud User Licenses (opens in a new tab)).
Jadi ketika seseorang berkata “kami sedang membangun portal pelanggan,” pertanyaan saya berikutnya bukan template yang mana. Pertanyaannya: siapa pelanggannya, berapa banyak, seberapa sering mereka datang, data apa yang mereka butuhkan, dan apa yang boleh mereka lakukan dengannya?
Ketika Lisensi Membentuk Model
Section titled “Ketika Lisensi Membentuk Model ”Kadang lisensi tidak hanya memilih objeknya; ia membengkokkan seluruh model. Sebagian lisensi platform membatasi pengguna pada satu aplikasi kustom dengan paling banyak sepuluh objek kustom (misalnya Lightning Platform – One App; Standard User Licenses (opens in a new tab)).
Dalam sebuah proyek awal, untuk perusahaan besar jasa profesional dan konstruksi, kami harus membangun sesuatu seperti LinkedIn untuk seluruh tenaga kerja: pekerjaan, keterampilan, sertifikasi, bahasa, dan proyek setiap orang, agar mereka bisa menemukan ahli pembangun jembatan yang tersertifikasi di negara tertentu. Tanpa batasan, saya akan membangun objek pekerjaan-pengguna, keterampilan-pengguna, sertifikasi-pengguna, bahasa-pengguna, dan proyek-pengguna, ditambah daftar referensi sertifikasi dan proyek. Dengan lisensi sepuluh objek, dan diminta untuk tidak menghabiskan semuanya, itu tidak mungkin. Jadi ini berubah menjadi permainan tebak lagu: dengan berapa sedikit objek saya bisa membangun ini? Jawabannya dua. Satu objek referensi, dengan tipe rekaman untuk setiap jenis daftar (pekerjaan, keterampilan, sertifikasi, bahasa, proyek), dan satu objek atribut pengguna, dengan tipe rekaman yang sepadan, yang menunjuk ke objek referensi itu.
Itu bukan model yang optimal. Sulit dibuat laporannya, dan saya lebih suka yang lebih rapi. Tetapi itulah yang diizinkan lisensinya. Saya menyebutnya objek pisau lipat Swiss: simpan pola ini di saku belakang Anda, dan ketika batasan tidak menyisakan ruang, pecahkan kacanya dan pakai pemisahan lewat tipe rekaman. Hanya saja, ketahui apa yang Anda korbankan. Izin yang berbeda per tipe rekaman bisa tetap memaksa Anda memecah objeknya.
Manusia Bukan Lagi Satu-satunya Pengguna
Section titled “Manusia Bukan Lagi Satu-satunya Pengguna ”Satu pertanyaan lisensi lagi kini menjadi penting: bagaimana dengan hal-hal yang bukan manusia? Integrasi punya identitas. Agen punya identitas. Salesforce kini punya lisensi Salesforce Integration untuk integrasi antarsistem: hanya API, bukan untuk manusia, dengan lima lisensi termasuk di setiap org Enterprise, Unlimited, dan Performance Edition (Standard User Licenses (opens in a new tab)). Jadi jangan hanya bertanya pengguna mana yang butuh akses. Tanyakan identitas mana yang butuh akses: seseorang, pelanggan, mitra, integrasi, agen. Lalu apa yang perlu dilihat dan dilakukan masing-masing.
Di luar ujian: apa yang diubah AI. Ketika agen menjadi satu lagi konsumen sekaligus pencipta data, pilihan objek dan lisensi bukan lagi hanya soal layar bagi manusia. Ketahui identitas apa yang dipakai agen saat berjalan, apa yang bisa dijangkau identitas itu, dan apakah model menaruh data yang dibutuhkannya di balik objek atau izin yang tidak bisa dipakainya.
Steve Trucking: Satu yang Mudah dan Satu yang Sulit
Section titled “Steve Trucking: Satu yang Mudah dan Satu yang Sulit ”Steve Trucking bekerja sama dengan Mitra Ritel. Apa itu Mitra Ritel? Sebuah bisnis. Mudah: Akun. Saya tidak membuat Retail_Partner__c hanya karena seseorang memakai kata “mitra.”
Sekarang Penerima, orang yang menerima kulkas. Kontak? Akun pribadi? Yang lain? Satu juta Penerima baru per tahun, yang merupakan pelanggan Mitra Ritel, bukan pelanggan kita. Itulah jenis pertanyaan di mana saya tidak ingin melompat ke sebuah objek sebelum memahami hubungan, akses, dan skalanya. Kita akan memutuskannya di checkpoint Bagian 1.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Apakah sebuah konsep bisnis cocok dengan rapi dengan tujuan yang dimaksud dari sebuah objek standar, atau apakah makna atau bebannya berbeda.
- Apakah label bisnis yang berbeda adalah entitas yang berbeda atau sekadar peran yang berbeda dari entitas yang sama.
- Apakah setiap orang, pengguna eksternal, integrasi, dan agen yang butuh data bisa menjangkau objek yang dipilih dengan lisensi yang direncanakan.
- Bagaimana populasi dan pola login (berbasis anggota atau berbasis login) membentuk lisensi dan modelnya.
- Kapan batasan lisensi membenarkan model yang kurang optimal, dan berapa harga pertukaran itu dalam pelaporan dan izin.
Intinya bukan bahwa objek standar itu baik dan objek kustom itu buruk. Intinya adalah pilihan itu punya konsekuensi, dan kadang pilihannya sama sekali tidak ditentukan oleh kata bendanya, melainkan oleh orang-orang, dan mesin-mesin, yang perlu memakainya.
Jelajahi
Section titled “Jelajahi ”- Bantuan Salesforce, Standard User Licenses (opens in a new tab), dicek 2026-10-02, dicek ulang 2026-10-12 (bahasa Inggris): pengguna Platform tidak berhak atas prakiraan, prospek, kampanye, dan peluang; satu aplikasi kustom dengan paling banyak 10 objek kustom; lima lisensi Salesforce Integration di setiap org Enterprise Edition.
- Bantuan Salesforce, Experience Cloud User Licenses (opens in a new tab), dicek 2026-10-02, dicek ulang 2026-10-12 (bahasa Inggris): Partner Community tidak bisa dipakai dengan akun pribadi; Customer Community Plus untuk laporan, dasbor, dan berbagi standar; beberapa login dalam sehari dihitung sebagai satu.
- Bantuan Salesforce, Supported Editions for Service Features (opens in a new tab), dicek 2026-10-02, dicek ulang 2026-10-12 (bahasa Inggris): perjanjian tingkat layanan (manajemen hak layanan) dengan Agentforce Service; Knowledge berbiaya tambahan di sebagian besar edisi.
- Bantuan Salesforce, Available Feature Licenses (opens in a new tab), dicek 2026-10-12 (bahasa Inggris): Service Cloud User, “Access the Salesforce Console for Service”; Marketing User untuk membuat dan mengelola kampanye.