Veriyi Tutarlı Tutmak

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 9.‘u. Her modül kendi başına okunabilir. Önceki: Sahiplik ve Yaşam Döngüsü · Sonraki: Salesforce Fiziksel Modelini Tasarlayın

Bu modülün yanıtladığı soru: Veriyi nasıl tutarlı tutarım ve her katmanın bedeli nedir?

Herkes temiz veri ister. Birinin “Asıl istediğimiz tutarsız veri” dediği bir gereksinim toplantısına hiç girmedim. Anlaşmazlık daha sonra çıkar: kuralları nerede uygulayacağız? Ekranda mı? Zorunlu bir alanla mı? Bir seçim listesi, bir doğrulama kuralı, bir yinelenen kayıt kuralı, bir flow, Apex? Hepsi yardımcı olur. Birbirinin yerine kullanılamazlar ve her katmanın bir bedeli vardır.

Genel kuralım kuralı makul ölçüde olabildiğince aşağıya itmektir. Bir değer yalnızca beş şeyden biri olabiliyorsa insanların her şeyi yazmasına izin verip sonra otomasyonla temizlemeyin. İki kayıt asla aynı tanımlayıcıyı paylaşmamalıysa birinin bunu bir raporda fark etmesine güvenmeyin. Bir kural, kayıt ister bir ekrandan, ister bir API’den, bir entegrasyondan, bir veri yüklemesinden ya da bir ajandan gelsin geçerli olmak zorundaysa onu yalnızca arayüzde uygulamayın. Kural veriye ne kadar yakınsa etrafından dolaşmak o kadar zordur. Buna tutarlılık merdiveni diyorum.

Birinci Basamak: Alan Türü ve Sözcük Dağarcığı

İlk tutarlılık kuralı 6. modüldekidir: doğru türü seçin. Tarih bir Tarih’tir, an bir Tarih/Saat’tir, para Para Birimi’dir. Bu, kimse bir kural yazmadan önceki tutarlılıktır.

Bir teslimatın durumunu metin alanı yaparsanız Delivered, delivered, DELIVERED, Complete, Done ve Dropped off alırsınız ve biri bu altısının aynı anlama gelip gelmediğini çözmek zorunda kalır. Ya da sözcük dağarcığını bir kez tanımlayın: Teslim edildi, tek değer, tek anlam. Listede olmayan her şeyi API üzerinden bile reddetmesi için onu kısıtlı bir seçim listesi yapın; birkaç alan listeyi paylaşıyorsa da bir genel değer kümesi (6. modülde ayrıntılar var).

Ama bir seçim listesini yalnızca insanların yazmasını engellemek için kullanmayın. Gerçekten bir değer mi, yoksa başka bir varlık mı? Her biri bir addan ibaret dokuz dağıtım merkezi bir seçim listesi gibi görünebilir; adresleri, müdürleri, kapasiteleri ve kamyonları olan dokuz dağıtım merkezi ise kayıtlardır. Kural modeli pekiştirmeli, kötü bir modeli telafi etmemelidir. Ve gerçekten kontrollü bir sözcük dağarcığıysa onu alanda kontrol edin. Kaosa izin verip sonra AZ, Arizona, Ariz ve Phoenix area değerlerini en başta istediğiniz tek değere dönüştüren bir flow inşa etmeyin.

İkinci Basamak: Zorunlu ve Benzersiz

Zorunlu ve Benzersiz cazip seçeneklerdir, çünkü basittirler: kutuyu işaretleyin, sorun çözüldü. Bazen. Her kamyonun oluşturulduğu günden itibaren bir filo numarası varsa ve iki kamyon aynı numarayı paylaşmıyorsa iki kutu da gerçek iş kurallarını ifade eder. Bu güçlü bir tutarlılıktır.

