Sahiplik ve Yaşam Döngüsü

🌐 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 8.‘i. Her modül kendi başına okunabilir. Önceki: İlişkilerin Sonuçları Vardır · Sonraki: Veriyi Tutarlı Tutmak

Bu modülün yanıtladığı soru: Kaydın sahibi kim ve ömrü boyunca ona ne olur?

Bir veri modeline baktığımda yalnızca nesnelerin ne olduğunu ve nasıl bağlandığını bilmek istemem. Kayıtlara zaman içinde ne olduğunu bilmek isterim. Onları kim oluşturuyor? Sahibi kim? Onları kim yeniden atayabilir? İş ilişkisi değiştiğinde, artık etkin olmadıklarında ne olur? Hiç silinmeliler mi ve onları ne kadar süre saklıyoruz? Bunların hiçbiri bir ERD’de, yani varlık-ilişki diyagramında (2. bölümün veri modelindeki kutular ve çizgiler) görünmez. Hepsi veri mimarisidir. Ve Salesforce’ta sahiplik, veri modeli ile güvenlik modelinin birbirine çarptığı yerdir.

Sahiplik Bir Alandaki Addan Fazlasıdır

Yöneticiler bir kayıtta Sahip’i görür ve onu bir etiket olarak okur: bu hesabın sahibi Bart, şu vakanın sahibi Lisa. Bu anlama gelebilir. Ama Salesforce’ta sahiplik aynı zamanda bir platform mekanizmasıdır. Sahibi olan nesnelerde sahip, rol hiyerarşisi, paylaşım kuralları, kuyruklar ve yeniden atama aracılığıyla kaydı kimin görebileceğini belirler. Dolayısıyla “Bu kaydın sahibi kim?” diye sorduğumda sayfada kimin adının yazacağını sormuyorum. Ona hangi güvenlik ve yaşam döngüsü davranışını bağladığımızı soruyorum. Sahip bir kullanıcı ya da bazı nesneler için (aralarında özel nesneler, vakalar ve potansiyel müşteriler var) bir kuyruk olabilir; her iki durumda da sahip kayda tam erişim alır (Understanding Sharing (opens in a new tab), İngilizce).

Bu yüzden iş sorumluluğunu kayıt sahipliğinden ayırırım. Bazen aynı kişidirler. Bazen değildirler. İş, bir teslimattan bir sevk görevlisinin sorumlu olduğunu söylüyorsa bu, sevk görevlisini otomatik olarak sahip yapmaz. Sorumluluk kendi alanında yaşayabilirken sahiplik güvenliği ve ölçeği destekleyecek şekilde belirlenebilir. İkisi de “sahip” sözcüğünü kullanıyor diye birbirine karışmalarına izin vermeyin.

Paylaşım Tablosu: Sahipliğin Erişime Dönüştüğü Yer

Bazı insanlar paylaşım tablosunun ne olduğunu bile bilmiyor. Her veri mimarı bilmeli.

Bir kaydın paylaşımının büyük kısmı, ilgili bir paylaşım nesnesinde (share object) tutulur; bu, Salesforce’un erişim kontrol listesi versiyonudur (Understanding Sharing (opens in a new tab), İngilizce). Hesap’ın AccountShare’i, Kişi’nin ContactShare’i vardır ve bir özel nesne de kendininkini alır: Truck__c’nin Truck__Share’i vardır (Sharing a Record Using Apex (opens in a new tab), İngilizce). İçindeki her satır dört şey söyler:

• Hangi kayıt: üst kimlik (parent ID).
• Kim: bir kullanıcı ya da bir grup (genel grup, bir rolün grubu, bir bölge).
• Ne kadar: Okuma, Düzenleme ya da Tümü (tam erişim).
• Neden: satır nedeni (row cause). Sahip için Owner, paylaşım kuralı için Rule, manuel paylaşım için Manual, Team, Salesforce’un bir hesap ile alt kayıtları arasında eklediği örtük nedenler ve bir geliştiricinin Apex paylaşımı için tanımladığı nedenler.

