Lewati ke konten

Model Data Standar

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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Gambar dibuat dengan AI

Modul 2 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Platform Data Salesforce: Lebih dari Sekadar Database · Berikutnya: Bangun Sendiri: Objek Kustom

Pertanyaan yang dijawab modul ini: Apa yang sudah dimodelkan Salesforce untuk Anda, dan bagaimana semuanya disusun?

Di modul 1 saya meminta Anda untuk lihat ke kapal induk: sebelum menciptakan sesuatu, lihat bagaimana Salesforce sendiri melakukannya. Di modul inilah kita benar-benar melihatnya. Salesforce sudah memodelkan banyak bagian bisnis untuk Anda, dalam objek standar-nya, dan dua dari model itu mengerjakan sebagian besar pekerjaan di kebanyakan org yang saya masuki: model Sales dan model Service. Sebelum Anda bisa memutuskan apakah sesuatu layak menjadi objek kustom, Anda perlu tahu apa yang sudah ada. Itulah isi dua modul berikutnya.

Apa yang Membuat Sebuah Objek Menjadi Standar

Section titled “Apa yang Membuat Sebuah Objek Menjadi Standar ”

Objek standar sudah tersedia sejak awal. Salesforce yang membangunnya, ia punya tujuan yang jelas, dan ia datang dengan bidang dan hubungannya sendiri. Anda bisa menambahkan bidang ke dalamnya, membangun otomatisasi di sekitarnya, dan mengubah tata letaknya, tetapi Anda tidak bisa merancang ulang objek itu: bidang dan hubungan standarnya adalah milik Salesforce.

Lihat namanya. Account, Contact, Case. Tanpa awalan, tanpa akhiran. Itu cara Salesforce menyisakan ruang itu untuk dirinya sendiri. Semua yang kita bangun berakhiran __c, sehingga Salesforce bisa menambah objek standar baru kapan saja tanpa pernah bertabrakan dengan apa pun di org Anda. Dan memang itu yang dilakukannya, di setiap rilis.

Di suatu masa, seseorang membangun objek produk yang tidak berhasil dan harus ditinggalkan. Itulah sebabnya nama API-nya Product2. Itu uji lakmus pertama saya ketika seseorang bilang ia mengenal Salesforce.

Mulailah dari kiri, dengan Prospek (Lead): seseorang yang mungkin menjadi pelanggan. Sebuah prospek sebenarnya belum menjadi bagian dari model. Ia adalah tempat penampungan sementara. Saat Anda mengonversinya, Salesforce membuat rekaman yang sesungguhnya: sebuah Akun (Account), sebuah Kontak (Contact), dan, jika ada kesepakatan, sebuah Peluang (Opportunity). Itulah sebabnya saya menggambar Prospek di samping.

Akun adalah perusahaannya. Kontak-nya adalah orang-orang di perusahaan itu. Sebuah Peluang adalah kesepakatan dengan akun tersebut. Sejauh ini, tidak ada yang tidak Anda duga.

Lalu mulai menarik. Apa isi kesepakatan itu? Setiap barisnya adalah Produk Peluang (Opportunity Product), dan sebuah Produk Peluang tidak menunjuk langsung ke sebuah Produk. Ia menunjuk ke sebuah Entri Buku Harga (Price Book Entry): produk ini, dengan harga ini, di buku harga ini. Entri Buku Harga berada di antara Produk (Product) dan Buku Harga (Price Book), sehingga produk yang sama bisa punya satu harga di buku harga standar dan harga lain di buku harga mitra Anda.

Itu dua hubungan yang menjadi benda, satu setelah yang lain. Ingat Item Pengiriman dari bab 2, di antara Pengiriman dan Produk, dan Trik Anjing di antara Anjing dan Trik? Salesforce melakukan hal yang persis sama di sini, dua kali: Produk Peluang di antara Peluang dan Entri Buku Harga, dan Entri Buku Harga di antara Produk dan Buku Harga. Begitu Anda bisa membaca itu, Anda bisa membaca sebagian besar model data standar.

Model Sales Model Sales. Sebuah Prospek, di sebelah kiri, dikonversi menjadi Akun. Sebuah Akun punya Kontak dan Peluang. Sebuah Peluang memakai sebuah Buku Harga dan berisi Produk Peluang. Setiap Produk Peluang diberi harga oleh satu Entri Buku Harga. Sebuah Buku Harga mencantumkan Entri Buku Harga, dan sebuah Produk muncul di Entri Buku Harga, sehingga setiap Entri Buku Harga menghubungkan satu Produk dan satu Buku Harga. dikonversi menjadi punya punya memakai berisi diberi harga oleh mencantumkan muncul di Prospek Akun Kontak Peluang Buku Harga Produk Peluang Entri Buku Harga Produk tepat satu nol atau satu satu atau banyak nol atau banyak © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Inilah rantai itu dari dekat, dengan bidang-bidang yang menyatukannya:

