Rancang Model Fisik Salesforce

🌐 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)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 10 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Menjaga Data Tetap Konsisten · Berikutnya: panduan belajar bab ini, lalu bab berikutnya, Memahami Data Perusahaan

Pertanyaan yang dijawab modul ini: Bagaimana kita mengubah model logis kita menjadi arsitektur Salesforce?

Bab ini adalah satu argumen panjang bahwa platform punya bentuk: objek standar dan kustom, tempat-tempat data bisa tinggal, tipe bidang, hubungan, kepemilikan, lisensi, aturan konsistensi, penyimpanan, dan skala. Masing-masing bisa mengubah cara model logis dari bab 2 dibangun. Sekarang mari kita satukan semuanya pada satu potongan Steve Trucking.

Satu potongan, bukan seluruh perusahaan. Kesalahan yang saya lihat dilakukan para arsitek adalah mencoba menyelesaikan seluruh perusahaan dalam satu diagram. Saya ingin sesuatu yang bisa kita nalar: sebuah Mitra Ritel mengirim manifes, Steve Trucking mengirimkan apa yang ada di dalamnya, dan kita menyimpan apa yang kita butuhkan tentang setiap pengiriman. Lalu kita mengambil keputusan fisik satu per satu. Desain lengkapnya ada di checkpoint Bagian 1.

Mulailah dari Apa yang Sudah Kita Ketahui

Bab 2 sudah mengerjakan bagian konseptualnya: Mitra Ritel, Penerima, Manifes, Pengiriman, Item Pengiriman, jenis titik pemberhentian, Kru, Truk, Pusat Distribusi, foto. Kita sudah menamai hubungan-hubungannya dan menanyakan artinya. Saya tidak akan mengulangnya. Pertanyaannya sekarang adalah bagaimana konsep-konsep itu hidup di Salesforce. Satu fakta dari ringkasan langsung penting: Steve Trucking sudah menjalankan Field Service untuk janji temu, kru, dan aplikasi seluler.

Mitra Ritel: Jangan Menciptakan Akun Baru

Mitra Ritel adalah perusahaan yang dilayani Steve Trucking. Salesforce sudah punya objek yang dirancang untuk perusahaan: Akun. Cocok dengan rapi. Jadi tidak ada Retail_Partner__c hanya karena bisnis menyebut “mitra.” Itu Akun, dengan tipe rekaman Retail Partner untuk membedakannya dari organisasi lain, dan bersamanya datang kontrak, kasus, Kontak untuk para manajer DC, dan akses portal untuk Kontak-kontak itu. Keputusan yang mudah. Tidak semuanya begitu.

Nomor Pesanan Mitra Bukanlah Identitas Kita

Setiap Mitra Ritel mengirim referensinya sendiri. Pesanan satu mitra terlihat seperti 8843119, mitra lain seperti A-984732. Nomor-nomor itu penting, tetapi milik siapa? Milik mitra. Salesforce punya record ID-nya sendiri, dan mitra punya referensi yang dipakainya saat berkomunikasi dengan kita. Keduanya bisa ada; itulah “satu hal, beberapa pengenal” dari bab 2.

Jadi referensi mitra menjadi External ID yang dipakai integrasi untuk mencocokkan pembaruan. Dan karena dua mitra bisa memakai nomor yang sama, identitasnya adalah mitra ditambah referensinya, bukan referensinya saja. Jangan menjadikan nomor milik mitra sebagai identitas universal pengiriman hanya karena nomor itu datang lebih dulu, dan jangan membuat integrasi mencari di bidang teks setiap kali ia perlu menemukan sebuah rekaman.

Pengiriman: Lihat ke Kapal Induk

Di sinilah ada godaan untuk membuat Delivery__c. Bisnis menyebut “pengiriman,” jadi kita butuh objek Pengiriman. Justru itulah yang tidak ingin saya Anda lakukan lebih dulu. Lihat ke kapal induk, seperti yang kita lakukan di modul 2. Apa yang sudah dimiliki Salesforce untuk pekerjaan yang dilakukan di sebuah lokasi, dengan siklus hidup, item, penjadwalan, dan kru di lapangan? Work Order (Perintah Kerja) milik Field Service: Salesforce menggambarkannya sebagai pekerjaan layanan lapangan yang dilakukan untuk pelanggan (WorkOrder (opens in a new tab)). Kunjungan terjadwal dan jendela waktunya adalah Service Appointment (Janji Layanan), dan itulah yang dijadwalkan dispatch dan ditampilkan aplikasi kru.

