Menjaga Data Tetap Konsisten

🌐 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 9 dari 10 dalam bab Arsitektur Data Salesforce, bab 3 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Kepemilikan dan Siklus Hidup · Berikutnya: Rancang Model Fisik Salesforce

Pertanyaan yang dijawab modul ini: Bagaimana saya menjaga data tetap konsisten, dan berapa biaya setiap lapisannya?

Semua orang menginginkan data yang bersih. Saya belum pernah masuk ke rapat persyaratan di mana seseorang berkata, “Yang sebenarnya kami inginkan adalah data yang tidak konsisten.” Perbedaan pendapatnya datang belakangan: di mana kita menegakkan aturannya? Di layar? Bidang wajib? Daftar pilihan, aturan validasi, aturan duplikat, flow, Apex? Semuanya membantu. Semuanya tidak bisa saling menggantikan, dan setiap lapisan ada biayanya.

Aturan umum saya adalah dorong aturannya serendah yang masuk akal. Jika sebuah nilai hanya bisa salah satu dari lima hal, jangan biarkan orang mengetik apa saja lalu membersihkannya nanti dengan otomatisasi. Jika dua rekaman tidak boleh berbagi pengenal yang sama, jangan mengandalkan seseorang menemukannya di laporan. Jika sebuah aturan harus berlaku entah rekaman datang dari layar, API, integrasi, muatan data, atau agen, jangan menegakkannya hanya di UI. Makin dekat aturan dengan datanya, makin sulit dilewati. Saya menyebutnya tangga konsistensi.

Anak Tangga Pertama: Tipe Bidang dan Kosakatanya

Aturan konsistensi pertama adalah yang dari modul 6: pilih tipe yang tepat. Tanggal adalah Date, momen adalah Date/Time, uang adalah Currency. Itulah konsistensi sebelum ada yang menulis aturan.

Jadikan status pengiriman sebagai bidang teks dan Anda akan mendapat Delivered, delivered, DELIVERED, Complete, Done, dan Dropped off, dan seseorang harus mencari tahu apakah keenamnya berarti hal yang sama. Atau definisikan kosakatanya sekali: Delivered, satu nilai, satu makna. Jadikan itu daftar pilihan terbatas (restricted picklist) agar menolak apa pun yang tidak ada di daftar, bahkan melalui API, dan set nilai global ketika beberapa bidang berbagi daftar itu (modul 6 membahas detailnya).

Tetapi jangan memakai daftar pilihan hanya untuk mencegah orang mengetik. Apakah itu benar-benar sebuah nilai, atau entitas lain? Sembilan pusat distribusi yang masing-masing hanya punya nama mungkin terlihat seperti daftar pilihan; sembilan dengan alamat, manajer, kapasitas, dan truk adalah rekaman. Aturan seharusnya memperkuat model, bukan menambal model yang buruk. Dan jika itu memang kosakata terkendali, kendalikan di bidangnya. Jangan biarkan kekacauan terjadi lalu membangun flow untuk mengubah AZ, Arizona, Ariz, dan Phoenix area menjadi nilai yang Anda inginkan sejak awal.

Anak Tangga Kedua: Wajib dan Unik

Required dan Unique menarik karena sederhana: centang kotaknya, masalah selesai. Kadang-kadang. Jika setiap truk punya nomor armada sejak hari ia dibuat, dan tidak ada dua truk yang berbagi nomor, kedua kotak itu mengungkapkan aturan bisnis yang nyata. Itulah konsistensi yang kuat.

Tetapi begitu platform menegakkan sebuah aturan, ia tidak peduli bahwa proses Anda punya pengecualian pada Selasa sore. Saya sudah bertahun-tahun memakai contoh ini di kelas. Sebuah objek sudah cukup lama ada, dengan banyak rekaman. Seseorang menambahkan sebuah bidang dan mencentang Required. Mereka menguji pembuatan rekaman: berjalan dengan indah. Lalu Sabtu malam, deployment, pengujian berjalan, dan sebuah kelas uji lama membuat objek itu tanpa bidang baru tersebut. Bum. Atau seseorang mengedit rekaman lama dari sebelum bidang itu ada. Atau integrasi mengirim payload yang sama yang sudah dikirimnya selama lima tahun. Bum. “Tapi kami tidak mengubah bidang itu.” Platform tidak peduli: Anda telah mengubah kontrak tentang apa itu rekaman yang valid. Aturan baru tidak hanya memengaruhi data baru; ia mengubah apa yang bisa Anda lakukan dengan data lama.