Rantai harga dari dekat Rantai harga sebagai model data terperinci. Sebuah Produk Peluang membawa ID Peluang-nya, ID Entri Buku Harga-nya, kuantitas, dan harga jual, dan diberi harga oleh satu Entri Buku Harga. Entri Buku Harga membawa ID Buku Harga-nya, ID Produk-nya, harga daftar, dan penanda Pakai Harga Standar (Use Standard Price). Sebuah Buku Harga punya nama dan penanda Standar (Is Standard); sebuah Produk punya nama dan kode produk. diberi harga oleh mencantumkan muncul di Buku Harga ID Buku Harga RECORD ID Nama Standar Produk Peluang ID Produk Peluang RECORD ID ID Peluang ID Entri Buku Harga Kuantitas Harga Jual Entri Buku Harga ID Entri Buku Harga RECORD ID ID Buku Harga ID Produk Harga Daftar Pakai Harga Standar Produk ID Produk RECORD ID Nama Kode Produk tepat satu nol atau satu satu atau banyak nol atau banyak © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Satu aturan yang sering membuat orang tersandung: ada buku harga standar, dan sebuah Entri Buku Harga di buku harga lain mana pun bisa langsung memakai harga standar produk tersebut. Ketahui buku harga mana yang dipakai sebuah peluang sebelum Anda memuat produk-produknya.

Sekarang sisi lain dari rumah ini. Akun yang sama, Kontak yang sama. Ketika ada yang salah, pelanggan membuka sebuah Kasus (Case).

Kasus itu biasanya tentang sesuatu yang dimiliki pelanggan, dan Salesforce punya objek untuk itu: Aset (Asset). Di modul 5 saya akan menyebutnya objek standar yang sering diabaikan orang. Aset adalah sesuatu yang dimiliki pelanggan, entah mereka membelinya dari Anda atau tidak.

Lalu, layanan apa yang menjadi hak pelanggan? Itulah Hak Layanan (Entitlement): dukungan yang berhak diterima sebuah akun, sering kali terkait dengan sebuah aset, produk, atau kontrak layanan. Pasang hak layanan pada sebuah kasus, dan kini kasus itu tahu tingkat dukungan apa yang seharusnya ia dapatkan.

Model Service Model Service. Sebuah Akun punya Kontak, Kasus, dan Aset. Sebuah Kontak melaporkan Kasus. Sebuah Kasus bisa tentang satu Aset, dan sebuah Hak Layanan (Entitlement), yang dimiliki sebuah Akun, mencakup Kasus. Sebuah garis dari Kasus kembali ke dirinya sendiri, mengitari sudutnya, adalah Parent Case (Kasus Induk): sebuah kasus adalah induk dari nol atau banyak kasus, dan setiap kasus punya nol atau satu induk. punya punya melaporkan memiliki tentang mencakup induk dari Akun Kontak Aset Kasus Hak Layanan tepat satu nol atau satu satu atau banyak nol atau banyak © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Lihat garis yang berjalan dari Kasus kembali ke dirinya sendiri. Setiap kasus punya bidang Parent Case (Kasus Induk), dan bidang itu menunjuk ke kasus lain. Itulah self-lookup: hubungan dari sebuah objek ke dirinya sendiri. Banyak orang bingung saat pertama kali melihatnya, jadi inilah dua alasan saya memakainya.

Pertama: masalah besar yang pecah menjadi masalah-masalah kecil. Pelanggan melaporkan bahwa seluruh instalasinya mati. Kita membuka sub-kasus untuk jaringan, perangkat keras, dan konfigurasi, masing-masing dikerjakan sendiri, dan semuanya terselesaikan ke atas: kasus induk belum selesai sampai semuanya selesai.

Kedua: riwayat. Sebuah kasus ditutup bulan lalu, dan sekarang masalah yang sama muncul lagi. Kasus baru menunjuk kembali ke kasus aslinya, sehingga siapa pun yang membukanya bisa melihat bahwa ini pernah terjadi sebelumnya, dan apa yang dilakukan untuk mengatasinya.

Kita akan kembali ke self-lookup saat sampai pada hubungan di modul 7.

Perhatikan bahwa Akun dan Kontak berada di tempat yang sama di kedua diagram. Keduanya adalah rekaman yang sama. Seorang tenaga penjualan dan seorang agen layanan melihat pelanggan yang sama, dari sisi rumah yang berbeda. Itulah salah satu argumen terkuat untuk tetap memakai yang standar: model-model ini dibangun untuk saling bertemu.

Tidak semua yang ada pada sebuah rekaman adalah bidang. Kontrak, foto, PDF, dan spreadsheet adalah file, dan tempatnya di Salesforce Files, bukan di model Attachments yang lama, yang sudah warisan (legacy). Jika dokumennya sudah tinggal di SharePoint Online, OneDrive, Google Drive, atau Box, Files Connect memungkinkan pengguna menjangkaunya dari Salesforce tanpa menyalinnya ke dalam.

File dihitung secara berbeda dari rekaman. Salesforce membagi penyimpanan menjadi dua: penyimpanan file menampung lampiran, Files, Salesforce CRM Content, file Chatter, dan sejenisnya, sedangkan penyimpanan data menampung rekaman Anda. Penyimpanan file naik cepat ketika setiap rekaman mendapat foto atau hasil pindaian, jadi gambar dalam volume besar, seperti foto dari aplikasi lapangan, sering kali lebih tepat berada di luar Salesforce sepenuhnya, dengan Salesforce hanya menyimpan tautannya. Modul 4 akan kembali ke hal itu.