Ama platform bir kuralı uygulamaya başladığında, sürecinizin Salı öğleden sonra bir istisnası olması umurunda değildir. Bu örneği yıllardır derste kullanırım. Bir nesne bir süredir var, bolca kaydı var. Biri bir alan ekleyip Zorunlu’yu işaretliyor. Kayıt oluşturmayı test ediyor: harika çalışıyor. Sonra Cumartesi gecesi, dağıtım, testler çalışıyor ve eski bir test sınıfı nesneyi yeni alan olmadan oluşturuyor. Bum. Ya da biri alan var olmadan önceki eski bir kaydı düzenliyor. Ya da entegrasyon beş yıldır gönderdiği aynı yükü gönderiyor. Bum. “Ama o alanı değiştirmedik ki.” Platform umursamaz: geçerli bir kaydın ne olduğuna dair sözleşmeyi değiştirdiniz. Yeni bir kural yalnızca yeni veriyi etkilemez; eski veriyle neler yapabileceğinizi de değiştirir.

Üçüncü Basamak: Doğrulama Kuralları

Doğrulama kuralları çok daha zengin şeyler söylememizi sağlar. Durum Teslim edildi ise gerçek teslimat saati doldurulmuş olmalıdır. Durak bir kurulumsa durak kapatılmadan önce kontrol listesi tamamlanmış olmalıdır. Kayıt kaydedildiğinde çalışırlar; böylece kayıt bir sayfadan, API’den, bir veri yüklemesinden, bir entegrasyondan ya da bir ajandan kaydedilmiş olsun, onu korurlar. Mesele de budur. Kuralın kaydı koruması gerekiyorsa onu her yazma işleminin karşılaştığı yere koyun.

Dişleri de vardır. Bu hem güçleri hem de bedelleridir.

Eski Kayıt Sorunu

İşin çirkinleştiği yer burası. Bir milyon kaydınız var ve bugün bir kural ekliyorsunuz: teslimat saati rotanın çıkış saatinden önce olamaz. Mantıklı. Ama yedi yıl önceki bir taşıma yüzünden yirmi bin eski kayıt bu kuralı ihlal ediyor. Bir kullanıcı bunlardan birini açıp telefon numarasını değiştiriyor. Kaydet. Kural tetikleniyor. “Bir telefon numarası değiştirdim. Neden bana 2019’dan bir teslimat saatinden bahsediyorsunuz?” Haklı bir soru.

Dolayısıyla bir doğrulama kuralı yalnızca neyin doğru olması gerektiğini söylememelidir. Onu ne zaman uygulayacağını da söylemelidir. ISNEW() ve ISCHANGED() gibi işlevler, bir kuralın kapsamını yeni kayıtlarla ya da ilgili alanların gerçekten değiştiği kaydetmelerle sınırlamanızı sağlar (Validation Rule Considerations (opens in a new tab), İngilizce).

Ama bir kayıt yalnızca bir kişi onu düzenlediğinde değişmez ve nedenlerin çoğu sizin kontrolünüzde değildir. Entegrasyon durumu gece günceller. Bir akış bir tarih damgalar. Bir yönetici bir bölgeyi yeniden atar ve on bin kayıtta sahip değişir. Biri bir teslimat kalemini düzenler, teslimattaki toplama özeti yeniden hesaplanır ve bu teslimatı kaydeder; böylece teslimatın doğrulama kuralı ona hiç dokunmamış bir kullanıcı için tetiklenir (Roll-Up Summary Field (opens in a new tab) sayfası, doğrulama hatalarının ayrıntı ya da ana kayıtta görünebileceği konusunda uyarır; İngilizce). Bu kaydetmelerin her biri yeni kuralınızla karşılaşır. Dolayısıyla her yeni kural için sorun: bu kural o kaydetmeye uygulanmalı mı?

Seçenekler şunlar ve onları kuralın içine örersiniz:

• Her zaman, her kaydetmede. Kural gerçekten kayıtla ilgiliyse ve eski veri ondan geçiyorsa doğrudur. Ama “her kaydetme”nin ne anlama geldiğini bilin: yalnızca sahibi değiştiren bir toplu iş ya da kaydın herhangi bir yerindeki herhangi bir alanda yapılan küçük bir düzenleme de ondan geçmek zorundadır.
• Yalnızca yeni kayıtlar için, ISNEW() ile. Kural kaydı bir kez, oluşturulduğunda denetler ve bir daha asla denetlemez. Geçmiş olduğu gibi kalır, ama gelecek de öyle: sonraki bir düzenleme yeni bir kaydın kuralı ihlal etmesine yol açabilir ve kimse bunu durdurmaz. Bu önemliyse onu bir sonrakiyle eşleştirin.
• Yalnızca ilgili olduğu alanlar değiştiğinde, ISCHANGED() ile. Telefon numarasını düzenlemek teslimat saati kuralını uyandırmaz.
• Belirli yazıcılar için değil. Formülde $Permission olarak denetlenen bir özel izin, insanlar kurala uymaya devam ederken entegrasyon kullanıcısının ya da bir veri taşımanın geçmesine izin verir (How to Reference a Custom Permission in a Validation Rule (opens in a new tab), İngilizce). Onu bilerek ve az kişiye verin.
• Bir tarihten itibaren, “yeni”nin “bunu uygulamaya başladığımızdan beri” anlamına geldiği durumlarda CreatedDate’i kuralın canlıya geçtiği günle karşılaştırarak. ISNEW()’den farklı olarak bu kayıtları sonraki her kaydetmede denetlemeye devam eder; dolayısıyla aynı uyarı geçerlidir: toplu bir sahip güncellemesi gibi küçük bir değişiklik, zamanla kurala aykırı hale gelmiş bir kayıtta başarısız olabilir.

Zaten sahip olduğunuz kayıtlara bir kural mı ekliyorsunuz? Açmadan önce sonuçlarını iyice düşünün. Var olan her kayıt artık bir sonraki kaydetmesinde ondan geçmek zorundadır ve o kaydetme beklemediğiniz bir yerden gelebilir: gecelik bir entegrasyon, toplu bir sahip değişikliği, bir toplama özeti, bir liste görünümünden toplu güncelleme. Bunlardan hangisi ona çarpacak ve bir kayıt başarısız olduğunda o işe ne olacak? Açmadan Önce bölümünde kullandığım sıralama var.

Kuralı Memnun Etmek İçin Geçmişi Yeniden Yazmayın

Yirmi bin eski kayıt ne olacak? Veri yanlışsa ve doğru değerleri biliyorsanız düzeltin. Ama başka bir tür “düzeltme” de gördüm: kimse tarihsel gerçeği bilmiyor, yalnızca kayıtların kuraldan geçmesi gerekiyor; bu yüzden onları bugünün kuralını karşılayan değerlerle güncelliyorlar. Bundan hoşlanmıyorum. Eski kayıtları uyumlu hale getirmek için güncellemek LastModifiedDate’i değiştirir ve önemli tarihsel bilgileri yok eder; değer uydurmak da geçmiş hakkında bilmediğimiz bir şeyi biliyormuş gibi yapmak demektir. Geçmişi yeniden yazmak yerine kuraldan önce var olan kayıtlar için kurala bir muafiyet yolu verin. Çirkin olabilir, ama dürüsttür.

Arayüz Doğrulaması Veri Doğrulaması Değildir

Bir alanı sayfa düzeninde zorunlu yapın, kullanıcılar onsuz kaydedemez. Sonra gecelik entegrasyon 50.000 kayıt ekler. Sizin sayfanızı mı kullandı? Hayır. Toplu yükleme, API istemcisi ya da ajan da kullanmadı. Bir arayüz zorunluluğu veriyi değil, o ekranı korur. Dinamik formlardaki alan doğrulaması da aynı şekilde atlatılabilir. Öyleyse sorun: bu veri nereden girebilir? Lightning, portal, mobil, entegrasyon, API, toplu yükleme, Flow, Apex, bir ajan. Ne kadar çok kapı varsa yalnızca birini koruyan bir kurala o kadar az güvenirim.

Dördüncü Basamak: Yinelenen Kayıt Kuralları

Şimdi bir kaydın içindeki tutarlılıktan kayıtlar arası tutarlılığa geçiyoruz. Acme Corporation, ACME Corp, Acme Inc.: dört müşteri mi, tek müşteri mi? Hiçbir alan kuralı bunu yanıtlayamaz. Eşleştirme kuralları kayıtların nasıl karşılaştırılacağını tanımlar; yinelenen kayıt kuralları olası bir yineleme bulunduğunda ne olacağına karar verir: uyarıyla izin ver, engelle ya da raporla. Nesne başına en fazla beş etkin yinelenen kayıt kuralınız ve her birinde en fazla üç eşleştirme kuralınız olabilir; eşleştirme anahtarları da her karşılaştırmayı en olası 100 yinelenen kayda daraltır (Things to Know About Duplicate Rules (opens in a new tab), İngilizce).