Derste Workbench’i açar ve bir kaydı paylaşırken paylaşım tablosunu sorgularım; siz de satırların belirip kaybolmasını izlersiniz. Biri “bu kişi onu neden görebiliyor?” diye sorduğunda yanıt çoğu zaman bir satırda, nedeniyle birlikte durur.

Ama her şey orada değildir. Kuruluş genelindeki varsayılan bir satır değildir. Rol hiyerarşisi de orada saklanmaz: sahibin üstündeki insanların erişimi gerektiğinde hesaplanır. Ve View All, Modify All, View All Data ve Modify All Data paylaşım tablosunu tamamen atlar (Sharing a Record Using Apex (opens in a new tab), İngilizce). Derste söylediğim gibi: View All’u işaretlerseniz paylaşım tablosunu atlamış olursunuz.

Salesforce, ilişkili oldukları için bazı kayıtları sizin yerinize de paylaşır. Buna örtük paylaşım (implicit sharing) denir ve bir hesap ile alt kayıtları arasında çalışır. Bir kişiyi, vakayı ya da fırsatı görebiliyorsanız ait olduğu hesabı da okuyabilirsiniz. Ve hesap sahibi, hesabın kişilerine, vakalarına ve fırsatlarına, sahibin rolüne göre belirlenen bir düzeyde erişim alır (Implicit Sharing (opens in a new tab), İngilizce). Son sürümlerde Salesforce bu alt kayıt erişiminin bir kısmını satır olarak saklamak yerine gerektiğinde hesaplıyor; bu yüzden paylaşım tablosunu sorguladığınızda onu göremezseniz şaşırmayın. Burada yalnızca bir ipucu veriyorum; ayrıntılar İlişkiler ve Yerleşik Paylaşım bölümünde.

Çok sayıda harici kullanıcınız olduğunda bir istisna daha var. Yüksek hacimli topluluk kullanıcıları (high-volume community users), yani binlerce ile milyonlarca müşteri için yapılmış Customer Community lisansları, rolsüzdür, genel gruplarda olamaz ve onlara paylaşım kuralları ya da manuel paylaşımlar aracılığıyla kayıt verilemez (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab), İngilizce). Onlar için yanıt paylaşım tablosu değildir: kayıtlara, bir kaydın hesabını ya da kişisini kullanıcının kendi hesabı ya da kişisiyle eşleştiren paylaşım kümeleri (sharing sets) aracılığıyla ulaşırlar. Bu lisansların ölçeklenmesinin nedenlerinden biri budur. Sharing and Visibility kursu bunu Harici Kullanıcılarla Paylaşım bölümünde ele alıyor.

Ve 7. modülü hatırlayın: bir ayrıntı nesnesinin hiç paylaşım nesnesi yoktur. Erişimi ana kaydın paylaşım nesnesinden ve ana-ayrıntı alanındaki Sharing Setting’ten (Paylaşım Ayarı) gelir.

Bir veri mimarı bunu neden önemser? Çünkü sahiplik bu tabloya yazılır. Her sahip değişikliği, her yeni paylaşım kuralı, rol ya da grup değiştiren her kullanıcı, Salesforce’un satır ekleyip silmesi demektir. Birkaç bin kayıtta kimse fark etmez. On milyon kayıtta, çoğunun sahibi tek bir kullanıcıyken, birazdan karşılaşacağımız yeniden hesaplama budur.

Sınav bilgisi. Bir özel nesnenin paylaşım nesnesi Object__Share olarak adlandırılır, örneğin Truck__Share. Bir ayrıntı nesnesinin paylaşım nesnesi yoktur: erişimi ana kayıttan gelir. Ve bir kaydın sahibi değiştiğinde manuel paylaşımları kaldırılır, geliştiricinin kendi nedeniyle yapılan Apex paylaşımı ise kalır.

Veri modelinin işi güvenlik modeline devrettiği yer burasıdır ve geri kalanını Sharing and Visibility Architect kursunda öğretiyorum: Steve’in Bir Kaydı Paylaşmanın 22 Yolu, Org Genelinde Varsayılanlar, Sahiplik, Kuyruklar ve Rol Hiyerarşisi, örtük paylaşımlar için İlişkiler ve Yerleşik Paylaşım ve Apex paylaşım nedenleri için Programatik Paylaşım ve Güvenli Kod. Bu kursta 12. bölüm hepsini insanlar, uygulamalar ve ajanlar için bir araya getiriyor.

