Doğru Nesneyi Seçin

🌐 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 5.‘i. Her modül kendi başına okunabilir. Önceki: Bu Veri Nerede Yaşıyor? · Sonraki: Alanlar da Mimaridir

Bu modülün yanıtladığı soru: Bu iş kavramı ne tür bir Salesforce nesnesine dönüşmeli ve lisanslar neye izin veriyor?

Salesforce’ta yapılması en kolay şeylerden biri özel bir nesne oluşturmaktır. Bence çok fazla özel nesne oluşturmamızın nedeni de tam olarak bu.

Bir gereksinim oturumundasınız ve biri “Distribütörlerimizi takip etmemiz gerekiyor” diyor. Yeni özel nesne: Distribütör. Tamam. Ama ben mimarın önce başka bir soru sormasını isterim: distribütör nedir? Bir şirkettir. Salesforce’un bir şirketi temsil etmenin zaten oldukça iyi bir yolu var. Adı Hesap. Bu, yanıtın her zaman Hesap olduğu anlamına gelmez. Ama bir şirketin neden Hesap olmadığını açıklamam gerekiyorsa “iş birimi onlara distribütör diyor”dan daha iyi bir neden isterim.

2. bölümün mantıksal modelinin platformla buluştuğu yer burası ve başlangıç pozisyonum basit: iş kavramı bir standart nesnenin amaçlanan kullanımına tam olarak uyuyorsa oradan başlayın.

Anlamla Başlayın

Bir şey nesne olmayı hak etse bile otomatik olarak özel bir nesne olmayı hak etmez. O şeyin gerçekte neyi temsil ettiğini sorun. Herhangi bir biçimde bir işletme ya da kuruluş mu? Hesap ile başlayın. O kuruluşla çalışan bir kişi mi? Kişi. Bir müşterinin sahip olduğu ya da satın aldığı bir şey mi? Varlık. Satmaya çalıştığınız bir şey mi? Artık Fırsat konuşmaya dahil olur.

Ana gemiye önce bu yüzden baktık, 2. modülde. O modeller her işe uymaz, ama kendimizinkini inşa etmek daha temiz hissettirdiği için onları görmezden gelmemeliyiz. Yeni Özel Nesne’ye tıklamadan önce sorun: Salesforce bu kavramı nasıl modelliyor, o modelin etrafında neler inşa edilmiş ve onu değiştirirseniz nelerden vazgeçmiş olursunuz?

Tam Uyum Testi

Testim tek bir soru: bu iş kavramı standart nesnenin amaçlanan kullanımına tam olarak uyuyor mu? Uyuyorsa eğilimim standart nesneden yanadır.

Bir distribütör ilişkimiz olan bir şirkettir; dolayısıyla Hesap tam bir uyumdur. Kullanıcıların bir şirkete distribütör, bir başkasına tedarikçi, bir diğerine perakende ortağı, bir diğerine de müşteri demesi beni rahatsız etmez. Bunlar iş rolleridir ve dört fiziksel nesneye ihtiyaç duymazlar. Farklı iş adları otomatik olarak farklı veri yapıları anlamına gelmez. Farkı bir tür, bir kayıt türü ya da bir ilişki taşıyabilir.

Test öbür yönde de çalışır. 1. bölümde size bir soru bırakmıştım: bir müşterinin işletmesinin birçok teslimat noktası var. Her nokta bir Hesap mı olmalı, yoksa özel bir nesne mi?

Hesap size çok şey verir. Adres alanlarını ve zaten bir Hesap adresi bekleyen her şeyi alırsınız: raporlar, haritalar, entegrasyonlar. Ama yükünü de alırsınız: bir sürü alan, paylaşım, hiyerarşi, sahiplik, bir Hesaba bağlı her şey; ve bunların çoğu ayrı bir adresle ilgili değildir. Sırf alternatif bir adres için hiç kullanmayacağınız bir sürü ağır şeyi taşımış olursunuz.

Hesabın alt kaydı olan bir özel nesne ise hafif olabilir: yalnızca adres alanları, teslimat yaptığımız bir yer, bağımsız olarak kontrol edebileceğim kendi yaşam döngüsüyle.

Yani bu bir denge: üstlendiğiniz ağırlığa karşı elde ettiğiniz değer. Tek ihtiyacım kendi yaşam döngüsü olan bir adresse, işte orada özel nesneye giderim.

