Di Mana Data Ini Tinggal?

🌐 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 4 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Bangun Sendiri: Objek Kustom · Berikutnya: Pilih Objek yang Tepat

Pertanyaan yang dijawab modul ini: sebelum Anda membuat sebuah objek, di mana sebenarnya data ini seharusnya tinggal: di core di Salesforce, dirujuk di tempat ia sudah berada, atau diarsipkan?

Saya ingin bertanya. Sebuah persyaratan baru tiba di meja Anda. Apa hal pertama yang Anda lakukan?

Jika Anda seperti kebanyakan dari kita, Anda membuka Setup dan membuat objek kustom. Saya paham. Dalam sepuluh menit Anda sudah punya tab, tata letak halaman, dan tampilan daftar. Dan inilah yang saya katakan di setiap kelas: begitu Anda membuat objek baru itu, Anda sudah berpikir seperti arsitek, disengaja atau tidak. Karena setiap objek yang Anda buat adalah sebuah komitmen. Ia memakan penyimpanan. Ia terkena batasan. Ia mendapat model berbagi, entah Anda merancangnya atau tidak. Ia butuh lisensi untuk siapa pun yang menyentuhnya. Dan begitu orang dan integrasi bergantung padanya, semoga berhasil kalau ingin menghapusnya.

Jadi keputusan arsitektur pertama bukanlah objek yang mana. Keputusannya adalah di mana data ini seharusnya tinggal? Jawab itu dengan benar dan tipe objeknya hampir memilih dirinya sendiri.

Di Core dan di Luar Core

Pertama, sebuah kata yang akan sering saya pakai: core. Core adalah platform Salesforce tempat org Anda berjalan: platform multitenant berbasis metadata dari modul 1, tempat objek-objek Sales dan Service dari modul 2 tinggal, beserta setiap objek kustom yang Anda bangun di modul 3. Ketika saya bilang data ada di core, maksud saya data itu disimpan di org Anda, di objek-objeknya.

Tidak semua data tinggal di sana. Data 360 menyimpan datanya di penyimpanannya sendiri, di luar objek-objek org Anda (ia near-core, dekat core: dikelola di core, datanya di-hosting di luar core; selengkapnya di bab 4). Lalu ada semua hal yang dijalankan perusahaan Anda yang sama sekali bukan Salesforce: ERP, gudang, sistem pesanan, platform milik mitra. Semua itu ada di luar core (off-core). Salesforce bisa menjangkaunya, menampilkannya, dan memakainya, tetapi org Anda tidak menyimpannya.

Di core, ada dua jenis objek yang benar-benar menampung rekaman Anda: sObject, standar maupun kustom (__c), dan big object (__b). Di luar core, Anda menjangkau data melalui objek eksternal (__x) dan alat integrasi lainnya. Ingat akhiran-akhiran dari modul 3 itu; akhiran memberi tahu Anda di mana sepotong data tinggal hanya dari namanya.

Saya membayangkannya seperti sebuah kantor. Ada barang yang tempatnya di meja Anda, karena Anda memakainya setiap hari. Ada barang yang cukup Anda cari di lemari arsip orang lain. Dan ada barang yang masuk ke kardus di gudang belakang. Itu memberi saya tiga jawaban.

1. Di Core: Ia Tinggal di Meja Anda

Datanya dibuat, diubah, dan dipakai di Salesforce setiap hari: akun, kasus, peluang, perintah kerja. Menyimpannya di sObject itu seperti menaruhnya di bagian depan kantor Anda. Untuk inilah objek standar dan kustom ada, dan Anda mendapat semuanya: tata letak halaman, berbagi, otomatisasi, pelaporan, pencarian, dan kini fitur-fitur AI yang dibangun di atas model data.

Tetapi meja Anda tidak gratis. Data di core memakan penyimpanan, dihitung dengan cara Salesforce menghitungnya, per rekaman, bukan per kolom, dan dokumen dihitung terpisah terhadap penyimpanan file. Kita sudah membahas keduanya di modul 2. Foto dan pindaian dalam volume besar sering kali lebih tepat berada di luar core, dengan Salesforce hanya menyimpan tautannya.

2. Dirujuk: Ia Tinggal di Lemari Arsip Orang Lain

Datanya milik sistem lain (ERP, data warehouse, platform pesanan), dan sistem itu tetap menjadi sumber kebenarannya. Pengguna perlu melihatnya di Salesforce, mungkin menghubungkannya dengan sebuah rekaman, tetapi Salesforce tidak butuh salinannya sendiri. Anda juga akan mendengar ini disebut data virtual: ia muncul di Salesforce secara virtual, tanpa pernah disimpan di sana.