Bedelleri sürtünmedir. Bir temsilcinin oluşturduğu her hesap Olası yinelenen kayıt bulundu diyorsa bazen tam olarak istediğiniz budur, bazen de insanlar okumadan tıklayıp geçmeyi öğrenir. Meşru kayıtlar birbirine benzeyebilir ve bir entegrasyonun bir kişiden farklı davranışa ihtiyacı olabilir. Üstelik uyarı Salesforce’un kendisine aittir: uyarısı ve olası yinelenen kayıtlar listesi sizin kurduğunuz özel bir ekrana uymayabilir ve kaydetme ekransız (headless) olduğunda, yani bir entegrasyon, bir veri yüklemesi, bir ajan söz konusu olduğunda, onu gösterecek hiç ekran yoktur. Bu yüzden bir yinelenen kaydın her yolda nasıl ortaya çıkacağına karar verin: bir kişi için uyarı, API için engellenen kaydetme ve hata ya da biri daha sonra incelesin diye Report seçeneği ve yinelenen kayıt kümeleri. İyi mimari en yüksek düzeyde uygulama değil, doğru uygulamadır.

Ve bir yinelenen kayıt kuralının gerçekte hangi kapıları koruduğunu kontrol edin (Things to Know About Duplicate Rules (opens in a new tab), İngilizce). API ve veri içe aktarma araçları üzerinden kimse uyarıyı görmez: uyarı vermeye ayarlanmış bir kural kaydetmeyi basitçe engeller. Bazı yollar kuralları tamamen atlar: Quick Create, Geri Al (Undelete) düğmesi, manuel birleştirme, Lightning Sync ya da Einstein Activity Capture’ın eklediği kayıtlar. Ve aynı anda kaydedilen kayıtlar birbiriyle karşılaştırılmaz, yalnızca Salesforce’ta zaten olan kayıtlarla karşılaştırılır. İçinde aynı müşteri iki kez bulunan bir dosya yükleyin, iki satır da geçebilir. Yinelenen kayıt kuralı iyi bir ağdır. Kapıdaki bir kilit değildir.

Sınav bilgisi. Yinelenen kayıt kuralları aynı anda kaydedilen kayıtları birbiriyle karşılaştırmaz, yalnızca Salesforce’ta zaten olan kayıtlarla karşılaştırır. API ve içe aktarma araçları üzerinden uyarı yoktur: kuralın yakaladığı yinelenen kayıt basitçe kaydedilmez. Ve bir kaydetme ile tetiklediği her şey tek bir işlem (transaction) olarak çalışır: herhangi bir parçası başarısız olursa tümü geri alınır.

Bir sınır. Yinelenen kayıt kuralları tek bir org’u temiz tutar. Kurumsal kimliği çözmezler. Salesforce’ta Acme Corporation, ERP’de ACME-10382 ve faturalamada 77193 numaralı müşteri varsa bir yinelenen kayıt kuralı bunların aynı şirket olduğunu size söyleyemez. Bu ana veridir, 6. bölüm.

Beşinci Basamak: Otomasyon

Bazı kurallar alt basamaklar için fazla karmaşıktır: ilgili kayıtlara, başka bir sisteme, bağımlı kayıtlara, çok adımlı bir sürece ihtiyaç duyarlar. Bu Flow’dur, Apex’tir, bazen entegrasyon mantığıdır. (Workflow Rules ya da Process Builder değil; desteklenmiyorlar.) Otomasyon güçlüdür ve daha pahalıdır: daha çok hareketli parça, daha çok test, daha çok hata yönetimi, bir otomasyonun diğerine takılması için daha çok yol. Ve kod kendi hatalarını getirir. Alan türü bunu uygulayabiliyorsa Apex yazmam. Bir doğrulama kuralı bunu açıkça söylüyorsa Flow orada diye bir flow inşa etmem. Bir alan sorununu bir süreç motoruyla çözmeyin.