Jadi Pengiriman → Perintah Kerja. Bukan karena katanya cocok; tidak cocok. Melainkan karena perilakunya cocok dengan kemampuan platform yang sudah kita bayar dan memang ingin kita pakai. Objek standar tidak harus memakai kosakata bisnis yang sama. Ia harus merepresentasikan konsepnya dengan benar.

Click to enlarge

Langkah 1 dari 4: kapal induk. Setiap kartu adalah konsep bisnisnya, dengan objek Salesforce-nya di bawahnya.

Tetapi Objek Standar Datang dengan Bawaan

Separuh yang lain: Perintah Kerja tidak gratis. Ia membawa lisensi Field Service, hubungannya sendiri, perilaku keamanan, bidang wajib, otomatisasi, dan siklus hidupnya, dan bagian lain platform berharap ia berperilaku dengan cara tertentu. Kita memilihnya karena kecocokannya rapi dan kita memakai apa yang dibangun di sekitarnya. Jika Steve Trucking sama sekali tidak menginginkan Field Service dan modelnya melawan proses di setiap langkah, saya akan mempertimbangkannya ulang. Arsitekturnya adalah kecocokannya, bukan labelnya.

Item Pengiriman: Ikuti Modelnya

Begitu Pengiriman menjadi Perintah Kerja, lihat sisa model itu sebelum menciptakan apa pun. Work Order Line Item (Item Baris Perintah Kerja) adalah subtugas pada sebuah perintah kerja (WorkOrderLineItem (opens in a new tab)): kulkasnya, pemasangannya, pengangkutan barang lamanya. Jadi Item Pengiriman → Item Baris Perintah Kerja. Perhatikan bahwa keputusan pertama membentuk keputusan kedua. Kita tidak memilih objek untuk setiap entitas secara terpisah. Adopsi sebuah model, dan pahami sisanya sebelum Anda membangun struktur kustom di sekitarnya.

Jenis Titik Pemberhentian Apa Ini?

Di Steve Trucking, sebuah titik pemberhentian bisa berupa hanya pengiriman, pengiriman dengan pemasangan, atau pengiriman dengan pengangkutan barang lama, dan setiap jenis punya durasi, keterampilan kru, dan daftar periksa pemasangannya sendiri. Di bab 2 kita memutuskan bahwa itu entitas, bukan label. Field Service sudah punya satu: Work Type (Tipe Pekerjaan), sebuah templat untuk jenis pekerjaan yang bisa diterapkan pada perintah kerja dan item barisnya (WorkType (opens in a new tab)). Jadi Jenis Titik Pemberhentian → Tipe Pekerjaan. Sekali lagi, bukan karena ada sesuatu bernama Work Type, melainkan karena konsep dan perilakunya selaras.

Click to enlarge

Langkah 2 dari 4: ikuti modelnya. Item baris dan Tipe Pekerjaan datang bersama Perintah Kerja.

Manifes: Sekarang Saya Ingin Objek Kustom

Apakah ada objek standar untuk “daftar milik mitra untuk hari Selasa di DC Phoenix”? Tidak juga, dan saya tidak akan memaksakannya ke objek yang tidak terkait hanya agar bisa bilang kita tetap standar. Manifes → Manifest__c. Itulah unit penerimaannya: dari mana ia datang (file, batch API), kapan, status dan totalnya, dan, ketika mitra mengirim ulang di hari yang sama, apa yang dibandingkan. Setiap baris manifes menjadi Perintah Kerja yang ditautkan kembali ke manifes itu.

Kustom bukanlah kegagalan. Itulah yang diberikan platform ketika sebuah konsep tidak punya rumah standar yang rapi. Kesalahannya bukan membuat objek kustom; kesalahannya adalah membuatnya tanpa memeriksa apakah platform sudah punya konsep itu.