Penyimpanan data juga dihitung secara berbeda dari sebuah database. Di database biasa, tabel dengan dua kolom dan sejuta baris itu kecil, dan tabel dengan seratus kolom dan sejuta baris itu gajah. Salesforce menimbang keduanya sama: sebagian besar rekaman dihitung sekitar 2 KB, berapa pun jumlah bidangnya. Ada pengecualian. Sebuah kampanye dihitung lebih besar, sebuah pesan email dihitung sesuai ukuran sebenarnya, dan sebuah akun pribadi dihitung sekitar 4 KB, karena ia adalah akun sekaligus kontak.

Ini satu tips. Setiap kali saya masuk ke org baru, salah satu tempat pertama yang saya tuju adalah Setup → Storage Usage (Penggunaan Penyimpanan). Saya bahkan akan meminta tangkapan layarnya kepada klien di panggilan pertama. Layar itu tidak berbohong. Ia memberi tahu Anda objek mana yang sedang tumbuh, dan mana yang sudah menjadi gajah.

Akun Pribadi: Ketika Pelanggannya Adalah Perorangan

Section titled “Akun Pribadi: Ketika Pelanggannya Adalah Perorangan ”

Model Akun dan Kontak bekerja dengan indah untuk sebuah perusahaan dan orang-orang di dalamnya. Tetapi bagaimana jika pelanggan Anda bukan perusahaan? Bagaimana jika pelanggannya adalah perorangan?

Itulah akun pribadi (person account): akun dan kontak yang digabungkan menjadi satu rekaman, untuk orang perorangan. Bidang kontaknya ikut terbawa, dan bidang kustomnya muncul dengan akhirannya sendiri, __pc. Masing-masing dihitung terhadap penyimpanan akun sekaligus kontak, karena di baliknya ia adalah keduanya.

Satu peringatan sebelum Anda mengaktifkannya: begitu akun pribadi diaktifkan, fitur itu tidak bisa dinonaktifkan. Itulah Uji Reversibilitas dari bab 1 dalam bentuknya yang paling murni. Modul 5 memberi Anda posisi saya tentang kapan fitur ini sepadan.

  • Bagian bisnis mana yang sudah dimodelkan Salesforce, sebelum ada hal baru yang dirancang.
  • Apakah sebuah konsep masuk ke model Sales, model Service, atau keduanya, dengan menyadari bahwa keduanya berbagi Akun dan Kontak.
  • Di mana dokumen dan gambar tinggal: Salesforce Files, sistem file yang terhubung, atau di luar platform dengan sebuah tautan.
  • Berapa biaya penyimpanan data itu, dihitung dengan cara Salesforce menghitungnya: rekaman, bukan kolom.
  • Apakah pelanggannya perusahaan atau perorangan, sebelum mengaktifkan sesuatu yang tidak bisa dimatikan.

Lalu, bagaimana jika Salesforce tidak punya yang Anda butuhkan? Anda membangunnya. Itu berikutnya.

  • OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (dicek 2026-10-12, bahasa Inggris): “a member of the list of Product2 products associated with an Opportunity” (anggota daftar produk Product2 yang terkait dengan sebuah Peluang); Entri Buku Harga wajib diisi.
  • PricebookEntry (opens in a new tab), Object Reference (dicek 2026-10-12, bahasa Inggris): “an association between a Pricebook2 and Product2” (hubungan antara Pricebook2 dan Product2); sebuah entri bisa memakai harga standar.
  • Case (opens in a new tab), Object Reference (dicek 2026-10-12, bahasa Inggris): ParentId, “the ID of the parent case in the hierarchy. The label is Parent Case” (ID kasus induk dalam hierarki; labelnya Parent Case); sebuah lookup ke Case.
  • Entitlement (opens in a new tab), Object Reference (dicek 2026-10-12, bahasa Inggris): “the customer support an account or contact is eligible to receive” (dukungan pelanggan yang berhak diterima sebuah akun atau kontak), yang bisa didasarkan pada aset, produk, atau kontrak layanan.
  • Data and Storage Resources (opens in a new tab), Bantuan Salesforce (dicek 2026-10-12, bahasa Inggris): apa saja yang termasuk dalam penyimpanan file dan penyimpanan data.
  • Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Bantuan Salesforce (dicek 2026-10-12, bahasa Inggris): “Most Salesforce records consume approximately 2 KB of data storage” (sebagian besar rekaman Salesforce memakai sekitar 2 KB penyimpanan data); akun pribadi sekitar 4 KB.
  • Enable Person Accounts (opens in a new tab), Bantuan Salesforce (dicek 2026-10-12, bahasa Inggris): “After Person Accounts is enabled, it can’t be disabled.” (Setelah Akun Pribadi diaktifkan, fitur itu tidak bisa dinonaktifkan.)
  • Files Connect FAQ (opens in a new tab), Bantuan Salesforce (dicek 2026-09-25, bahasa Inggris).