Itulah objek eksternal, melalui Salesforce Connect. Saya suka bilang ia kelihatan seperti bebek dan berjalan seperti bebek, tetapi ia bukan bebek. Ia muncul seperti sObject: Anda bisa menaruhnya di tata letak halaman dan daftar terkait, dan menghubungkannya dengan rekaman Anda sendiri melalui external lookup dan indirect lookup. Tetapi datanya tidak disimpan di core. Setiap kali Anda menyentuhnya, ia melakukan callout. Buka sebuah rekaman, muat daftar terkait, jalankan laporan, dan Salesforce pergi bertanya ke sistem lain itu. Artinya ada latensi, dan halaman Anda hanya setersedia sistem di baliknya.

Orang sering keberatan dengan biaya lisensinya, jadi hitunglah seperti yang saya lakukan di kelas. Connect dilisensikan per endpoint, dan satu endpoint bisa membawa masuk banyak objek. Sekarang tanyakan berapa biaya membangun dan memelihara alternatifnya: komponen kustom, kode callout di baliknya, dan developer yang siaga ketika ada yang rusak. Sering kali lisensinya lebih murah, dan admin Anda bisa mengonfigurasinya tanpa menulis satu baris kode pun. Kelemahannya: data yang diedit pengguna sepanjang hari, atau dilaporkan secara intensif.

Dokumen juga bisa dirujuk. Jika sebuah kontrak sudah tinggal di SharePoint Online, OneDrive, Google Drive, atau Box, Files Connect memungkinkan pengguna menjangkaunya dari Salesforce tanpa menyalinnya ke dalam.

Salesforce Connect bukan satu-satunya cara merujuk data. Kadang caranya adalah logika kustom: kode yang memanggil sistem lain secara waktu nyata dan menampilkan datanya di halaman, tanpa menyimpan salinan. Itu memberi Anda kendali penuh, sekaligus tanggung jawab penuh atas callout, error, dan pemeliharaannya. Dan Data 360 juga bisa melakukan federasi tanpa menyalin. Pilihan itu punya babnya sendiri (Virtualisasi, Federasi, dan Zero Copy). Di sini, intinya adalah keputusannya sendiri: rujuk, jangan salin.

3. Diarsipkan: Ia Masuk ke Gudang Belakang

Riwayat, jejak audit, transaksi lama. Anda harus menyimpannya, kadang bertahun-tahun, tetapi hampir tidak ada yang membukanya. Dan inilah yang sering ditunda tim. Ketika sebuah kelas bilang mereka punya objek dengan 50 juta rekaman dan bertanya mengapa harus mengarsipkan, saya balik bertanya: jika Anda tidak mengarsipkan hari ini, apakah Anda akan pernah mengarsipkan? Di 50 juta hari ini, Anda sedang menuju 100, 150, 200 juta.

Ada dua gudang. Yang satu ada di core: big object. Anggap saja seperti menyimpan data di garasi. Anda bisa menyimpan rekaman dalam jumlah sangat besar, tetapi Anda tidak bisa menaruhnya di tata letak halaman, tidak ada UI atau pelaporan standar, dan Anda mengkueri melalui indeks big object, dengan pencocokan persis atau rentang (Big Objects Best Practices (opens in a new tab)). Keamanannya hanya izin objek dan bidang, tanpa berbagi tingkat rekaman, dan otomatisasi tidak berjalan di atasnya. Saya sudah puluhan kali memakai Salesforce Connect dan big object hanya sekali atau dua kali. Big object berfungsi, tetapi canggung, dan saya sudah menulis cukup banyak solusi akal-akalan untuk mengambil datanya. Jadi saran saya: buat prototipenya sebelum Anda menyarankannya, dan rencanakan bagaimana orang akan menemukan datanya sebelum Anda memilihnya.

Gudang yang lain ada di luar core: data warehouse atau database di tempat lain (Merancang untuk Skala). Sering kali itulah gudang yang lebih baik, dan ia tidak harus tersembunyi. Data yang diarsipkan di luar core tetap bisa muncul di laporan melalui alat seperti Tableau, dan tetap bisa dijangkau dari Salesforce, melalui Salesforce Connect atau cara virtualisasi lain, ketika seseorang perlu melihat ke belakang.