Click to enlarge

Langkah 3 dari 4: satu-satunya objek kustom, di tempat tidak ada objek standar yang cocok.

Foto: Hanya karena Salesforce Bisa Menyimpannya, Bukan Berarti Harus

“Kami butuh foto-foto pengiriman di Salesforce.” Apa arti “di Salesforce”? Pengguna perlu melihatnya dari Salesforce, ya. Apakah itu berarti file gambarnya harus tinggal di penyimpanan core? Belum tentu. Hitung nolnya: sekitar empat foto per pengiriman, lebih banyak untuk pemasangan, dengan satu juta pengiriman per tahun, berarti empat sampai lima juta foto per tahun, dan pengiriman bertumbuh 30% per tahun.

Jadi posisi awal saya: jangan mengubah org core menjadi gudang foto raksasa hanya karena pengguna butuh akses ke foto. File-filenya seharusnya berada di penyimpanan yang dibangun untuk volume itu, di luar core, dengan Salesforce menyimpan apa yang dibutuhkannya untuk menemukan dan menampilkannya: rujukan, jumlah, atau rekaman indeks kecil per foto, dan penanda bahwa foto pemasangan yang wajib sudah lengkap. Akses ke data dan di mana data tinggal secara fisik adalah dua pertanyaan yang berbeda. Itu modul 4 yang kembali muncul.

Bidang: Buat Maknanya Terlihat

Perintah Kerja butuh bidang-bidang: referensi mitra, jendela waktu pengiriman, waktu pengiriman aktual, status, catatan seperti “kode gerbang” atau “ada anjing di halaman.” Saya tidak akan mengubah ini menjadi katalog bidang; modul 6 sudah melakukannya. Ajukan pertanyaan-pertanyaannya untuk masing-masing: apa artinya, siapa pemiliknya, apakah berubah, apakah ia pengenal, kosakata terkendali, disimpan atau diturunkan, sensitif. Referensi mitra adalah External ID, jadi keunikannya adalah bagian dari kontrak integrasi, bukan sekadar kotak centang. Waktu pengiriman aktual adalah sebuah momen, jadi Date/Time. Status menggerakkan perilaku, jadi daftar terkendali, tidak pernah teks bebas. Dan catatan pengiriman tentang rumah seseorang adalah data pribadi, jadi diklasifikasikan. Setiap bidang bisa ditelusuri kembali ke maknanya.

Hubungan: Jangan Sekadar Menghubungkan Kotak

Akun ke Perintah Kerja, Perintah Kerja ke item-item barisnya, Manifes ke Perintah Kerja, Tipe Pekerjaan yang menggambarkan titik pemberhentian. Lalu pertanyaan-pertanyaan modul 7 untuk setiap garis: bisakah anak berdiri sendiri, siapa pemiliknya, apakah akses diwarisi, bisakah ia pindah, apa yang terjadi saat dihapus, berapa banyak anak yang bisa menumpuk? Setiap Perintah Kerja di bawah segelintir akun Mitra Ritel berarti ratusan ribu anak per induk: pertanyaan skew yang akan kita jawab di Bagian 2. Dan untuk hubungan-hubungan standar Field Service, periksa bagaimana Salesforce sudah membangunnya alih-alih berasumsi semuanya sesuai dengan apa yang akan kita rancang. Ketika Anda mengadopsi model standar, Anda mengadopsi keputusan-keputusan yang diambil Salesforce di dalamnya. Pahami semuanya sebelum Anda membangun di atasnya.

Kepemilikan dan Penerima: Jangan Biarkan Pengaturan Bawaan yang Memutuskan

Dua keputusan yang dengan senang hati akan diambilkan oleh pengaturan bawaan untuk kita.

