SHAREPOİNT LİSTELERİ İLE SÜREÇ TASARIMI: ALANLAR, GÖRÜNÜMLER, KURALLAR

Süreçlerinizi Excel dosyaları, e-posta zincirleri ve kişiye bağlı takip yöntemleriyle yönetiyorsanız, en küçük değişiklik bile kontrol kaybına dönüşebilir. SharePoint listeleri, bu dağınıklığı tek bir “kaynağa” indirger: tanımlı alanlar, tutarlı kurallar, izlenebilir durumlar ve raporlanabilir iş adımları.

Bu makalede, SharePoint listeleriyle süreç tasarımı yaparken kritik olan üç noktayı birlikte ele alacağız: doğru alan modeli (veri tasarımı), doğru görünüm stratejisi (operasyon) ve doğru kurallar (kalite ve kontrol). Ayrıca JSON sütun biçimlendirme ve Power Automate ile otomasyona giden yolu gerçekçi örneklerle göstereceğiz.

Hedefimiz; “liste açıp birkaç sütun eklemek” değil, kurum içinde sürdürülebilir, devredilebilir ve denetlenebilir bir yapı kurmak. İsterseniz temel kavramları öğrendikten sonra pratik yapmak için SharePoint eğitimi içeriğine de göz atabilirsiniz.

SharePoint listeleri ile süreç tasarımında temel yaklaşım

Başarılı bir süreç tasarımının temeli, “işi yapan insan” ile “veriyi işleyen sistem” arasındaki sınırı netleştirmektir. SharePoint listesi burada bir kayıt defteri değil; kuralları olan, durumları tanımlı, kimlerin hangi adımda neyi yapacağı belli bir süreç bileşenidir.

İyi bir yaklaşım için şu soruları en başta cevaplayın: Süreç hangi tetikleyiciyle başlar? Bir kaydın yaşam döngüsü hangi durumlardan geçer? Zorunlu bilgiler hangileridir? Onay ve bilgilendirme hangi noktada devreye girer? Bu sorular, alanları ve kuralları rastgele değil, kontrollü şekilde kurgulamanızı sağlar.

Süreç haritasını durum modeline dönüştürün

Önce süreç adımlarını metin olarak yazın, sonra bunu bir “durum modeli”ne çevirin. Örneğin: Taslak → İnceleme → Onay Bekliyor → Onaylandı → Tamamlandı / Reddedildi. Bu durumlar, liste alanlarınızın ve otomasyonunuzun merkezine oturur.

Kayıt yaşam döngüsünü ölçülebilir hale getirin

“Ne kadar sürüyor?” sorusunu cevaplamak için yalnızca başlangıç/bitiş alanları yetmez. En azından kritik geçişlerde tarih damgası tutmak, darboğazları ve ekip performansını görünür kılar. Bu amaçla “İnceleme Başlangıcı”, “Onay Tarihi” gibi alanlar planlanabilir.

Alanlar: Veri modelini doğru kurmak

SharePoint liste alanları süreç tasarımının omurgasıdır. Yanlış alan tipi seçimi, raporlamayı ve otomasyonu zorlaştırır; doğru seçim ise kullanıcı deneyimini iyileştirir ve hatayı azaltır. Temel hedef, veriyi mümkün olduğunca “yapısal” tutmaktır: serbest metin yerine seçenek, tarih, kişi, sayı gibi tiplerle ilerleyin.

Alan tipi seçimi için pratik rehber

• Choice (Seçenek): Durum, öncelik, kategori gibi sınırlı değerler için.
• Person: Talep sahibi, sorumlu, onaycı gibi roller için.
• Date/Time: SLA, hedef tarih, kapanış tarihi gibi zamana bağlı ölçümler için.
• Number/Currency: Maliyet, puan, bütçe, miktar gibi hesaplanabilir veriler için.
• Lookup: Referans veriyi ayrı listede tutup ilişkilendirmek için.

Zorunluluk ve varsayılan değerler ile hatayı azaltın