Bir vakadaki alt sorunlar için de aynısı. Her alt sorun gerçekten bir vakaysa, bir temsilci onun üzerinde çalışıyorsa, kendi durumu ve hizmet düzeyi varsa, onları 2. modüldeki Üst Vaka (Parent Case) ile iç içe koyun. Ama kimsenin vaka olarak üzerinde çalışmadığı bir kontrol listesi maddesiyse, tam bir vaka hiç kullanmayacağı bir sürü şey taşır ve basit bir özel alt nesne daha hafif olabilir. Özel nesne daha temiz olduğu için değil. Anlam farklı olduğu ya da ağırlık yanlış olduğu için.

Standart Nesneler Yükleriyle Gelir

Bir standart nesne seçtiğinizde alanlarından fazlasını seçersiniz. Salesforce ürünlerinin zaten anladığı bir şeyi seçersiniz: raporlama, otomasyon, yerleşik ilişkiler, ürün özellikleri, AppExchange paketleri ve Salesforce’un bundan sonra inşa edeceği her şey. Bu son derece değerli olabilir.

Standart nesneler kendi görüşleriyle de gelir: mevcut davranış, ilişkiler, güvenlik konuları, bazen lisans gereksinimleri ve ihtiyacınız olmayan özellikler. Dolayısıyla “her zaman standart nesne kullanın” benim kuralım değil. “Her zaman” diye bir kuralım yok. Bir eğilimim var: anlam tam olarak uyduğunda ve etrafındaki platform davranışı tasarıma karşı savaşmak yerine ona yardım ettiğinde standart nesneyi kullanın. Beş yılımı Fırsat’ı satış fırsatı olmayan bir şey gibi davranmaya zorlayarak geçirirsem standart kalarak hiçbir şey kazanmamışımdır. Yalnızca öbür yönde yanlış bir uzlaşma yapmışımdır.

Varlık İyi Bir Örnektir

Varlık, insanların gözden kaçırdığı standart nesnelerden biridir. Söyleyebileceğim en basit hali: müşterinin sahip olduğu bir şeydir. Belki bizden satın almıştır, belki değil. Müşterimin sahasında duran bir rakip ürünü yine de önemserim, çünkü ona servis veriyorumdur, onu değiştirmeye çalışıyorumdur ya da kurulu tabanlarını anlamam gerekiyordur. Önce Varlık’a bakmadan Customer_Product__c oluşturursam bir mimari soruyu atlamış olurum. Varlık otomatik olarak kazanmaz, ama değerlendirilmeyi hak eder.

Kişi Hesapları: Kişi Ne Zaman Hesaptır?

2. modülde kişi hesaplarıyla tanıştık: bireysel müşteriler için tek kayıtta bir hesap ve bir kişi. Şimdi karar zamanı.

Benim pozisyonum: B2C için onlarsız yapmak zor. Hesaplar ve Kişilerle kutudan o kadar çok şey çıkar ki maliyetine ve yüküne değer. Ve bir maliyeti var: bir işletme hesabının yaklaşık iki katı depolama, bir kez açınca kapatamayacağınız bir anahtar ve bazı harici lisansların onları kullanamaması. Partner Community kişi hesaplarıyla kullanılamaz (Experience Cloud User Licenses (opens in a new tab), İngilizce). Yani soru “veritabanımızda insanlar var mı?” değil. Her org’da insanlar vardır. Soru şu: “bu işte kişi gerçekten hesabın kendisi mi?” Bir Kişinin insan olması onu kişi hesabı yapmaz. Bunu iş ilişkisi belirler.

Click to enlarge

Şimdi Her Şeyi Karmaşıklaştırayım: Lisanslar

Şimdiye kadar: kavramı bulun, en temiz standart uyumu arayın, anlam uymadığında özel nesneye gidin. Şimdi mimarın ardından gelen sorusu: onu kimin kullanması gerekiyor? Güzel bir model tasarlayıp sonra veriye ihtiyaç duyan insanların yarısının seçtiğiniz nesneler için lisanslı olmadığını keşfedebilirsiniz. Lisanslar veri modelinin bir parçasıdır.

Üç Dahili Lisans

Kendi çalışanlarınızla başlayın. Şirketin içinde, her mimarın ezbere bilmesini istediğim üç lisans türü var, çünkü her kullanıcının neyi görüp ne yapabileceğini, dolayısıyla veri modelinizin neye güvenebileceğini onlar belirler.

