SharePoint’te Meta Veri ve İçerik Türü Tasarımı: Klasörden Çıkış

Dosya sunucusundan SharePoint’e taşınan kütüphanelerin çoğu eski klasör ağacını olduğu gibi getirir: Kalite/Prosedürler/2024/Üretim/Hat 3/Onaylı. İlk haftalarda kimse şikâyet etmez, çünkü yapı tanıdıktır. Sorun arama, filtreleme, saklama etiketi ve otomasyon devreye girince başlar; klasör her birinin önüne duvar olarak çıkar. Aşağıda site sütunu, içerik türü ve yönetilen meta veri (term store) ile sınıflandırmanın nasıl kurulacağını, hangi bilginin klasörde kalıp hangisinin meta veriye taşınacağını ve mevcut ağaçtan çıkış sırasını anlatıyoruz.

Klasör yapısı nerede tıkanır

Klasör bir dokümanı tek eksende sınıflandırır. Bir prosedür hem “Üretim” departmanına, hem “Hat 3”e, hem “İSG” konusuna aitse klasörde bunlardan yalnızca birini seçebilirsiniz. Diğer eksenler ya kopya dosyalarla ya da kullanıcının hafızasıyla taşınır. Hafıza ölçeklenmez. Sahada her seferinde aynı belirtilerle karşılaşıyoruz:

• Tek eksenli bulma: “Tüm departmanların yürürlükteki talimatları” gibi bir görünüm klasör yapısında kurulamaz.
• Yol uzunluğu: SharePoint Online’da dosya adı dahil çözümlenmiş yol 400 karakteri aşmamalı. Derin klasörler ve uzun dosya adları bu sınıra hızla yaklaşır; eşitleme istemcisi ve masaüstü uygulamalar çoğu zaman daha erken hata verir.
• Taşıma maliyeti: Departman adı değişince klasör yeniden adlandırılır; dokümana verilmiş bağlantılar ve akışlardaki yol tanımları kırılabilir.
• Otomasyon zorluğu: Power Automate veya saklama etiketi için “bu doküman ne?” sorusunun yanıtı klasör adından ayrıştırılmak zorunda kalır. Klasör adı değişince akış sessizce yanlış çalışır.

Bu, klasörü yasaklamak demek değil. İzin sınırı veya küçük, kalıcı bir gruplama için klasör hâlâ doğru araçtır. Yapılacak iş, sınıflandırma bilgisini klasör adından çıkarıp sorgulanabilir alanlara taşımaktır.

Site sütunu, içerik türü ve term store

Meta veri tasarımı üç yapı taşıyla kurulur. Farkları net olmazsa tanım yanlış katmanda yapılır ve on kütüphanede on farklı “Departman” sütunu oluşur:

Yapı	Kapsam	Ne için
Liste sütunu	Tek kütüphane	Yalnız o kütüphaneye özgü alan
Site sütunu	Site ve alt öğeleri	Birden çok kütüphanede aynı tanımla kullanılan alan
İçerik türü	Site veya içerik türü galerisi	Bir doküman sınıfının sütun seti, şablonu ve davranışı
Term store	Kiracı geneli	Hiyerarşik, merkezi yönetilen terimler

İçerik türü “bu bir prosedürdür ve prosedürün şu alanları vardır” tanımıdır. Örneğin “Kontrollü Doküman” içerik türü Doküman Tipi, Süreç Sahibi, Yürürlük Tarihi ve Revizyon alanlarını taşır. Aynı kütüphanede “Form” ve “Kayıt” gibi başka içerik türleri de durabilir; her biri kendi alan setini gösterir. Kiracı genelinde kullanılacak içerik türleri SharePoint yönetim merkezindeki içerik türü galerisinde tanımlanıp sitelere yayımlanır.

Yönetilen meta veri (term store), değerleri merkezden yönetilen hiyerarşik listelerdir: terim grubu → terim kümesi → terim. “Lokasyon” terim kümesi altında “Gebze > Hat 1, Hat 2” gibi bir hiyerarşi tanımlanır. Terim yeniden adlandırıldığında o terimi kullanan dokümanlar güncel adı gösterir; değişiklik SharePoint intranet sitelerine arka plandaki eşitleme işiyle kısa bir gecikmeyle yansır. Seçim (choice) sütununda değer değiştirirseniz mevcut kayıtlar eski değerde kalır. Fark burada.

Basit kural: değer listesi tek kütüphanede ve sabitse seçim sütunu; birden çok sitede kullanılıyor, hiyerarşik veya eş anlamlı içeriyorsa yönetilen meta veri; değerler başka bir listenin kayıtlarıysa (örneğin tedarikçi listesi) arama (lookup) sütunu.

Klasör mü meta veri mi: karar tablosu

Hangi bilginin nerede tutulacağını tartışırken masaya bu tabloyu koyun:

Bilgi	Önerilen yer	Gerekçe
Farklı erişim grubu	Ayrı kütüphane veya klasör	İzin sınırı yönetimi kolaylaşır
Departman, süreç	Yönetilen meta veri	Kütüphaneler arası tutarlılık
Doküman tipi	İçerik türü veya seçim sütunu	Alan setini ve şablonu belirler
Yıl, dönem	Tarih sütunu	Filtrelenebilir ve sıralanabilir
Proje, müşteri	Arama sütunu veya meta veri	Ana kayıt başka listede tutulur
Doküman seti (bir dosyanın ekleri)	Doküman kümesi veya klasör	Birlikte yönetilen paket

İzin farkı olan içerik için klasör yerine ayrı kütüphane açarsanız izinler kütüphane düzeyinde yönetilir; klasör düzeyinde devralması kırılmış izinlerden çok daha görünür ve denetlenebilir olur. Ayrıntısı SharePoint izin modeli rehberinde.

Varsayılan değerler ve zorunlu alanlar

Meta veri projelerinin çoğu aynı yerden çöker: kullanıcıdan her yüklemede beş alan doldurması beklenir. Bir ay sonra alanların yarısı boştur, kalanı “Diğer”. Doldurma yükünü azaltmanın yolları:

• Sütun varsayılan değeri: Kütüphane ayarlarındaki “Sütun varsayılan değer ayarları” ile klasör bazında varsayılan atanır. “Gebze” klasörüne yüklenen her dosyanın Lokasyon değeri otomatik “Gebze” olur. Klasörü hemen kaldırmadan meta veriye geçişte en işe yarar ara adım budur.
• İçerik türüne göre şablon: “Yeni” menüsünden oluşturulan doküman doğru içerik türü ve şablonla başlar.
• Zorunlu alanları sınırlayın: Gerçekten filtrede, saklamada veya otomasyonda kullanılacak iki-üç alanı zorunlu yapın. Zorunlu alanı eksik dosyalar modern arayüzde “gerekli bilgi eksik” uyarısıyla işaretlenir; kütüphanede check-out zorunluysa dosya eksik alan tamamlanana kadar check-out durumunda kalabilir ve başkaları güncel sürümü göremez.
• Otomatik doldurma: Süreç Sahibi gibi alanlar Power Automate ile bir ana listeden türetilebilir.

Görünümler, filtreler ve liste görünümü eşiği

Meta verinin karşılığını görünüm verir. “Yürürlükteki prosedürler” görünümü İçerik Türü = Kontrollü Doküman ve Durum = Yürürlükte filtresiyle, Departmana göre gruplanarak tanımlanır. Geçiş döneminde “öğeleri klasörsüz göster” seçeneği klasördeki dosyaları düz listede görmeyi sağlar.

Büyük kütüphanede liste görünümü eşiği (list view threshold) devreye girer. SharePoint Online’da bir kütüphane milyonlarca öğe barındırabilir; ama tek bir görünüm sorgusu 5.000 öğeyi aşan bir taramaya ihtiyaç duyarsa işlem engellenir. Eşik depolama sınırı değildir, sorgu sınırıdır. Kullanıcı bunu “kütüphane açılmıyor” diye bildirir; konsolda ilk bakılacak yer görünümün ilk filtresi ve o sütunun indeksli olup olmadığıdır. Kontrol sırası:

1. Filtrelenen sütunları indeksleyin: Kütüphane ayarlarındaki “İndekslenmiş sütunlar” bölümünden, görünümlerde ilk filtre olarak kullanılan sütunları indeksleyin. Bir liste en fazla 20 indeks taşır; indeksi liste eşiği aşmadan oluşturmak en sorunsuz yoldur, büyük listede indeks oluşturma arka planda zaman alabilir.
2. İlk filtre seçici olsun: Görünümün ilk filtresi sonuç kümesini 5.000’in altına indirmeli. “Durum = Yürürlükte” tek başına 5.000’i aşıyorsa Departman filtresi önce gelir.
3. Gruplamaya dikkat: İndekslenmemiş sütuna göre gruplama ve sıralama büyük kütüphanede hata üretebilir.
4. Arama ve filtre bölmesi: Çok büyük kütüphanede kullanıcıyı görünümler yerine arama sonuç sayfasına veya filtre bölmesine yönlendirmek daha iyi ölçeklenir.

Aynı eşik Power Apps uygulamalarında delegasyon kararlarını da etkiler; listeyi bir uygulamanın veri kaynağı yapmayı düşünüyorsanız Dataverse ile SharePoint listesi karşılaştırmasına bakın.

Mevcut klasör yapısından geçiş sırası

Kurumsal Microsoft 365 ve intranet projelerinde klasörden meta veriye geçiş tek hamlede yapılmaz. Tek hamlede yapılırsa geri dönüş de olmaz. İzlediğimiz sıra:

1. Envanter: Klasör ağacını ve dosya sayılarını çıkarın. Her klasör seviyesinin hangi bilgiyi temsil ettiğini (departman, yıl, durum) etiketleyin.
2. Model: Site sütunlarını, içerik türlerini ve terim kümelerini tasarlayın. Terim kümeleri term store’da merkezi olarak oluşturulur.
3. Eşleme tablosu: Klasör yolu → meta veri değeri eşlemesini bir CSV’de tutun.
4. Toplu meta veri atama: PnP PowerShell ile dosyalara değerleri yazın; ardından klasörleri düzleştirin veya yalnız izin sınırı olanları bırakın.
5. Görünümler ve eğitim: Yeni görünümleri yayımlayın; kullanıcıya klasör yerine filtre bölmesini gösterin.

Model kurulumunun PnP PowerShell örneği aşağıda. Site adresi ve adlar örnektir; komutlar bir site sütunu oluşturur, içerik türüne ekler ve içerik türünü kütüphaneye bağlar:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/kalite -Interactive `
  -ClientId <uygulama-kaydi-client-id>

Add-PnPField -DisplayName "Doküman Tipi" -InternalName "DokumanTipi" -Type Choice `
  -Group "Kurumsal Sütunlar" -Choices "Prosedür","Talimat","Form"

$parent = Get-PnPContentType -Identity "Document"
Add-PnPContentType -Name "Kontrollü Doküman" -Group "Kurumsal İçerik Türleri" -ParentContentType $parent
Add-PnPFieldToContentType -Field "DokumanTipi" -ContentType "Kontrollü Doküman"
Add-PnPContentTypeToList -List "Dokümanlar" -ContentType "Kontrollü Doküman"

Toplu atamada yönetilen meta veri sütunu için terim yolu kullanılabilir:

Set-PnPListItem -List "Dokümanlar" -Identity 128 `
  -Values @{"DokumanTipi"="Prosedür"; "Lokasyon"="Kurumsal|Lokasyon|Gebze"}

Sahada en sık gördüğümüz hata iç adlardadır. InternalName Türkçe karakter ve boşluk içerirse SharePoint kodlanmış ad üretir (_x00dc_ gibi) ve otomasyonda okumak işkenceye döner. İç adı her zaman ASCII ve boşluksuz verin. PnP PowerShell’in güncel sürümlerinde ortak çok kiracılı uygulama kaydı kullanılmıyor; kiracınızda kendi Entra ID uygulama kaydınızı oluşturup -ClientId ile belirtmeniz gerekir (Register-PnPEntraIDAppForInteractiveLogin bu kaydı oluşturur; cmdlet adını kullandığınız sürümün dokümantasyonundan doğrulayın). Değerler yazılırken “Değiştiren” ve “Değiştirilme” alanları güncellenir. Denetim tarafında bu toplu değişikliği bir geçiş işlemi olarak kayda geçirin.

Dosya sunucusundan taşıma aşamasının altyapı planı ayrıca ele alınır: dosya sunucusundan SharePoint ve OneDrive’a göç planı. Yönetilen meta verinin kavramsal temeli için Microsoft’un managed metadata dokümantasyonu resmi başvuru kaynağıdır. Kontrollü doküman kütüphanelerinin kurulumunda SharePoint doküman ve revizyon yönetimi hizmetimiz bu modeli sürüm ve onay ayarlarıyla birlikte ele alır; sürüm ayarlarının ayrıntısı doküman revizyon yönetimi rehberinde.

Sık sorulan sorular

Klasörleri tamamen kaldırmak gerekir mi?

Hayır. Klasör izin sınırı veya birlikte yönetilen küçük paketler için hâlâ iş görür. Amaç sınıflandırma bilgisini klasör adından çıkarıp filtrelenebilir sütunlara taşımaktır.

Seçim sütunu mu yönetilen meta veri mi kullanmalıyım?

Değer listesi tek kütüphanede kullanılıyor ve nadiren değişiyorsa seçim sütunu yeter. Birden çok sitede ortak kullanılan, hiyerarşik veya yeniden adlandırılması olası değerler için yönetilen meta veri seçin.

5.000 öğe eşiği kütüphaneye en fazla 5.000 dosya konabileceği anlamına mı gelir?

Hayır. Eşik depolama değil sorgu sınırıdır. Kütüphane çok daha fazla öğe taşır; görünümleri indekslenmiş sütunlarla ve seçici ilk filtreyle tasarlamanız gerekir.

Mevcut dosyalara meta veri toplu olarak nasıl atanır?

Klasör yolu ile meta veri değeri arasındaki eşleme bir CSV dosyasında hazırlanır ve PnP PowerShell Set-PnPListItem komutuyla dosyalara yazılır. Klasör bazlı varsayılan değerler yeni yüklemeler için ara çözümdür.