İyi bir form deneyimi, kullanıcıyı “doğru girdi”ye yönlendirir. Zorunlu alanları yalnızca gerçekten kritik olanlarda kullanın; geri kalanları süreç aşamasına göre kurallarla (ör. durum Onay Bekliyor iken Onaycı zorunlu) yönetin. Varsayılan değerler, özellikle kategori ve öncelik gibi alanlarda giriş hızını artırır.

Lookup ile referans veri ve normalizasyon

Aynı bilgiyi farklı kayıtların içine tekrar tekrar yazdırmak yerine, referans veriyi ayrı bir listede tutmak veri bütünlüğünü güçlendirir. Örneğin “Departmanlar”, “Tedarikçiler” veya “Proje Kodları” gibi veri kümelerini Lookup ile bağlamak, raporlama ve filtreleme tarafında ciddi avantaj sağlar.

Ek olarak, “tek alanla her şeyi çözerim” yaklaşımı çoğu zaman borç yaratır. Örneğin “Talep Detayı” alanı serbest metin olabilir, ancak “Talep Türü”, “Etki Alanı”, “Öncelik”, “Hedef Tarih” gibi alanların tipli olması, otomasyonda koşul yazmayı kolaylaştırır.

Görünümler: Operasyonu hızlandıran filtre ve düzen

Listeyi güçlü yapan şey sadece alanlar değildir; kullanıcıların günlük işi nasıl gördüğüdür. Görünümler, aynı veri setini farklı roller için farklı pencerelerle sunar. Örneğin ekip lideri “Bekleyen Onaylar” görünümüyle çalışırken, operasyon ekibi “Bu Hafta Kapanacaklar” görünümüyle ilerleyebilir.

Rol bazlı görünüm stratejisi

En iyi pratik, süreçteki ana rolleri belirleyip her rol için 1–3 temel görünüm oluşturmaktır. Örnek görünüm seti: “Benim Taleplerim”, “Sorumlu Olduklarım”, “Onay Bekleyenler”, “Gecikenler”, “Tamamlananlar”. Bu sayede kullanıcılar filtre yazmakla uğraşmadan doğrudan işe odaklanır.

Sıralama, gruplama ve koşullu biçimlendirme

Görünümde doğru sıralama (ör. hedef tarih artan) ve gruplama (ör. durum bazlı) yapmak, listeden bir “iş panosu” üretir. Ayrıca liste sütun biçimlendirme ile durumları renklendirerek kritik kayıtların kaçmasını engelleyebilirsiniz. Buradaki amaç estetik değil, operasyonel görünürlük sağlamaktır.

Aşağıdaki örnek, “Durum” alanını bir rozet gibi göstermeyi ve kritik statülere görsel vurgu vermeyi hedefler:

{
  "$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
  "elmType": "div",
  "style": {
    "padding": "2px 8px",
    "border-radius": "14px",
    "display": "inline-block",
    "font-weight": "600"
  },
  "attributes": {
    "class": "=if(@currentField == 'Gecikti','sp-field-severity--severeWarning', if(@currentField == 'Onay Bekliyor','sp-field-severity--warning', if(@currentField == 'Tamamlandı','sp-field-severity--good','sp-field-severity--low')))"
  },
  "txtContent": "@currentField"
}

Bu tür bir biçimlendirme, kullanıcıların “nerede aksiyon var?” sorusuna daha hızlı cevap vermesini sağlar. Özellikle çok sayıda kaydı yöneten ekiplerde, doğru görünüm + doğru vurgu, gereksiz toplantı ve takip mesajlarını azaltır.

Kurallar: Veri kalitesi, doğrulama ve süreç kontrolü

Kurallar, “herkesin kendi bildiğini okuduğu” ortamı disipline eder. SharePoint’te bunu üç katmanda düşünebilirsiniz: alan doğrulama (validation), iş mantığı (duruma göre zorunluluk) ve kullanıcı yönlendirmesi (form davranışı). Bunların her biri süreç tasarımının kalitesini belirler.

Validation formülleri ile mantıksal tutarlılık