Siapa pemilik sebuah pengiriman? Kita sudah menjawabnya di modul 8, dan jawabannya terbawa langsung ke Perintah Kerja: kepemilikan tidak menentukan akses siapa pun di sini, jadi pengguna integrasi memiliki Perintah Kerja yang dibuatnya. Dispatcher melihat milik pusat distribusinya, kru melihat milik rute mereka, dan setiap Mitra Ritel melihat miliknya sendiri melalui portal, semuanya melalui berbagi, bukan kepemilikan. Pengguna integrasi tidak punya peran dan dijauhkan dari grup publik yang dipakai aturan berbagi kita, karena dengan 3.300 per hari ia melewati 10.000 rekaman dalam tiga hari. Dan kita mencatat apa yang terjadi jika pengguna itu suatu saat diganti.

Apa itu Penerima? Sebuah Kontak? Akun pribadi? Sesuatu yang hanya disimpan di pengiriman? Itu bergantung pada apakah Steve Trucking punya hubungan dengan orang-orang ini sama sekali (mereka adalah pelanggan para Mitra Ritel), apakah satu mitra boleh melihat penerima milik mitra lain, berapa lama data pribadi mereka boleh disimpan, dan skalanya: sekitar satu juta Penerima baru per tahun. Kita belum punya semua itu, dan itu tidak apa-apa. Kadang jawaban yang tepat adalah kita belum cukup tahu. Catat pertanyaannya dan carilah informasinya; jangan mengubur ketidakpastian itu di dalam objek kustom. Kita menjawabnya di checkpoint Bagian 1, setelah bab 4 sampai 6 memberi kita gambaran perusahaan dan data master.

Konsistensi: Lindungi Model di Lapisan yang Tepat

Tangga dari modul 9 berlaku: referensi mitra adalah External ID, unik, sehingga manifes yang dikirim ulang melakukan upsert alih-alih membuat duplikat; status adalah daftar terbatas; waktu pengiriman aktual wajib hanya setelah statusnya menyatakan Delivered; titik pemberhentian pemasangan tidak bisa ditutup tanpa daftar periksa dan fotonya. Bukan satu flow raksasa. Setiap aturan di anak tangganya sendiri.

Di Mana Setiap Bagian Tinggal

Satu putaran lagi atas potongan ini, dengan pertanyaan modul 4: di mana setiap bagian data tinggal? Di slide kelas saya, ini satu slide, logis berhadapan dengan fisik: entitas-entitas logis dari bab 2, dan di mana masing-masing mendarat secara fisik: di core, sebagai sObject (__c jika kustom) atau big object (__b), atau di luar core (off-core), sebagai objek eksternal (__x) atau data yang sama sekali tidak pernah masuk ke Salesforce.

• Di core, dipakai setiap hari: Akun, Perintah Kerja beserta item-item barisnya, Janji Layanan, Tipe Pekerjaan, Manifest__c.
• Di core, diarsipkan: pengiriman yang lebih tua dari tiga tahun pindah ke Riwayat Pengiriman (Delivery History), sebuah big object, tetap ada untuk klaim, di gudang belakang.
• Dirujuk: detail pesanan milik Mitra Ritel sendiri tetap di sistem mitra; kita menyimpan referensi mitra sebagai External ID, dan menjangkau sisanya melalui objek eksternal atau integrasi ketika seseorang membutuhkannya.
• Di luar core: foto-foto, di penyimpanan yang dibangun untuk jutaan gambar, dengan tautan dari Perintah Kerja.

Itulah model fisiknya: bukan hanya objek yang mana, tetapi rumah yang mana.

Sekarang Lihat Seluruh Potongannya

• Mitra Ritel → Akun, dengan tipe rekaman Retail Partner; manajer DC sebagai Kontak.
• Pengiriman → Perintah Kerja Field Service, dijadwalkan melalui Janji Layanan.
• Item Pengiriman → Item Baris Perintah Kerja.
• Jenis Titik Pemberhentian → Tipe Pekerjaan.
• Manifes → kustom Manifest__c.
• Referensi mitra → External ID di Perintah Kerja, unik per mitra.
• Foto → disimpan di luar core; Salesforce menyimpan rujukan dan penanda kelengkapannya.
• Riwayat pengiriman → diarsipkan ke big object setelah tiga tahun.
• Kepemilikan → pengguna integrasi, dengan akses melalui berbagi (modul 8).
• Penerima → terbuka, untuk checkpoint Bagian 1.

Click to enlarge