Biar saya ceritakan sebuah proyek di mana kami melakukannya dengan benar sejak awal. Seorang klien ritel punya lebih dari 1.200 lokasi. Mereka bilang kepada saya, “Kami hanya melayani seratus janji temu sehari di setiap toko. Bukan masalah besar.” Lalu saya menghitung: seratus sehari, enam hari seminggu (sekitar 305 hari setahun), di 1.200 lokasi, adalah lebih dari 36 juta janji temu per tahun. Lalu mereka menyebutkan bahwa setiap kunjungan membuat dua janji temu, satu di meja depan dan satu untuk bagian belakang toko: lebih dari 73 juta rekaman per tahun. Lalu mereka menginginkan riwayat lima tahun: lebih dari 360 juta rekaman, sebelum pertumbuhan apa pun. Kami belum go-live, dan saya sudah bisa melihat keretanya melaju lurus menuju stasiun volume data besar. Jadi arsipnya dibangun sebelum kami mengumpulkan satu janji temu pun: janji temu yang lebih lama dipindahkan ke big object, dan layar pencarian menampilkan janji temu terkini dengan yang sudah diarsipkan tepat di bawahnya. Bertahun-tahun kemudian, sistem itu masih berjalan dengan baik.

Click to enlarge

Menerapkannya: Steve Trucking

Steve Trucking adalah skenario yang kita pakai terus-menerus: perusahaan keluarga pengiriman last-mile yang mengambil peralatan rumah tangga dan elektronik di pusat distribusi peritel besar, lalu mengantarkan dan memasangnya di rumah pelanggan. Empat jenis datanya, tiga jawaban:

Data	Tempat tinggalnya	Alasan
Pengiriman, kru, dan janji temu hari ini	Di core	Dispatcher dan kru bekerja di dalamnya sepanjang hari
Detail pesanan peritel	Dirujuk (atau salinan tipis di core)	Sistem peritel adalah sumber kebenarannya
Riwayat pengiriman dari tiga tahun lalu	Diarsipkan	Disimpan untuk klaim dan tren; hampir tidak ada yang membukanya
Foto pengiriman	Di luar core, ditautkan	Ribuan per hari; disimpan di luar Salesforce dengan tautan di pengirimannya

Inilah hal yang sama dalam bentuk model data. Pengiriman (Delivery) berada di core, tempat orang bekerja di dalamnya sepanjang hari. Tiga tahun kemudian, ia pindah ke Riwayat Pengiriman (Delivery History), sebuah big object: masih di core, tetapi di gudang. Pesanan milik mitra muncul sebagai objek eksternal, __x: Salesforce menghubungkan pengiriman dengannya, tetapi datanya tetap di sistem peritel. Dan foto-fotonya sepenuhnya tinggal di luar core, dengan tautan dari pengiriman. Satu model, tiga rumah.

Click to enlarge

Setiap org yang nyata punya ketiganya. Yang bermasalah adalah yang menaruh semuanya di core, karena membuat objek adalah tombol bawaannya.

Yang Diputuskan Arsitek di Sini

• Rumah untuk setiap jenis data, sebelum objek apa pun dirancang: di core, dirujuk, atau diarsipkan.
• Sumber kebenarannya. Jika sistem lain memiliki datanya, Salesforce tidak seharusnya diam-diam menjadi master kedua.
• Jalur akses untuk apa pun yang ada di luar core. Data yang dirujuk butuh sumber yang tersedia dan latensi yang bisa diterima; data yang diarsipkan butuh cara bagi orang untuk menemukannya.
• Pertumbuhan penyimpanan. Hitung sekarang (rekaman per hari, dikali pertumbuhan, dikali masa retensi), bukan ketika peringatan penyimpanan datang.

Di luar ujian: AI menaikkan taruhan atas “di core.” Fitur AI dan agen bekerja paling baik pada data yang dipahami platform: data di objek standar dan kustom, dinamai dan dideskripsikan dengan baik. Itu menarik kita untuk menaruh lebih banyak di core. Tahan godaan itu untuk data yang salah. Agen yang di-grounding pada salinan data ERP yang basi memberi jawaban yang yakin tetapi salah. Sering kali langkah yang lebih baik adalah merujuk sumber yang hidup, atau menyimpan potongan kecil yang dideskripsikan dengan baik di core. Di mana AI membaca data kini menjadi bagian dari keputusan di mana data tinggal.

Jelajahi

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (dicek 2026-09-25, bahasa Inggris)
• Files Connect FAQ (opens in a new tab), Bantuan Salesforce (dicek 2026-09-25, bahasa Inggris)
• Dalam kursus ini: Virtualisasi, Federasi, dan Zero Copy dan Merancang untuk Skala