Örneğin hedef tarih bugünden önce olamasın, kapanış tarihi hedef tarihten küçük olamasın, “Maliyet” girildiyse “Para Birimi” seçilsin gibi basit ama etkili doğrulamalar tanımlayabilirsiniz. Böylece raporlarınızın ve otomasyonunuzun üzerine kurulduğu veri daha tutarlı olur.

Duruma göre zorunluluk ve geçiş kuralları

Gerçek süreçlerde tüm alanlar en başta dolmaz. Örneğin talep açılırken “Onaycı” seçilmeyebilir; ancak kayıt “Onay Bekliyor” durumuna gelince onaycı zorunlu olmalıdır. Bu noktada form tarafında koşullu gösterim veya otomasyon tarafında koşullu kontrol devreye girer. Amaç kullanıcıyı cezalandırmak değil, yanlış akışı baştan önlemektir.

İzin modeli: Kim neyi görür, neyi değiştirir?

Kurumsal süreçlerde en kritik konulardan biri izinlerdir. Liste düzeyinde mi, öğe düzeyinde mi kontrol edeceksiniz? Talep sahibi sadece kendi kaydını görsün mü? Onaycı belirli alanları güncellesin mi? Bu kararlar, güvenlik ve operasyonun hızını birlikte etkiler. İyi tasarım; minimum yetki (least privilege) ile işin akmasını sağlayan tasarımdır.

Bu katmanda “kural koymak” kadar, kuralların bakımını yönetmek de önemlidir. Kuralların tek bir kişiye bağımlı olmaması için adlandırma standardı, dokümantasyon ve sürüm yaklaşımı belirlemek uzun vadede avantaj sağlar.

Otomasyon: Power Automate ile onay ve bildirim akışları

Liste süreç tasarımında otomasyon, hız ve izlenebilirlik sağlar. Power Automate ile yeni kayıt açılınca bildirim, durum değişince onay isteği, SLA yaklaşınca hatırlatma gibi senaryoları standartlaştırabilirsiniz. Burada önemli olan, otomasyonu “her şeye koşan akış” şeklinde değil, net tetikleyici ve net sorumluluk ile kurmaktır.

Akış tasarımında sürdürülebilirlik prensipleri

Akışlar büyüdükçe bakım zorlaşır. Bu yüzden isimlendirme (ör. SP-Requests-Approval), ortam değişkenleri, hata yakalama ve loglama yaklaşımı en baştan planlanmalıdır. Ayrıca “kim onaylıyor?” sorusu statik bir kişi yerine rol/alan üzerinden çözüldüğünde organizasyon değişikliklerinden daha az etkilenirsiniz.

Örnek: Durum Onay Bekliyor olunca onay akışı başlatma

Aşağıdaki örnek, bir kayıt güncellendiğinde “Durum” alanı Onay Bekliyor olduysa onay sürecini tetikleyen basit bir akış mantığını temsil eder. Bu yaklaşım, manuel e-posta trafiğini azaltırken kayıt geçmişini de güçlendirir:

// Power Automate mantığı (psödo-akış):
Trigger: When an item is created or modified (SharePoint)
Condition: Status equals 'Onay Bekliyor'
  Yes:
    Start and wait for an approval (Approver = item['Onaycı'])
    If Approved:
      Update item -> Status = 'Onaylandı', ApprovalDate = utcNow()
      Send email -> Requester
    If Rejected:
      Update item -> Status = 'Reddedildi', RejectionReason = response comments
      Send email -> Requester
  No:
    Do nothing

Bu modelde kritik nokta; onaycı alanının doğru tipte olması (Person), durumların net tanımlanması (Choice) ve raporlama için tarih damgalarının tutulmasıdır. Böylece hem süreç çalışır, hem de süreç ölçülebilir hale gelir.

Şablonlar, standartlar ve governance ile ölçekleme

Tek bir listeyi iyi tasarlamak değerli; ancak kurumda benzer süreçler çoğaldıkça standart ve governance ihtiyacı ortaya çıkar. Alan adlandırma kuralı, durum setleri, görünüm isimleri, sahiplik modeli, yetki yaklaşımı ve arşivleme politikası gibi konular, ölçeklemenin temelidir.