Sales Cloud (artık Agentforce Sales). Bu kullanıcılar tam Salesforce kullanıcı lisansına sahiptir: standart CRM nesneleri ve her türlü standart ya da özel uygulama. Yani hesapların ve kişilerin üzerine potansiyel müşteriler, fırsatlar ve tahminler, hatta vakalar: bir satış temsilcisi bir görüşmeden önce müşterinin açık vakalarını görebilir. Kampanya oluşturmak ve yürütmek bir parça daha gerektirir: Marketing User özellik lisansı.

Service Cloud (artık Agentforce Service). Aynı Salesforce kullanıcı lisansı, servis için yapılandırılmış hali. Vakalar merkezdedir ve Service Console’da üzerinde çalışılır: Salesforce Console for Service’i açan, Service Cloud User özellik lisansıdır. Hizmet düzeyi sözleşmeleri burada yaşar, yetkilendirme yönetimi (entitlement management) ve kilometre taşları aracılığıyla; Knowledge da burada devreye girer, çoğu sürümde ek ürün olarak satın alınır.

Platform (Salesforce Platform). CRM’e değil, sizin özel uygulamalarınıza ihtiyaç duyan insanlar için. Hesapları, kişileri, raporları, gösterge panolarını, dokümanları ve org’daki her özel uygulamayı alırlar. Almadıkları: tahminler, potansiyel müşteriler, kampanyalar ve fırsatlar. Daha ucuzdur; bu kadar çok büyük özel uygulamanın onun üzerinde çalışmasının nedeni de tam olarak budur, veri modelinizi hazırlıksız yakalayabilmesinin nedeni de.

	Sales Cloud	Service Cloud	Platform
Kullanıcı lisansı	Salesforce	Salesforce	Salesforce Platform
Amacı	Satış	Müşterilere destek	Özel uygulamalar
Hesaplar, kişiler	Evet	Evet	Evet
Potansiyel müşteriler, fırsatlar, tahminler	Evet	Evet	Hayır
Vakalar	Evet, bir müşterinin vakalarını görmek için	Merkezde, Service Console’da	Hayır
Hizmet düzeyi sözleşmeleri	Hayır	Evet, yetkilendirmeler ve kilometre taşları	Hayır
Özel nesneler ve uygulamalar	Evet	Evet	Evet

Tabloyu bir mimar gibi okuyun. Büyük bir kullanıcı grubu Platform’daysa, onların işini bir Fırsat üzerine koyan her tasarım daha başlamadan bozuktur. Yöneticilerin SLA rakamlarına ihtiyacı varsa, onları görüp göremeyeceklerine bulundukları lisans karar verir. Bu üç tür davranışı belirler.

Click to enlarge

Lisans Nesneye Karar Verdiğinde

En sık karşılaştığım kurban Fırsat. Tabloda gördünüz: Platform kullanıcıları onu alamaz (Standard User Licenses (opens in a new tab), İngilizce), Customer Community kullanıcıları da onunla çalışamaz. Gereksinim bir Fırsat gibi görünür, biri “Fırsat’ı kullanalım” der ve sonra ben kimin erişime ihtiyacı olduğunu sorarım. Büyük bir kitle Platform ya da Customer Community lisanslarındaysa, lisans artık bir satın alma ayrıntısı değildir. Bir mimari kısıttır ve genellikle tasarımı bir özel nesneye doğru iter.

Yukarı doğru da çalışır. Derste sorarım: CEO güzel gösterge panoları istiyor; Sales lisansı mı, Service mi? Bir Sales kullanıcısı satış nesnelerini ve hatta vakaları görebilir; dolayısıyla satış gösterge panoları ve açık vaka sayıları için Sales yeterlidir. Ama yönetici SLA KPI’larını (bir vakanın hizmet düzeyini ihlal etmesine ne kadar kaldığını) istediği anda bu veri yetkilendirmelerde ve kilometre taşlarında (entitlements and milestones) bulunur ve yetkilendirme yönetimi eski adıyla Service Cloud olan Agentforce Service’i gerektirir (Supported Editions for Service Features (opens in a new tab), İngilizce). Artık yöneticilerin lisanslarını yükseltiyorsunuz. İş gereksinimini dinleyin ve ihtiyaç duyduğu verinin altında hangi lisansın durduğunu bilin.

Stadyum

Lisansları bir stadyumdaki koltuklar olarak düşünürüm. Herkes aynı maçı izliyor. Ortadaki pahalı koltukları alırsam iki takımı da yakından görebilirim. Köşede, tribünün tepesindeysem koltuklar minderli değildir ve maçı dürbünle izlerim.

Bunlar harici lisanslar; şirket dışındaki insanlar için: bir Experience Cloud sitesine oturum açan müşteriler ve ortaklar. Bilmenizi istediğim üç tane var.