Langkah 4 dari 4: seluruh potongan, di core, diarsipkan, dan di luar core. Setiap garis adalah lookup: Salesforce membangun Field Service di atas lookup, dan kita mengadopsi keputusan-keputusannya bersamanya.

Diagram Bukanlah Arsitekturnya

Saya bisa menyerahkan diagram itu kepada Anda, dan itu belum cukup. Arsitekturnya adalah penalaran di baliknya. Mengapa Akun? Sebuah perusahaan yang cocok dengan rapi. Mengapa Perintah Kerja dan bukan Delivery__c? Pengiriman berperilaku seperti pekerjaan lapangan, dan Field Service sudah ada. Mengapa Manifes kustom? Tidak ada rumah standar yang rapi. Mengapa foto tidak sekadar File? Volume dan hitungan ekonomi penyimpanan. Mengapa External ID? Sistem lain butuh identitas yang stabil melintasi batas. Mengapa pengguna integrasi memiliki Perintah Kerja? Kepemilikan tidak menentukan akses di sini, dan itu menjaga jejak audit tetap jujur. Mengapa Penerima masih terbuka? Kita belum menjawab cukup banyak pertanyaan. Garis-garisnya adalah hasil; keputusan-keputusanlah yang menghasilkannya.

Jadi inilah kebiasaan yang ingin saya Anda bawa keluar dari bab 3. Tunjuk apa pun di sebuah model fisik dan tanyakan mengapa? Mengapa objek ini, tipe ini, hubungan ini, pemilik ini, tempat ini, aturan ini? Anda seharusnya bisa menelusuri jawabannya ke belakang: dari konfigurasi, ke model fisik, ke model logis, ke persyaratan bisnis. Jika tidak bisa, seseorang telah merancang dari Setup.

Dan Anda tentu sudah memperhatikan angka-angka yang belum sepenuhnya kita kerjakan: pengiriman per mitra, item baris, foto, retensi, pengarsipan. Bagus. Tanyakan jumlah nolnya sebelum Anda mengunci sebuah desain: model yang bekerja dengan indah pada lima puluh ribu rekaman bisa berperilaku sangat berbeda pada lima ratus juta. Itu Bagian 2.

Di luar ujian: apa yang diubah AI. Berikan ringkasan Steve Trucking kepada AI dan ia akan menghasilkan skema dalam hitungan detik: Akun, Perintah Kerja, objek kustom, bidang, bahkan metadata deployment. Itu akselerator yang luar biasa, dan itu bukan tinjauannya. Tugas arsitek bergeser menjadi memeriksa pemetaan dan konsekuensinya: kecocokan, lisensi, kepemilikan, siklus hidup, skala, identitas, keamanan, dan apa yang tetap di luar platform. AI adalah pendorong roket; ia tidak memberi tahu Anda apakah Anda sudah mengarah ke tujuan yang benar.

Yang Diputuskan Arsitek di Sini

• Bagaimana setiap konsep bisnis dipetakan ke Salesforce: objek standar, objek kustom, atau sesuatu di luar core.
• Pengenal, bidang, dan hubungan mana yang mengimplementasikan makna bisnis tanpa diam-diam mengubahnya.
• Perilaku platform dan lisensi apa yang ikut datang bersama model standar yang Anda adopsi.
• Keputusan kepemilikan, siklus hidup, konsistensi, penyimpanan, dan skala mana yang harus diambil sebelum desainnya lengkap.
• Pertanyaan mana yang secara eksplisit dibiarkan terbuka, alih-alih disembunyikan di balik pilihan implementasi yang sembarangan.

Di awal bab ini kita bertanya bagaimana model seharusnya hidup di Salesforce. Itulah arsitektur data Salesforce: bukan membuat objek, bukan menghafal Setup, bukan menggambar kotak yang lebih cantik, melainkan dengan sengaja menyesuaikan model bisnis dengan bentuk platform. Setiap struktur adalah sebuah komitmen. Buatlah yang bisa Anda jelaskan.

Jelajahi

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab), dan WorkType (opens in a new tab), dicek 2026-10-02 (bahasa Inggris).
• Ringkasan Steve Trucking (bahasa Inggris).