Bazen Sahiplik Devralınır

Önceki modülde bir ana-ayrıntı alt kaydının kendi sahibi olmadığını, üst kaydını izlediğini gördük. Bu çoğu zaman tam olarak doğrudur. İş, bir teslimattaki her kalem için farklı bir sahibe ihtiyaç duyuyor mu? Hayır. Yaşam döngüsünün sahibi teslimattır ve kalem ona aittir. İlişki tasarımı ve sahiplik tasarımının birlikte yapılmasının nedeni budur: ana-ayrıntıyı seçtiğinizde sahiplik kararının bir kısmını zaten vermiştiniz.

Sistemlerin Oluşturduğu Kayıtların Sahibi Kim?

Şimdi iş ilginçleşiyor. Bir kişi bir hesap oluşturur ve belki sahibi olur. Ama bir ERP gece boyunca 100.000 işlem gönderir. Bunların sahibi kim? Entegrasyon kullanıcısı mı? Bir kuyruk mu? Veriden çıkarılan bölgesel bir sahip mi? Beş yıldır kimsenin aklına gelmeyen bir sistem hesabı mı? Ve artık ajanlar da kayıt oluşturuyor.

Pozisyonum: sahipliğin paylaşım için önemli olup olmadığına bağlıdır. Entegrasyon kullanıcısı ya da ajan kullanıcısı geçerli bir kullanıcıdır ve kayıtların sahibi olabilir. O nesnede sahiplik erişimi belirliyorsa (rol hiyerarşisi ya da paylaşım kuralları aracılığıyla), kayıtları doğru sahibe atayın: gerçek bir kullanıcıya, bir kuyruğa ya da özel bir sahip kullanıcıya. Belirlemiyorsa sistem kullanıcısını sahip olarak tutmak daha iyi bir seçim olabilir, çünkü o zaman denetim izi doğrudan kaydı oluşturan şeye götürür.

Her iki durumda da bilerek karar verin. Her şeyin sahibi olan bir entegrasyon hesabı sessizce güvenlik mimarinizin bir parçası haline gelmiştir ve birinin, o hesap bir gün devre dışı bırakılırsa ne olacağını bilmesi gerekir.

Sahiplik Bir Ölçek Sorununa Dönüşebilir

Dağılım da önemlidir. Binlerce sahibe yayılmış on milyon kayıt bir şekildir. Tek bir kullanıcıya ait on milyon kayıt bambaşka bir şekildir. Salesforce, tek bir kullanıcı bir nesnenin 10.000’den fazla kaydına sahip olduğunda buna sahiplik veri çarpıklığı (ownership data skew) der (Ownership Data Skew (opens in a new tab), İngilizce). Genellikle biri her şeyi tek bir kullanıcıya ya da kuyruğa park ettiğinde olur: atanmamış tüm potansiyel müşteriler bir yer tutucu kullanıcıda, her entegrasyon kaydı entegrasyon kullanıcısında. O kullanıcı rol hiyerarşisinde yer değiştirene ya da bir paylaşım kuralının dayandığı bir gruba girip çıkana kadar zararsızdır. Sonra Salesforce’un çok büyük sayıda paylaşım girdisini düzeltmesi gerekir ve uzun süren yeniden hesaplamalarla karşılaşırsınız.

Öneri pratiktir. Mümkün olduğunda sahipliği daha fazla kullanıcıya yayın. Bir kullanıcının çok sayıda kayda sahip olması gerekiyorsa onu rol hiyerarşisinin dışında tutun; bir role ihtiyacı varsa onu en üstte kendi rolüne koyun ve yerini değiştirmeyin; paylaşım kurallarının kullandığı genel grupların da dışında tutun (Ownership Data Skew (opens in a new tab), İngilizce). Aynı düşünce, önceki modüldeki çok fazla alt kaydı olan üst kayıt için, yani üst-alt çarpıklığı için de geçerlidir.