Customer Community: açık tribünler. Vakalara ve bilgi bankasına ihtiyaç duyan çok sayıda harici kullanıcı için yapılmıştır: destek vakasının durumuna bakan bir müşteri. Koltuklar yaklaşık yarı fiyatınadır ve muazzam sayıda kullanıcıya verilebilir. Orada neyi kaybedersiniz? Raporları, gösterge panolarını ve paylaşım tablosunu: üst katmanların aldığı rol tabanlı paylaşımı. Kişi hesaplarıyla çalışır.

Customer Community Plus: aşağı doğru yaklaşık yarı yolda. Salesforce onu raporlara, gösterge panolarına ve standart paylaşıma ihtiyaç duyan harici kullanıcılar için lisans olarak tanımlar: başkalarının erişimini yöneten ya da kendi rakamlarını görmesi gereken bir müşteri.

Partner Community: sahaya daha da yakın, işletmeden işletmeye (B2B) iş için, satış verisine erişimle. Ortaklar potansiyel müşteriler ve fırsatlar üzerinde çalışır: fırsat kaydı yaparlar ve sizinle birlikte kampanyalar yürütürler. Satış nesnelerine ulaşan harici koltuk budur. Bir püf noktası: kişi hesaplarıyla kullanılamaz (Experience Cloud User Licenses (opens in a new tab), İngilizce).

Click to enlarge

Hata, herkesin pahalı bileti varmış gibi tasarım yapıp uygulama aşamasında kullanıcılarınızın çoğunun verilerini koyduğunuz bölüme giremediğini keşfetmektir. O zaman üç seçeneğiniz olur: farklı koltuklar almak, deneyimi taşımak ya da modeli yeniden tasarlamak. Üçü de mimaridir.

Nasıl Ödedikleri Tasarımı Değiştirir

İnsanların unuttuğu bir soru daha var: bu kullanıcılar nasıl oturum açacak? Harici lisanslar iki biçimde gelir. Üye tabanlı: kullanıcı başına ödersiniz; bu, her gün oturum açan 500 ortağa uyar. Oturum tabanlı: ayda belirli sayıda oturum satın alırsınız; bu, yılda birkaç kez oturum açan beş milyon müşteriye uyar. Aynı gün içinde birden fazla oturum açmak yine tek oturum sayılır (Experience Cloud User Licenses (opens in a new tab), İngilizce).

Bu yüzden biri “bir müşteri portalı inşa ediyoruz” dediğinde bir sonraki sorum hangi şablon olduğu değildir. Şudur: müşteriler kim, kaç tane, ne sıklıkla geliyorlar, hangi veriye ihtiyaçları var ve onunla ne yapmalarına izin veriliyor?

Lisans Modeli Şekillendirdiğinde

Bazen lisans yalnızca nesneyi seçmez; tüm modeli büker. Bazı platform lisansları kullanıcıları en fazla on özel nesneden oluşan tek bir özel uygulamayla sınırlar (örneğin Lightning Platform – One App; Standard User Licenses (opens in a new tab), İngilizce).

İlk projelerimden birinde, büyük bir profesyonel hizmetler ve inşaat şirketi için, tüm çalışanlar için LinkedIn benzeri bir şey inşa etmemiz gerekiyordu: herkesin işleri, becerileri, sertifikaları, dilleri ve projeleri; böylece belirli bir ülkede sertifikalı köprü inşaatçısını bulabileceklerdi. Bir sınır olmasaydı bir kullanıcı-iş, kullanıcı-beceri, kullanıcı-sertifika, kullanıcı-dil ve kullanıcı-proje nesnesi, artı sertifikaların ve projelerin referans listelerini inşa ederdim. On nesnelik bir lisans altında ve hepsini harcamamamız söylenmişken bu mümkün değildi. Böylece iş bir tür “kaç notada bilirsin” yarışmasına döndü: bunu en az kaç nesneyle inşa edebilirim? Yanıt ikiydi. Her liste türü (iş, beceri, sertifika, dil, proje) için bir kayıt türü olan bir referans nesnesi ve buna işaret eden, eşleşen kayıt türlerine sahip bir kullanıcı özniteliği nesnesi.

Optimal model değildi. Raporlaması bir dertti ve daha temiz olmasını tercih ederdim. Ama lisansın izin verdiği buydu. Bunlara İsviçre çakısı nesneler diyorum: kalıbı cebinizde tutun ve sınırlar hiç yer bırakmadığında camı kırın ve kayıt türü ayrımına gidin. Yalnızca neden vazgeçtiğinizi bilin. Kayıt türü başına farklı izinler sizi yine de nesneyi bölmeye zorlayabilir.