Anak Tangga Ketiga: Aturan Validasi

Aturan validasi memungkinkan kita menyatakan hal-hal yang jauh lebih kaya. Jika statusnya Delivered, waktu pengiriman aktual harus diisi. Jika titik pemberhentiannya adalah pemasangan, daftar periksa harus lengkap sebelum titik pemberhentian itu bisa ditutup. Aturan validasi berjalan saat rekaman disimpan, jadi ia melindungi rekaman entah disimpan dari halaman, API, muatan data, integrasi, atau agen. Itulah intinya. Jika aturan harus melindungi rekaman, taruh di tempat yang ditemui setiap penulisan.

Aturan validasi juga punya taring. Itu kekuatannya sekaligus biayanya.

Masalah Rekaman Lama

Di sinilah mulai jelek. Anda punya satu juta rekaman, dan hari ini Anda menambahkan sebuah aturan: waktu pengiriman tidak boleh sebelum keberangkatan rute. Masuk akal. Tetapi dua puluh ribu rekaman lama melanggarnya, gara-gara migrasi tujuh tahun lalu. Seorang pengguna membuka salah satunya dan mengubah nomor telepon. Simpan. Aturannya terpicu. “Saya mengubah nomor telepon. Kenapa Anda memberi tahu saya soal waktu pengiriman dari 2019?” Pertanyaan yang adil.

Jadi aturan validasi tidak seharusnya hanya menyatakan apa yang harus benar. Ia harus menyatakan kapan menegakkannya. Fungsi seperti ISNEW() dan ISCHANGED() memungkinkan Anda membatasi aturan pada rekaman baru, atau pada penyimpanan di mana bidang yang relevan benar-benar berubah (Validation Rule Considerations (opens in a new tab)).

Tetapi sebuah rekaman tidak hanya berubah ketika seseorang mengeditnya, dan banyak penyebabnya berada di luar kendali Anda. Integrasi memperbarui status setiap malam. Sebuah flow mengisi tanggal. Seorang manajer menugaskan ulang sebuah wilayah dan pemiliknya berubah pada sepuluh ribu rekaman. Seseorang mengedit item pengiriman, roll-up pada pengiriman dihitung ulang, dan itu menyimpan pengirimannya, sehingga aturan validasi pengiriman terpicu bagi pengguna yang sama sekali tidak menyentuhnya (Roll-Up Summary Field (opens in a new tab) memperingatkan bahwa error validasi bisa muncul di detail atau di master). Setiap penyimpanan itu bertemu aturan baru Anda. Jadi untuk setiap aturan baru, tanyakan: apakah aturan ini seharusnya berlaku untuk penyimpanan itu?

Inilah pilihan-pilihannya, dan Anda menenunnya ke dalam aturan:

• Selalu, di setiap penyimpanan. Tepat ketika aturannya benar-benar tentang rekaman itu dan data lama lolos. Tetapi pahami arti “setiap penyimpanan”: batch job yang hanya mengubah pemilik, atau suntingan kecil apa pun pada bidang mana pun di rekaman itu, juga harus meloloskannya.
• Hanya untuk rekaman baru, dengan ISNEW(). Aturannya memeriksa rekaman sekali, saat dibuat, dan tidak pernah lagi. Masa lalu tetap seperti adanya, tetapi begitu pula masa depan: suntingan berikutnya bisa membuat rekaman baru melanggar aturan dan tidak ada yang menghentikannya. Jika itu penting, pasangkan dengan pilihan berikutnya.
• Hanya ketika bidang yang bersangkutan berubah, dengan ISCHANGED(). Mengedit nomor telepon tidak membangunkan aturan waktu pengiriman.
• Tidak untuk penulis tertentu. Sebuah izin kustom (custom permission), yang diperiksa di formula sebagai $Permission, membiarkan pengguna integrasi atau migrasi data lewat sementara orang tetap menemui aturannya (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Berikan dengan sengaja dan kepada sedikit pihak.
• Sejak tanggal tertentu, dengan membandingkan CreatedDate dengan hari aturan itu mulai berlaku, ketika “baru” berarti “sejak kita mulai menegakkan ini.” Berbeda dengan ISNEW(), cara ini terus memeriksa rekaman-rekaman itu di setiap penyimpanan berikutnya, jadi peringatan yang sama berlaku: perubahan kecil, seperti pembaruan pemilik secara batch, bisa gagal pada rekaman yang sudah bergeser.

Menambahkan aturan ke rekaman yang sudah Anda miliki? Pikirkan konsekuensinya sebelum Anda mengaktifkannya. Setiap rekaman yang ada sekarang harus meloloskannya pada penyimpanan berikutnya, dan penyimpanan itu bisa datang dari tempat yang tidak Anda duga: integrasi malam, perubahan pemilik secara batch, roll-up, pembaruan massal dari list view. Mana dari semua itu yang akan terkena, dan apa yang terjadi pada job itu ketika satu rekaman gagal? Bagian Sebelum Anda Mengaktifkannya berisi urutan yang saya pakai.

Jangan Menulis Ulang Sejarah demi Menyenangkan Aturannya

Bagaimana dengan dua puluh ribu rekaman lama itu? Jika datanya salah dan Anda tahu nilai yang benar, perbaiki. Tetapi saya pernah melihat jenis “perbaikan” lain: tidak ada yang tahu kebenaran historisnya, mereka hanya butuh rekamannya lolos, jadi mereka memperbaruinya dengan nilai yang memenuhi aturan hari ini. Saya tidak menyukainya. Memperbarui rekaman lama agar patuh akan mengubah LastModifiedDate dan menghancurkan informasi historis yang penting, dan mengarang nilai berarti berpura-pura kita tahu sesuatu tentang masa lalu yang sebenarnya tidak kita ketahui. Beri aturannya jalan pintas (bypass) untuk rekaman yang lebih tua darinya alih-alih menulis ulang sejarah. Bisa jelek, tetapi jujur.

Validasi UI Bukanlah Validasi Data

Jadikan sebuah bidang wajib di tata letak halaman dan pengguna tidak bisa menyimpan tanpanya. Lalu integrasi malam menyisipkan 50.000 rekaman. Apakah integrasi itu memakai halaman Anda? Tidak. Begitu pula muatan massal, klien API, atau agen. Persyaratan di UI melindungi layar itu, bukan datanya. Validasi bidang di dynamic forms bisa dihindari dengan cara yang sama. Jadi tanyakan: dari mana saja data ini bisa masuk? Lightning, portal, seluler, integrasi, API, muatan massal, Flow, Apex, agen. Makin banyak pintunya, makin kurang saya percaya pada aturan yang hanya menjaga salah satunya.

Anak Tangga Keempat: Aturan Duplikat

Sekarang kita beralih dari konsistensi di dalam sebuah rekaman ke konsistensi lintas rekaman. Acme Corporation, ACME Corp, Acme Inc.: empat pelanggan atau satu? Tidak ada aturan bidang yang bisa menjawabnya. Aturan pencocokan mendefinisikan bagaimana rekaman dibandingkan; aturan duplikat memutuskan apa yang terjadi ketika kemungkinan duplikat ditemukan: izinkan dengan peringatan, blokir, atau laporkan. Anda bisa punya hingga lima aturan duplikat aktif per objek dan hingga tiga aturan pencocokan di masing-masing, dan match key mempersempit setiap perbandingan ke 100 kemungkinan duplikat teratas (Things to Know About Duplicate Rules (opens in a new tab)).

Biayanya adalah gesekan. Jika setiap akun yang dibuat seorang sales memunculkan Possible duplicate found, kadang itu persis yang Anda inginkan, dan kadang orang belajar mengklik terus tanpa membaca. Rekaman yang sah bisa terlihat mirip, dan sebuah integrasi mungkin butuh perilaku yang berbeda dari manusia. Dan peringatan itu milik Salesforce sendiri: peringatannya dan daftar kemungkinan duplikatnya mungkin tidak menyatu dengan layar kustom yang Anda bangun, dan ketika penyimpanannya headless (tanpa layar), entah integrasi, muatan data, atau agen, sama sekali tidak ada layar untuk menampilkannya. Jadi putuskan bagaimana sebuah duplikat muncul di setiap jalur: peringatan untuk manusia, penyimpanan yang diblokir beserta error untuk API, atau opsi Report dan duplicate record set untuk ditinjau seseorang nanti. Arsitektur yang baik bukanlah penegakan maksimal; arsitektur yang baik adalah penegakan yang tepat.

Dan periksa pintu mana yang benar-benar dijaga oleh aturan duplikat (Things to Know About Duplicate Rules (opens in a new tab)). Melalui API dan alat impor data, tidak ada yang melihat peringatannya: aturan yang diatur untuk memberi peringatan langsung memblokir penyimpanannya. Sebagian jalur melewati aturan sepenuhnya: Quick Create, tombol Undelete, penggabungan manual, rekaman yang ditambahkan oleh Lightning Sync atau Einstein Activity Capture. Dan rekaman yang disimpan pada saat yang sama tidak dibandingkan satu sama lain, hanya dengan rekaman yang sudah ada di Salesforce. Muat sebuah file yang berisi pelanggan yang sama dua kali, dan kedua barisnya bisa lolos. Aturan duplikat adalah jaring yang baik. Ia bukan kunci pintu.

Pengetahuan untuk ujian. Aturan duplikat tidak membandingkan rekaman yang disimpan pada saat yang sama satu sama lain, hanya dengan rekaman yang sudah ada di Salesforce. Melalui API dan alat impor tidak ada peringatan: duplikat yang tertangkap aturan itu langsung tidak disimpan. Dan sebuah penyimpanan beserta semua yang dipicunya berjalan sebagai satu transaksi: jika ada bagian yang gagal, semuanya dibatalkan (rollback).

Satu batas. Aturan duplikat menjaga satu org tetap bersih. Aturan duplikat tidak menyelesaikan identitas perusahaan. Jika Salesforce punya Acme Corporation, ERP punya ACME-10382, dan sistem penagihan punya pelanggan 77193, aturan duplikat tidak bisa memberi tahu Anda bahwa semuanya perusahaan yang sama. Itu data master, bab 6.

Anak Tangga Kelima: Otomatisasi

Sebagian aturan terlalu rumit untuk anak tangga yang lebih rendah: aturan itu butuh rekaman terkait, sistem lain, rekaman yang bergantung, proses bertahap. Itulah Flow, Apex, kadang logika integrasi. (Bukan Workflow Rules atau Process Builder; keduanya sudah tidak didukung.) Otomatisasi itu ampuh dan lebih mahal: lebih banyak bagian yang bergerak, lebih banyak pengujian, lebih banyak penanganan error, lebih banyak cara bagi satu otomatisasi untuk tersandung otomatisasi lain. Dan kode membawa error-nya sendiri. Jika tipe bidang bisa menegakkannya, saya tidak menulis Apex. Jika aturan validasi menyatakannya dengan jelas, saya tidak membangun flow hanya karena Flow tersedia. Jangan menyelesaikan masalah bidang dengan mesin proses.

Semua atau Tidak Sama Sekali: Ketika Rekaman Berubah Bersama

Sejauh ini setiap anak tangga melindungi satu penyimpanan. Tetapi rekaman berubah bersama: sebuah pengiriman dan item-itemnya, sebuah pesanan dan baris-barisnya, sebuah flow yang memperbarui tiga objek. Di sini platform memberi Anda jaminan yang kuat. Sebuah penyimpanan dan semua yang dipicunya, trigger, flow, kelas yang mereka panggil, berjalan sebagai satu transaksi: jika ada bagian yang gagal, semuanya dibatalkan (rollback) dan tidak ada yang di-commit (Apex Transactions (opens in a new tab)). Anda tidak akan mendapat setengah pengiriman.

Pekerjaan massal adalah pengecualian yang Anda pilih sendiri. Muatan data atau metode Apex Database bisa mengizinkan keberhasilan sebagian (partial success): rekaman yang baik tersimpan, yang buruk kembali dengan error-nya, dan seseorang harus menanganinya (DML Statements vs. Database Class Methods (opens in a new tab)). Itu sering kali tepat untuk muatan sejuta baris, tetapi lalu konsistensi menjadi sebuah proses: siapa yang membaca file error-nya, dan apa yang terjadi pada rekaman yang gagal?

Lalu ada soal waktu. Dua penyimpanan pada saat yang sama bisa sama-sama lolos pemeriksaan yang masing-masing akan gagal jika sendirian. Sebuah flow yang mencari pesanan yang sudah ada lalu membuatnya bisa meloloskan dua, dan kita baru saja melihat bahwa aturan duplikat tidak membandingkan rekaman yang disimpan pada saat yang sama. Bidang yang ditandai Unique, atau External ID, diperiksa platform di setiap penyimpanan, jadi hanya satu yang menang. Itu satu alasan lagi untuk mendorong keunikan ke tingkat bidang. Penguncian, perebutan (contention), dan percobaan ulang adalah topik tersendiri; bab 11, Transaksi, Konkurensi, dan Keandalan, membahasnya secara mendalam.

Dorong Aturannya ke Bawah, Sampai Ia Tidak Lagi Cocok di Sana

“Serendah yang masuk akal” tidak berarti “selalu yang paling rendah.” Jika sebuah bidang hanya wajib setelah sebuah peluang mencapai tahap tertentu, menjadikannya wajib di skema adalah salah; aturannya bersyarat, jadi aturan validasi adalah anak tangga yang tepat. Jika sebuah duplikat sebaiknya memberi peringatan kepada manusia tetapi integrasi yang disetujui punya rekonsiliasinya sendiri, rancanglah untuk kedua jalur. Tujuannya: lapisan terendah yang merepresentasikan aturan bisnis dengan benar.

Setiap Lapisan Ada Biayanya

Click to enlarge

Inilah trade-off yang ingin saya Anda lihat. Tipe bidang dan nilai terkendali itu sederhana dan kuat, tetapi hanya untuk apa yang bisa diungkapkan sebuah bidang. Required dan Unique itu tumpul: begitu aktif, setiap penulisan harus memenuhinya. Aturan validasi mengungkapkan kondisi yang lebih kaya tetapi bisa memblokir suntingan pada rekaman lama dan mengejutkan sebuah deployment. Aturan duplikat melindungi lintas rekaman tetapi menambah gesekan bagi pengguna dan integrasi. Otomatisasi bisa menangani apa saja tetapi membuat Anda harus memiliki orkestrasi, error, pengujian, dan kinerja. Tidak ada lapisan yang gratis. Pilih lapisan untuk setiap aturan sambil mengetahui bagaimana ia gagal.

Sebelum Anda Mengaktifkannya

Menambahkan aturan ke org yang sudah ada adalah sebuah peluncuran, bukan sekadar kotak centang. Berapa banyak rekaman yang melanggarnya hari ini, dan mengapa? Apakah semuanya benar-benar salah? Bisakah kita tahu nilai yang benar? Apakah aturan itu benar secara historis, atau hanya mulai sekarang? Integrasi, pengujian, dan otomatisasi mana yang akan terkena? Urutan yang baik: ukur, bersihkan apa yang bisa Anda buktikan salah, batasi cakupan aturannya, tambahkan jalan pintas yang disengaja untuk riwayat yang sah, uji setiap jalur penulisan, lalu tegakkan. Mengukur dan membersihkan adalah disiplin tersendiri, profiling, standardisasi, pemantauan, stewardship, dan bab 5, Kualitas dan Tata Kelola Data, membahasnya. Jauh lebih baik daripada mencentang kotak pada hari Jumat lalu menemukan konsekuensinya pada Sabtu malam.

Di luar ujian: apa yang diubah AI. Sebuah agen bisa membuat rekaman lebih cepat daripada siapa pun, dan rekaman yang buruk sama cepatnya. “Pengguna tahu untuk tidak melakukan itu” bukanlah perlindungan ketika penggunanya adalah agen. Taruh aturan-aturan penting di lapisan data, tempat setiap penulis menemuinya, agar agen tidak perlu mengingat aturan-aturan tak tertulis perusahaan.

Steve Trucking: Lindungi Pengirimannya

Ambil sebuah pengiriman. Statusnya berasal dari satu kosakata: daftar pilihan, terbatas. Referensi pesanan Mitra Ritel harus unik per mitra, jadi ia menjadi External ID, ditandai unik, dipakai untuk upsert manifes. Waktu pengiriman aktual wajib begitu statusnya Delivered: aturan validasi, dibatasi pada perubahan itu. Titik pemberhentian pemasangan tidak bisa ditutup sampai daftar periksanya lengkap dan foto wajibnya sudah diambil (untuk mesin cuci piring, saluran air masuk, saluran pembuangan, dan kerataannya): aturan validasi, atau otomatisasi jika harus memeriksa foto yang disimpan di luar platform. Pesanan yang sama yang tiba dua kali dari manifes yang dikirim ulang tertangkap oleh External ID; dua pesanan berbeda yang terlihat mirip adalah soal pencocokan.

Perhatikan bahwa saya tidak bilang “masukkan semuanya ke dalam sebuah flow.” Setiap aturan berada di anak tangganya sendiri. Untuk setiap aturan, tanyakan: lapisan terendah apa yang menegakkan ini dengan benar untuk setiap jalur penulisan yang penting?

Yang Diputuskan Arsitek di Sini

• Di anak tangga mana setiap aturan berada: tipe bidang, kosakata terkendali, wajib atau unik, aturan validasi, aturan duplikat, atau otomatisasi.
• Jalur penulisan mana yang harus dilindungi: UI, portal, seluler, integrasi, muatan massal, API, otomatisasi, dan agen.
• Apakah aturan baru berlaku untuk rekaman historis, atau dibatasi pada data baru dan yang berubah dengan jalan pintas untuk masa lalu.
• Apakah data buruk yang sudah ada bisa dikoreksi berdasarkan bukti, alih-alih ditulis ulang agar lolos.
• Seberapa banyak gesekan, kerumitan, dan pemeliharaan yang sepadan untuk sebuah aturan.

Data yang bersih tidak datang dari meminta orang memasukkan data yang baik. Data yang bersih datang dari arsitektur yang membuat hal yang benar menjadi mudah, hal yang salah menjadi sulit, dan aturan-aturan penting sulit dilewati. Berikutnya, kita menyatukan bab ini pada sepotong Steve Trucking.

Jelajahi

• Bantuan Salesforce, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) dan Roll-Up Summary Field (opens in a new tab), dicek 2026-10-13 (bahasa Inggris).
• Bantuan Salesforce, Picklist Limitations (opens in a new tab), dicek 2026-10-02 (bahasa Inggris).
• Bantuan Salesforce, Validation Rule Considerations (opens in a new tab), dicek 2026-10-02 (bahasa Inggris).
• Bantuan Salesforce, Things to Know About Duplicate Rules (opens in a new tab), dicek 2026-10-13 (bahasa Inggris): batasannya, jalur-jalur tempat aturan tidak berjalan, penyimpanan melalui API dan impor yang diblokir tanpa peringatan, penyimpanan serentak yang tidak dibandingkan.
• Apex Developer Guide, Apex Transactions (opens in a new tab) dan DML Statements vs. Database Class Methods (opens in a new tab), dicek 2026-10-13 (bahasa Inggris): satu transaksi dibatalkan sebagai satu kesatuan; metode Database bisa mengizinkan keberhasilan sebagian.
• Bantuan Salesforce, Workflow Rules & Process Builder End of Support (opens in a new tab), dicek 2026-10-02 (bahasa Inggris).