Dolayısıyla dağılım fiziksel modelin bir parçasıdır. Yalnızca kaç kayıt olduğunu sormayın; nasıl dağıldıklarını sorun. Bu, Sıfır Sayısı’nın bir başka versiyonudur: yalnızca kaç sıfır değil, sıfırların nerede yoğunlaştığı. 2. Kısım çarpıklığa derinlemesine giriyor; burada onun geldiğini görmenizi istiyorum. Sharing and Visibility kursu konuyu Ölçekte Paylaşım bölümünde yeniden ele alıyor.

“Varsayılan Sahip” Mimariye Dönüşür

Sürekli gördüğüm bir kalıp. Kimse bir şeyin sahibinin kim olması gerektiğini bilmiyor, biri de “Hepsini entegrasyon kullanıcısına atayın” ya da “System adında genel bir kullanıcı oluşturun” diyor. Belki doğrusu budur. Ama bunu kazara yapmayın. Geçici bir varsayılanın kalıcı hale gelme alışkanlığı vardır: iki yıl sonra her kayıt integration@company.com’a aittir, kimse nedenini hatırlamaz ve onu değiştirmek bir projedir. Bu, 1. bölümün Tersinirlik Testi’dir: bir milyon kaydı tek bir sahibe vermeden önce, bunu sonradan değiştirmenin neye mal olacağını sorun.

Yeniden Atama Bir Yaşam Döngüsü Olayıdır

Sahipler değişir. Satış temsilcileri ayrılır, bölgeler kayar, ekipler yeniden yapılanır, bölgeler yeniden dengelenir. Sahibe ne bağlı: paylaşım, otomasyon, raporlar, kuyruklar, eskalasyonlar, entegrasyonlar? Sahibi değiştirmek kaydı kimin görebileceğini değiştiriyorsa yeniden atama bir yönetici temizliği değildir. Bir güvenlik olayıdır ve bir milyon kayıtta aynı zamanda operasyonel bir olaydır. Bu olurken paylaşım tablosunu izleyin: sahip değiştiğinde manuel paylaşımlar kaldırılır, geliştiricinin kendi nedeniyle yapılan Apex paylaşımı ise değişikliğe dayanır (Understanding Sharing (opens in a new tab), İngilizce). Derste bir kaydı biriyle paylaşırım, sahibi değiştiririm ve o kişi erişimini kaybeder. Salon her seferinde şaşırır.

Ve sahipliğin erişimle aynı şey olmadığını unutmayın. Bir kaydı görmesi gereken tek kişi sahibi değildir ve Salesforce’un erişim vermenin pek çok yolu vardır: rol hiyerarşisi, paylaşım kuralları, ekipler, bölgeler, manuel ve programatik paylaşım. Sharing and Visibility kursu bunlara Steve’in Bir Kaydı Paylaşmanın 22 Yolu ile başlayarak derinlemesine giriyor. Mimarın noktası daha basit: her erişim sorununu sahiplikle çözmeye çalışmayın. Yalnızca biri bir kaydı görebilsin diye sahipleri değiştiriyorsanız muhtemelen yanlış sorunu çözüyorsunuz.

Oluşturma Yalnızca Başlangıçtır

Pek çok veri modellemesi oluşturmada durur: alanlar, nesne, ilişki, tamam. Ama kayıt on yıl yaşayabilir. Güncellenir, sahip değiştirir, durum ve ilişki değiştirir, etkinliğini yitirir, geçmiş olur, arşivlenmesi gerekebilir ve bir gün belki silinir. Mimari yalnızca kaydın nasıl doğduğu değildir. Doğumdan ölüme kadar ne olduğudur.

Click to enlarge

Sırf Eski Diye Silmeyin