Ya Hep Ya Hiç: Kayıtlar Birlikte Değiştiğinde

Şimdiye kadar her basamak tek bir kaydetmeyi korudu. Ama kayıtlar birlikte değişir: bir teslimat ve kalemleri, bir sipariş ve satırları, üç nesneyi güncelleyen bir akış. Burada platform size güçlü bir güvence verir. Bir kaydetme ve tetiklediği her şey, yani tetikleyiciler, akışlar ve onların çağırdığı sınıflar, tek bir işlem olarak çalışır: herhangi bir parçası başarısız olursa her şey geri alınır ve hiçbir şey kalıcı hale getirilmez (Apex Transactions (opens in a new tab), İngilizce). Yarım bir teslimat elde etmezsiniz.

Toplu iş, sizin seçtiğiniz istisnadır. Bir veri yüklemesi ya da bir Apex Database metodu kısmi başarıya izin verebilir: iyi kayıtlar kaydedilir, kötüler hatalarıyla geri döner ve biri onlarla ilgilenmek zorundadır (DML Statements vs. Database Class Methods (opens in a new tab), İngilizce). Bir milyon satırlık bir yükleme için bu çoğu zaman doğrudur, ama o zaman tutarlılık bir süreçtir: hata dosyasını kim okuyor ve başarısız olan kayıtlara ne oluyor?

Bir de zamanlama var. Aynı anda yapılan iki kaydetme, her birinin tek başına başarısız olacağı bir denetimden ikisi birden geçebilir. Var olan bir siparişi arayıp sonra bir tane oluşturan bir akış ikisinin birden geçmesine izin verebilir ve yinelenen kayıt kurallarının aynı anda kaydedilen kayıtları karşılaştırmadığını az önce gördük. Benzersiz olarak işaretlenmiş bir alan ya da bir Harici Kimlik ise her kaydetmede platform tarafından denetlenir; dolayısıyla yalnızca biri kazanır. Benzersizliği alana kadar aşağı itmek için bir neden daha. Kilitler, çekişme ve yeniden denemeler kendi başına bir konudur; 11. bölüm, İşlemler, Eşzamanlılık ve Güvenilirlik, derinlemesine giriyor.

Kuralı Aşağı İtin, Oraya Ait Olmayana Kadar

“Makul ölçüde olabildiğince aşağı” her zaman “en aşağı” demek değildir. Bir alan yalnızca bir fırsat belirli bir aşamaya ulaştığında zorunluysa onu şemada zorunlu yapmak yanlıştır; kural koşulludur, dolayısıyla doğru basamak bir doğrulama kuralıdır. Bir yinelenen kayıt bir kişiyi uyarmalı ama onaylı bir entegrasyonun kendi mutabakatı varsa her iki yol için de tasarlayın. Hedef: iş kuralını doğru biçimde temsil eden en alt katman.

Her Katmanın Bir Bedeli Vardır

Click to enlarge

Görmenizi istediğim ödünleşim bu. Alan türleri ve kontrollü değerler basit ve güçlüdür, ama yalnızca bir alanın ifade edebildikleri için. Zorunlu ve Benzersiz kabadır: açıldıklarında her yazma işlemi onları karşılamalıdır. Doğrulama kuralları daha zengin koşulları ifade eder ama eski kayıtlarda düzenlemeleri engelleyebilir ve bir dağıtımı şaşırtabilir. Yinelenen kayıt kuralları kayıtlar arasında koruma sağlar ama kullanıcılar ve entegrasyonlar için sürtünme ekler. Otomasyon her şeyi halleder ama orkestrasyonu, hataları, testleri ve performansı üstlenmenizi gerektirir. Bedava katman yoktur. Her kuralın katmanını nasıl başarısız olduğunu bilerek seçin.

Açmadan Önce