Adlandırma ve alan sözlüğü oluşturun

Aynı kavramın farklı listelerde farklı isimlerle geçmesi raporlama ve entegrasyonlarda sorun yaratır. Örneğin “Sorumlu”, “Atanan”, “Owner” gibi dağınık isimler yerine ortak bir alan sözlüğü oluşturun. Ayrıca durum setlerini mümkün olduğunca ortaklaştırın: Taslak/İnceleme/Onay/Tamamlandı gibi temel yapı, farklı süreçlere uyarlanabilir.

Değişiklik yönetimi ve versiyon yaklaşımı

Süreçler yaşayan varlıklardır; değişir. Bu değişimi kontrollü yapmak için “değişiklik talebi” yaklaşımı, test ortamı, yayın notu ve geriye dönük uyumluluk (ör. kaldırılan durumlar) planlanmalıdır. Böylece liste tasarımı bir kişinin uzmanlığına değil, kurumsal bir pratiğe dönüşür.

Uygulama örneği: Talep yönetimi listesi için uçtan uca tasarım

Örnek senaryo: IT talep yönetimi. Hedef: Ekiplerin talepleri standart açması, durumların izlenmesi, onay gereken taleplerin otomatik yönetilmesi ve KPI’ların raporlanması.

Önerilen alan seti

Aşağıdaki set, basit ama genişletilebilir bir yapı sunar: Talep Başlığı (Title), Talep Türü (Choice), Öncelik (Choice), Talep Sahibi (Person), Sorumlu (Person), Durum (Choice), Hedef Tarih (Date), Kapanış Tarihi (Date), Etki (Choice), Açıklama (Multiple lines), Ek Dosya (Attachment), Onaycı (Person), Onay Tarihi (Date).

Önerilen görünüm seti

Talep Sahibi için “Benim Taleplerim”, operasyon ekibi için “Sorumlu Olduklarım”, yöneticiler için “Onay Bekleyenler”, süreç sahibi için “Gecikenler” ve “Tamamlananlar” görünümü oluşturun. Her görünümde gösterilecek sütunları minimumda tutun; gereksiz sütun kalabalığı iş hızını düşürür.

Önerilen kural ve otomasyonlar

Öncelik Yüksek ise Hedef Tarih zorunlu, durum Onay Bekliyor ise Onaycı zorunlu, kapanış tarihi hedef tarihten önce olamaz gibi doğrulamalar koyun. Otomasyon olarak; kayıt açılınca sorumluya bildirim, durum Onay Bekliyor olunca onay akışı, gecikme yaklaşınca hatırlatma akışı devreye alın. Bu parçaları ayrı akışlar halinde kurgulamak, bakım maliyetini azaltır.

Sık yapılan hatalar ve hızlı kontrol listesi

Süreç tasarımı, küçük hataların birikerek büyük maliyete dönüştüğü bir alandır. En sık görülen hatalar: çok fazla serbest metin alanı, durumların net olmaması, görünümlerin rol bazlı tasarlanmaması, kuralların yazılı olmaması ve izin modelinin sonradan yamalanmasıdır.

1. Durum seti net mi ve geçişler mantıklı mı?
2. Alan tipleri raporlamaya uygun mu (Choice/Person/Date ağırlıklı mı)?
3. Rol bazlı temel görünümler hazır mı?
4. Zorunluluklar süreç aşamasına göre tanımlandı mı?
5. Otomasyonlar küçük, okunabilir ve sahipliği belirli mi?
6. İzin modeli “minimum yetki” ilkesine uyuyor mu?

Bu kontrol listesini her yeni süreç listesinde uygulamak, kısa vadede birkaç saat kazandırmaz; uzun vadede ekiplerin çalışma biçimini standardize ederek haftalarca sürecek kaosu engeller. SharePoint listeleriyle süreç tasarımı, doğru yapıldığında yalnızca bir teknoloji seçimi değil, kurumsal bir verimlilik hamlesidir.