Artık Tek Kullanıcılar İnsanlar Değil

Bir lisans sorusu daha önem kazandı: insan olmayan şeyler ne olacak? Entegrasyonların kimlikleri vardır. Ajanların kimlikleri vardır. Salesforce’un artık sistemden sisteme entegrasyonlar için bir Salesforce Integration lisansı var: yalnızca API, insanlar için değil; her Enterprise, Unlimited ve Performance Edition org’unda beş tane dahil (Standard User Licenses (opens in a new tab), İngilizce). Dolayısıyla yalnızca hangi kullanıcıların erişime ihtiyacı olduğunu sormayın. Hangi kimliklerin erişime ihtiyacı olduğunu sorun: bir kişi, bir müşteri, bir ortak, bir entegrasyon, bir ajan. Sonra da her birinin neyi görmesi ve yapması gerektiğini.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanlar verinin bir başka tüketicisi ve üreticisi haline geldikçe nesne seçimi ve lisanslama yalnızca insan ekranlarıyla ilgili değildir. Ajanın hangi kimlikle çalıştığını, o kimliğin neye ulaşabildiğini ve modelin ajanın ihtiyaç duyduğu veriyi onun kullanamayacağı bir nesnenin ya da iznin arkasına koyup koymadığını bilin.

Steve Trucking: Bir Kolay, Bir Zor

Steve Trucking Perakende Ortaklarıyla çalışır. Perakende Ortağı nedir? Bir işletme. Kolay: Hesap. Biri “ortak” sözcüğünü kullandı diye Retail_Partner__c oluşturmam.

Şimdi Alıcı, buzdolabını teslim alan kişi. Kişi mi? Kişi hesabı mı? Başka bir şey mi? Yılda bir milyon yeni Alıcı, bizim değil Perakende Ortaklarının müşterileri. İlişkiyi, erişimi ve ölçeği anlamadan bir nesneye atlamak istemediğim türden bir soru tam olarak bu. Buna 1. Kısım kontrol noktasında karar vereceğiz.

Mimarın Burada Karar Verdikleri

• Bir iş kavramının bir standart nesnenin amaçlanan kullanımına tam olarak uyup uymadığı ya da anlamının veya ağırlığının farklı olup olmadığı.
• Farklı iş etiketlerinin farklı varlıklar mı yoksa aynı varlığın farklı rolleri mi olduğu.
• Veriye ihtiyaç duyan her kişinin, harici kullanıcının, entegrasyonun ve ajanın planlanan lisanslar altında seçilen nesneye ulaşıp ulaşamayacağı.
• Kullanıcı kitlesinin ve oturum açma düzeninin (üye tabanlı ya da oturum tabanlı) lisansı ve modeli nasıl şekillendirdiği.
• Bir lisans sınırının ne zaman optimal olmayan bir modeli haklı çıkardığı ve bu ödünleşimin raporlamada ve izinlerde neye mal olduğu.

Mesele standart nesnelerin iyi, özel nesnelerin kötü olması değil. Seçimin sonuçları olması ve bazen hiç isim tarafından değil, onu kullanması gereken insanlar ve makineler tarafından belirlenmesi.

Daha Fazlası

• Salesforce Help, Standard User Licenses (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02, yeniden kontrol 2026-10-12: Platform kullanıcıları tahminler, potansiyel müşteriler, kampanyalar ve fırsatlar hakkına sahip değildir; en fazla 10 özel nesneden oluşan tek bir özel uygulama; her Enterprise Edition org’unda beş Salesforce Integration lisansı.
• Salesforce Help, Experience Cloud User Licenses (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02, yeniden kontrol 2026-10-12: Partner Community kişi hesaplarıyla kullanılamaz; raporlar, gösterge panoları ve standart paylaşım için Customer Community Plus; bir gün içinde birden fazla oturum açma tek oturum sayılır.
• Salesforce Help, Supported Editions for Service Features (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02, yeniden kontrol 2026-10-12: Agentforce Service ile hizmet düzeyi sözleşmeleri (yetkilendirme yönetimi); Knowledge çoğu sürümde ek maliyetlidir.
• Salesforce Help, Available Feature Licenses (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-12: Service Cloud User, “Access the Salesforce Console for Service”; kampanya oluşturmak ve yönetmek için Marketing User.