Var olan bir org’a bir kural eklemek bir onay kutusu değil, bir yaygınlaştırmadır. Bugün kaç kayıt onu ihlal ediyor ve neden? Gerçekten yanlışlar mı? Doğru değeri bilebilir miyiz? Kural geçmiş için de doğru mu, yoksa yalnızca bundan sonrası için mi? Hangi entegrasyonlar, testler ve otomasyonlar ona çarpacak? İyi bir sıralama: ölçün, yanlış olduğunu kanıtlayabildiklerinizi temizleyin, kuralın kapsamını belirleyin, meşru geçmiş için bilinçli bir muafiyet yolu ekleyin, her yazma yolunu test edin, sonra uygulayın. Ölçmek ve temizlemek kendi başına disiplinlerdir, profilleme, standartlaştırma, izleme, veri sorumluluğu, ve 5. bölüm, Veri Kalitesi ve Yönetişim, bunları ele alıyor. Cuma günü bir kutuyu işaretleyip sonuçlarını cumartesi gecesi keşfetmekten çok daha iyi.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Bir ajan herhangi bir kişiden daha hızlı kayıt oluşturabilir, kötü kayıtları da aynı hızla. Kullanıcı bir ajan olduğunda “kullanıcılar bunu yapmamaları gerektiğini bilir” bir koruma değildir. Önemli kuralları her yazanın karşılaştığı veri katmanına koyun; böylece ajanın şirketin yazılı olmayan kurallarını hatırlaması gerekmez.

Steve Trucking: Teslimatı Koruyun

Bir teslimatı alın. Durumu tek bir sözcük dağarcığından gelir: kısıtlı bir seçim listesi. Perakende Ortağının sipariş referansı ortak başına benzersiz olmalıdır; bu yüzden benzersiz olarak işaretlenmiş, yük listesini upsert etmek için kullanılan bir Harici Kimliktir. Gerçek teslimat saati, durum Teslim edildi olduğunda zorunludur: kapsamı o değişiklikle sınırlanmış bir doğrulama kuralı. Bir kurulum durağı, kontrol listesi tamamlanıp gerekli fotoğrafları (bir bulaşık makinesi için su hattı, tahliye hattı ve terazi) çekilmeden kapatılamaz: bir doğrulama kuralı ya da platform dışında saklanan fotoğrafları kontrol etmesi gerekiyorsa otomasyon. Yeniden gönderilen bir yük listesinden iki kez gelen aynı sipariş Harici Kimlik tarafından yakalanır; birbirine benzeyen iki farklı sipariş ise bir eşleştirme sorusudur.

“Hepsini bir flow’a koyun” demediğime dikkat edin. Her kural kendi basamağında durur. Her kural için sorun: önemli olan her yazma yolu için bunu doğru biçimde uygulayan en alt katman hangisi?

Mimarın Burada Karar Verdikleri

• Her kuralın hangi basamağa ait olduğu: alan türü, kontrollü sözcük dağarcığı, zorunlu ya da benzersiz, doğrulama kuralı, yinelenen kayıt kuralı ya da otomasyon.
• Hangi yazma yollarının korunması gerektiği: arayüz, portal, mobil, entegrasyonlar, toplu yüklemeler, API’ler, otomasyon ve ajanlar.
• Yeni bir kuralın tarihsel kayıtlara mı uygulanacağı, yoksa geçmiş için bir muafiyet yoluyla yeni ve değişen veriyle mi sınırlanacağı.
• Var olan kötü verinin, kuraldan geçmek için yeniden yazılmak yerine kanıta dayanarak düzeltilip düzeltilemeyeceği.
• Bir kuralın ne kadar sürtünmeye, karmaşıklığa ve bakıma değdiği.

Temiz veri insanlardan iyi veri girmelerini istemekten gelmez. Doğru olanı kolay, yanlış olanı zor ve önemli kuralları atlatılması zor kılan bir mimariden gelir. Sırada bölümü Steve Trucking’den bir kesit üzerinde bir araya getiriyoruz.

Daha Fazlası

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) ve Roll-Up Summary Field (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13.
• Salesforce Help, Picklist Limitations (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13: sınırlar, kuralların çalışmadığı yollar, API ve içe aktarma kaydetmelerinin uyarısız engellenmesi, eşzamanlı kaydetmelerin karşılaştırılmaması.
• Apex Developer Guide, Apex Transactions (opens in a new tab) ve DML Statements vs. Database Class Methods (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13: tek bir işlem bir bütün olarak geri alınır; Database metotları kısmi başarıya izin verebilir.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.