Bir Perakende Ortağı iş göndermeyi bırakıyor. Hesabı silelim mi? Otomatik olarak değil: teslimatları, talepleri ve faturalama geçmişi hâlâ önemli. Bir kamyon emekliye ayrılıyor. Teslimat geçmişi ve hasar talepleriyle birlikte onu silelim mi? Şeyin kendisi artık etkin olmayabilir, ama verisi hâlâ etkindir. Bu yüzden etkin olmayan ile yok olanı ayırırım. Emekliye ayrılmış bir kamyon modelde kalabilir; eski bir çalışan denetim geçmişinde hâlâ görünebilir. Mimari, operasyonel ilişki bittikten sonra önemli olan olguları korumalıdır.

Saklama Bir İş Gereksinimidir

Öbür taraf: her şeyi sonsuza kadar saklamak da mimari değildir. Depolama büyür, raporlar yavaşlar, arama gürültülenir ve gizlilik yasası bazı verilerin silinmesi gerektiğini söyleyebilir. Bu yüzden bunu ne kadar süre saklıyoruz? sorusuna açık bir yanıt isterim. “Salesforce saklıyor” bir saklama politikası değildir.

Ve bu çoğunlukla işlem verisiyle ilgili bir sorudur. Referans verisi, yani ürünler, hizmet türleri, dağıtım merkezleri, devasa boyutlara ulaşmaz ve diğer kayıtlar ona işaret eder; bu yüzden genellikle kalır. Müşteri verisi ikisinin arasındadır: bir müşterinin ömrünü sonlandırdığınız bir gün gelebilir, özellikle kişisel veri tutuyorsanız ve onu saklama nedeni sona erdiğinde. Ama hacim işlemlerdedir: teslimatlar, siparişler, vakalar, randevular; her gün, sonsuza dek oluşturulurlar. Yüz milyonlarca satıra büyüyen budur ve saklamanın açık olması gereken yer de burasıdır: belki org’da iki yıllık operasyonel veri, bir yerde yedi yıllık finansal kayıtlar, bazı fotoğraflar için doksan gün. Bunlar iş kurallarıdır ve kimse sormadıysa mimar sormalıdır.

Bunu yıllardır derste söylerim: bugün arşivlemiyorsanız, hiç arşivleyecek misiniz? “Sonra ilgileniriz” ifadesinin üç yüz milyon kayıtta acil bir projeye dönüşme huyu vardır. 2. Kısım’da aynı soru üzerine kurulu, arşivleme ve temizleme üzerine koca bir modül var.

Steve Trucking: Bir Teslimatın Sahibi Kim?

Bir teslimat, Perakende Ortağının yük listesinden bir entegrasyon tarafından günde yaklaşık 3.300 kez oluşturulur. Sahibi kim? Perakende Ortağı değil; o bir iş ilişkisi. Alıcı değil. Ekip onu gerçekleştiriyor, ama ekipler kamyon değiştirdiğinde kayıt her seferinde sahip mi değiştirmeli? Sevk görevlisi mi? Dağıtım merkezi mi? Bir kuyruk mu? Onu oluşturan entegrasyon kullanıcısı mı?

Şimdi bu modülü uygulayın, karar veren soruyla başlayarak: sahiplik birinin teslimatlara erişimini belirliyor mu? Steve Trucking’de belirlemiyor. Sevk görevlileri kendi dağıtım merkezlerinin teslimatlarını görür, ekipler kendi rotalarındakileri görür ve her perakendeci kendi teslimatlarını ortak portalında görür. Bunların hiçbiri kaydın sahibinin kim olduğuna bağlı değildir; dağıtım merkezinden, rotadan ve ortaktan gelir.

Dolayısıyla yanıtım: teslimatların sahibi entegrasyon kullanıcısıdır. Bu, bir sistem kullanıcısının kayıtlara bilerek sahip olmasının iyi bir örneğidir:

• Denetim izi dürüsttür. Her teslimatın sahibi nereden geldiğini söyler: yük listesi entegrasyonu.
• Erişim sahiplikten değil, paylaşımdan gelir. Dağıtım merkezine dayalı ölçüt tabanlı paylaşım kuralları her DC’nin ekibine kendi teslimatlarını verir; ortaklar kendilerininkine portal üzerinden ulaşır.
• Çarpıklık tasarımla ortadan kaldırılır. Günde 3.300 teslimatla entegrasyon kullanıcısı üç günde 10.000 teslimatı geçer; yani ilk günden sahiplik çarpıklığı vardır ve bunu planlarsak sorun değildir. Entegrasyon kullanıcısının rolü yoktur; dolayısıyla bir hiyerarşide onun üstünde yeniden hesaplanması gereken hiçbir şey yoktur ve paylaşım kurallarımızın kullandığı genel grupların dışında kalır.
• Kimse teslimatları yeniden atamaz. Ekipler kamyon değiştirir, sevk görevlileri vardiya değiştirir ve sahip hiç değişmez; dolayısıyla bir yeniden atama fırtınası ve kaybedilecek manuel paylaşım yoktur.

Ve o kullanıcı bir gün devre dışı bırakılırsa ya da değiştirilirse ne olacağını yazıya dökün, çünkü artık milyonlarca kaydın sahibidir. Bir sonraki ekibin bulması gerekecek karar budur.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanlar makine hızında kayıt oluşturur ve değiştirir. Bir ajan kendi kullanıcısı altında 100.000 kayıt oluşturursa “sahibi sonra düzeltiriz” bir çarpıklığa, bir paylaşım yeniden hesaplamasına ve bir temizlik projesine dönüşür. Ajanın sahiplik kuralına canlıya geçmeden önce aynı soruyla karar verin: burada sahiplik paylaşım için önemli mi?

Mimarın Burada Karar Verdikleri

• Sahipliğin iş sorumluluğunu mu, bir güvenlik mekanizmasını mı yoksa her ikisini mi temsil ettiği ve Sahip alanında değilse sorumluluğun nerede yaşadığı.
• Kayıtların kendi sahiplerine mi ihtiyaç duyduğu yoksa sahibi bir üst kayıttan mı devralmaları gerektiği.
• Entegrasyonların ve ajanların oluşturduğu kayıtların sahibinin kim olacağı; sahipliğin paylaşımı belirleyip belirlemediğine bağlı olarak.
• Sahipliğin nasıl dağıldığı ve bir kullanıcının çok sayıda kayda sahip olması gerektiğinde sahiplik çarpıklığından nasıl kaçınılacağı.
• Kayıtların ne zaman etkinliğini yitirdiği, ne zaman arşivlendiği, ne kadar süre saklandığı ve silmenin ne zaman doğru olduğu.

Fiziksel bir modele baktığınızda yalnızca verinin nerede saklandığını sormayın. Bugün sahibinin kim olduğunu, yarın kimin olabileceğini ve artık ona ihtiyacımız olmadığında ne olacağını sorun. Sırada: doğru nesne, alanlar, ilişkiler ve sahip olsa bile verinin hâlâ güvenilir kalması gerekir.

Daha Fazlası

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13: sahipler (bir kullanıcı ya da özel nesneler, vakalar ve potansiyel müşteriler için bir kuyruk) tam erişim alır; paylaşımın çoğu ilgili bir paylaşım nesnesinde yaşar; rol hiyerarşisi çalışma zamanında türetilir; sahip değiştiğinde manuel paylaşımlar kaldırılır, Apex yönetimli paylaşım korunur; satır nedeni (row cause) değerleri.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13: AccountShare, MyCustomObject__Share; ayrıntı nesnelerinin paylaşım nesnesi yoktur; paylaşım nesnesinin izlemedikleri (kuruluş genelindeki varsayılanlar, rol hiyerarşisi, View All ve Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13: bir hesap ile kişileri, vakaları ve fırsatları arasındaki erişim.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) ve Sharing Rule Considerations (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-13: rol yok, paylaşım kuralı ya da manuel paylaşım yok; bunların yerine paylaşım kümeleri.
• Sharing and Visibility Architect kursu: Steve’in Bir Kaydı Paylaşmanın 22 Yolu, Org Genelinde Varsayılanlar, Sahiplik, Kuyruklar ve Rol Hiyerarşisi, İlişkiler ve Yerleşik Paylaşım, Programatik Paylaşım ve Güvenli Kod, Harici Kullanıcılarla Paylaşım, Ölçekte Paylaşım.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) ve Parent-Child Data Skew (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.