Versiyon kontrolü, yorumlar, onaylar, denetim izleri ve güvenli erişim sunan bir hukuki sözleşme inceleme web uygulamasını nasıl planlayıp tasarlayıp inşa edeceğinizi öğrenin.
Ekran taslağı çizmeye veya teknoloji yığını seçmeye başlamadan önce, çözmekte olduğunuz problemi netleştirin. “Sözleşme inceleme” bir sayfalık NDA’yı düzeltmekten, katı onay kuralları olan çok taraflı karmaşık bir anlaşmayı koordine etmeye kadar her şey olabilir. Açık kullanım durumları, ürününüzün kimsenin tam olarak güvenmediği genel bir doküman aracına dönüşmesini engeller.
Gerçek rolleri ve her birinin ne yapması gerektiğini—çoğunlukla zaman baskısı altında—adıyla belirtin:
Bunları yazarken, ayrıca “mobilde çalışmalı”, “harici kullanıcılar dahili notları görmemeli” veya “imzadan önce onaylar yakalanmalı” gibi kısıtları da kaydedin.
MVP’niz, tekrar tekrar gerçekleşen sıkı bir aktiviteler döngüsünü desteklemeli:
Bir iş, tamamlanmak için e-posta, paylaşılan sürücüler ve sohbet dizileri arasında atlama gerektiriyorsa, uygulamanız için güçlü bir adaydır.
Bir sözleşmenin aşamaya bağlı olarak birden fazla “gerçekliği” olabilir. Herkesin aynı zihinsel modele sahip olması için versiyon durumlarını baştan tanımlayın:
Bu tanım daha sonra izinleri (kim düzenleyebilir), saklamayı (ne silinebilir) ve raporlamayı (ne “nihai” sayılır) şekillendirir.
Kuyruk hesabı gerektirmeyen ölçülebilir metrikler seçin. Örnekler:
Bu metrikler, daha sonra arama iyileştirmeye, daha net iş akışına veya daha katı RBAC’e yatırım gibi ödünleri yönlendirecektir.
Bir sözleşme inceleme web uygulaması için MVP, birkaç şeyi son derece iyi yapmalı: belgeleri düzenli tutmak, düzenlemeleri ve geri bildirimi takip etmeyi kolaylaştırmak ve sözleşmeyi “taslaktan” “imzalanmış” haline açık bir denetim iziyle taşımak. İlk günden her hukuki köşe durumunu çözmeye çalışırsanız ekipler hâlâ e-postaya dönecektir.
Birincil bir yolculukla başlayın: bir sözleşme yükleyin, inceleyicileri davet edin, değişiklikleri ve yorumları yakalayın, sonra onaylayın ve finalize edin.
Dahil edilmesi gereken ana MVP özellikleri:
Ağır otomasyonu erteleyin: gelişmiş madde playbook’ları, AI destekli yeniden yazma, karmaşık entegrasyonlar ve çok adımlı koşullu yönlendirme gibi. Bunlar değerlidir ama önce temel işbirliği döngünüz güvenilir olmalı.
Ölçülebilir çıktılar tanımlayın: inceleyiciler son versiyonu saniyeler içinde anlayabilmeli, onaylar izlenebilir olmalı ve ekipler herhangi bir sözleşmeyi veya ana hükmü hızla bulabilmeli—e-posta dizileri olmadan.
Bir sözleşme inceleme uygulaması, “sözleşmenin ne olduğu” ile “zaman içinde nasıl değiştiği”ni ne kadar iyi ayırdığına bağlıdır. Temiz bir veri modeli ayrıca izinleri, aramayı ve izlenebilirliği de kolaylaştırır.
Üst düzeyi Workspaces (veya “Müşteriler/Ekipler”) olarak modelleyin, ardından her workspace içinde Matters/Projeler olsun. Bir matter içinde tanıdık düzenleme için klasörler ve çapraz gruplama için etiketler (ör. “NDA”, “Yenileme”, “Yüksek Öncelik”) destekleyin.
Her Sözleşme için, kullanıcıların dosya açmadan filtreleyebileceği yapılandırılmış meta veriler saklayın:
Meta veriyi esnek tutmak için sabit birkaç alan artı workspace başına “özel alanlar” tablosu (anahtar + tür + değer) kullanın.
Üç katman düşünün:
Bu ayrım, bir sözleşmenin birçok versiyonu ve birçok dizisi olmasına izin verir, “belge geçmişi” ile “konuşma geçmişi” karışmaz.
Kim/ne/yaptı/nerede (isteğe bağlı IP/kullanıcı ajanı) ve hangi varlık üzerinde (sözleşme/versiyon/yorum/izin) gibi bilgileri kaydeden bir AuditEvent günlüğü oluşturun. Örnekler: “version_uploaded”, “comment_added”, “status_changed”, “permission_granted”, “export_generated”.
İhtilaf durumlarında savunulabilir olacak kadar bağlam saklayın, ancak denetim günlüğünde tam belgeleri çoğaltmaktan kaçının.
Workspace/matter seviyesinde saklama politikası alanları ekleyin (ör. kapanıştan sonra 7 yıl sakla). Denetimler veya dava için dışa aktarma primitives sağlayın: sözleşme meta verisi, tüm versiyonlar, yorum dizileri ve denetim izi tek bir paket halinde dışa aktarılabilmeli. Bu varlıkları erken tasarlamak sonraki acı veren geçişleri önler.
Sözleşme inceleme uygulamasında güvenlik büyük ölçüde iki şey hakkındadır: hangi belgenin görülebileceğini ve kullanıcıların onunla ne yapabileceğini kontrol etmek. Bu kuralları erken açık yapın; çünkü veritabanı modelinizi, UI’yı ve denetim izini şekillendirecekler.
Basit, tanınabilir rollerle başlayın ve bunları eylemlere eşleyin:
İzinleri eylem düzeyinde (gör, yorum yap, düzenle, indir, paylaş, onayla) tanımlayın ki roller büyüdüğünde uygulamayı yeniden yazmak zorunda kalmayın.
Çoğu hukuk ekibi matter/deal bazında çalışır. Bir “matter”ı birincil güvenlik sınırı olarak ele alın: kullanıcılara matter seviyesinde erişim verilir, belgeler bu erişimi miras alır.
Harici konuklar (karşı taraflar, dış danışmanlar) için kısıtlı hesaplar kullanın:
Erişim kontrolleri olsa bile kazara sızdırmayı önleyin:
Varsayılan olarak parola ile girişi destekleyin, ancak daha güçlü seçenekleri planlayın:
Tüm izin kararlarını sunucu tarafında tutun ve erişim/izin değişikliklerini kaydedin.
Redlining, bir sözleşme inceleme uygulamasının kalbidir: insanların ne değiştiğini, kimin değiştirdiğini ve kabul edip etmediklerini anladığı yerdir. Anahtar, doğru kalırken sıradan kullanıcılar için okunaklı kalan bir karşılaştırma yaklaşımı seçmektir.
İki yaygın yaklaşım vardır:
DOCX tabanlı difflar: Word yapısını (runs, paragraflar, tablolar) karşılaştırırsınız. Bu, biçimlendirme ve numaralandırmayı korur ve avukatların alışık olduğu şekilde çalışır. Ancak DOCX “sadece metin” değildir ve küçük biçimlendirme değişiklikleri gürültülü difflara yol açabilir.
Düz metin / madde tabanlı difflar: İçeriği temiz metne (veya ayrık maddelere) normalleştirip difflersiniz. Özellikle madde kütüphanesi yönetimine odaklanıyorsanız daha temiz ve kararlı karşılaştırmalar sağlar. Dezavantajı, düzen sadakatini (tablolar, başlıklar, izlenebilir biçimlendirme değişiklikleri) kaybetmektir.
Birçok ekip her ikisini birleştirir: DOCX farkındalığı ile kararlı metin blokları çıkarıp sonra o blokları diff’lemek.
Sözleşmeler nadiren lineer değişir. Karşılaştırma diffiniz şunları tespit etmelidir:
“Diff gürültüsünü” azaltmak önemlidir: boşlukları normalleştirin, önemsiz biçimlendirme kaymalarını yok sayın ve bölüm numaralandırmasını koruyabildiğiniz yerlerde saklayın.
Yorumları belirli bir versiyona ve isteğe bağlı olarak bir bağlama (başlangıç/bitiş offsetleri) bağlı olarak destekleyin; ayrıca metin kayarsa yeniden bağlama stratejisi (yakın bağlam eşleştirme) sunun. Her yorum ayrıca denetim izine yazılmalı: yazar, zaman damgası, versiyon ve çözüm durumu.
Hukuk dışı kullanıcılar genellikle işaretleme yerine başlık ihtiyacı duyar. Değişiklikleri bölüm ve tür (Eklendi/Silindi/Düzenlendi/Taşındı) bazında gruplayan, düz dilde snippet’ler ve ilgili konuma hızlı geçişler içeren bir “Değişiklik Özeti” paneli ekleyin.
Bir sözleşme inceleme web uygulamasının başarısı, insanların nasıl sorunsuz işbirliği yaptığına bağlıdır. Amaç, kimin ne yapması gerektiğini, ne zaman ve ne değiştiğini açıkça belli etmek ve savunulabilir bir geçmiş saklamaktır.
Madde, cümle veya seçime sabitlenmiş satır içi yorumları destekleyin. Yorumları birinci sınıf varlıklar olarak ele alın: diziler, @bahsetmeler ve dosya/versiyon referansları.
Dizileri çöz ve tekrar aç kontrolleri ekleyin. Çözülmüş yorumlar uyumluluk için keşfedilebilir kalmalı ama varsayılan olarak daraltılmalı ki belge okunabilir kalsın.
Bildirimler önemlidir; ancak öngörülebilir olmalıdır. Tercih edilen model: atama veya bahsedilme gibi olay temelli kurallar ve sürekli bildirimler yerine günlük özetler. Kullanıcıların sözleşme başına tercihleri ayarlamasına izin verin.
Bölümler veya görevler için hafif atamalar kullanın (ör. “Ödeme maddesini incele”) ve “Hukuk onaylandı” veya “Güvenlik onaylandı” gibi kuruluşunuza özel kontrolleri içeren bir kontrol listesine izin verin. Kontrol listelerini belirli bir versiyona bağlayın ki onaylar izlenebilir kalsın.
Küçük, anlaşılır bir durum makinesi tanımlayın: Taslak → İncelemede → Onaylandı → İmzalandı (organizasyona göre özelleştirilebilir). Geçitleri zorunlu kılın: yalnızca belirli roller sözleşmeyi ilerletebilsin ve gerekli kontrol listesi maddeleri tamamlanmadan ileri geçilmeye izin verilmesin.
Bunu rol tabanlı erişim kontrolü ve değiştirilemez olay günlükleriyle eşleştirin (kim durumu değiştirdi, kim onayladı, ne zaman).
Sözleşme ve atama düzeyinde son tarihler ekleyin, eskalasyon kuralları belirleyin (ör. 48 saat önce hatırlatma, sonra son gün bildirimi). Bir kullanıcı pasifse, atanan kişinin yöneticisine veya yedek inceleyiciye bildirim gönderin—tüm kanalı rahatsız etmeden.
İleride e-imza entegrasyonu ekleyecekseniz, “İmzaya hazır” durumunu son bir kontrol olarak hizalayın. Ayrıca bkz. /blog/contract-approval-workflow — daha detaylı desenler için.
Arama, bir klasör dolusu sözleşmeyi çalışan bir sisteme dönüştürür. Hukuk ekiplerinin basit soruları hızlıca yanıtlamasına ("Sorumluluk sınırlaması maddemiz nerede?") ve operasyonel sorulara destek vermesine ("Hangi tedarikçi sözleşmeleri gelecek çeyrekte bitiyor?") yardımcı olur.
Yüklenen dosyalar ve çıkarılmış metin üzerinde tam metin arama uygulayın. PDF ve Word dokümanlar için metin çıkarma adımı gerekir (ve taranmış PDF’ler için ideal olarak OCR) ki aramalar resim tabanlı belgelerde başarısız olmasın.
Eşleşen terimleri vurgulayarak ve nerede göründüğünü göstererek sonuçları kullanılabilir kılın (mümkünse sayfa/bölüm). Eğer uygulamanız versiyonları destekliyorsa, arama kullanıcıya son onaylı versiyon, tüm versiyonlar veya belirli bir snapshot içinde arama yapma seçeneği sunmalıdır.
Tam metin arama hikâyenin yarısıdır. Meta veri, sözleşme işini ölçeklendirmeyi sağlar.
Yaygın filtreler:
Bundan sonra kaydedilmiş görünümler (ön tanımlı veya kullanıcı tanımlı sorgular) ekleyin; bunlar akıllı klasör gibi davranır. Örneğin: “Yakında süresi dolacak tedarikçi MSA’ları” veya “İmzası eksik NDA’lar.” Kaydedilmiş görünümler paylaşılabilir olmalı ve izinlere saygı göstermeli, böylece kullanıcı asla erişemeyeceği sözleşmeleri görmesin.
Madde yönetimi zaman içinde incelemeyi hızlandırır. Kullanıcıların sözleşme içinde maddeleri etiketlemesine (ör. “Fesih”, “Ödeme”, “Sorumluluk”) ve bu etiketlenmiş snippet’leri yapılandırılmış girdiler olarak saklamasına izin verin:
Basit bir madde kütüphanesi, yeni taslaklarda yeniden kullanım sağlar ve gözden geçirenlerin sapmaları fark etmesine yardımcı olur. Aramayı madde kütüphanesi ve icra edilmiş sözleşmelerde “tazminat” gibi terimleri bulacak şekilde eşleştirin.
Ekipler genellikle sözleşme grupları üzerinde işlem yapar: meta veriyi güncelle, sahip ata, durumu değiştir veya rapor için listeyi dışa aktar. Arama sonuçları üzerinde toplu eylemleri destekleyin ve ana alanları ve denetime uygun zaman damgasını içeren dışa aktarmalar (CSV/XLSX) sağlayın. Daha sonra planlı raporlar sunacaksanız, dışa aktarmaları baştan tutarlı ve öngörülebilir şekilde tasarlayın.
Sözleşmeler uygulamanıza gelmeden önce diğer araçlarda yaşar. Dosya işleme ve entegrasyonlar zor olduğunda, inceleyiciler eki e-posta ile göndermeye devam eder—ve versiyon kontrol sessizce bozulur.
İnsanların gerçekte gönderdiği iki formatı destekleyerek başlayın: DOCX ve PDF. Web uygulamanız yüklemeleri kabul etmeli, onları normalize etmeli ve hızlı bir tarayıcı içi önizleme oluşturmalı.
Pratik bir yaklaşım: orijinal dosyayı saklayın, ardından üretin:
Kullanıcı bir “taranmış PDF” (sadece görüntü) yüklediğinde ne olacağını açıkça belirtin. OCR planlıyorsanız, kullanıcıya işlem adımı olarak gösterin ki metin aramasının gecikebileceğini anlasın.
Birçok sözleşme e-posta yoluyla gelir. Basit bir gelen e-posta adresi düşünün (ör. contracts@yourapp) — biri bir diziyi ilettiğinde yeni belge oluşturur veya yeni bir versiyon ekler.
Harici taraflar için paylaşılan linkleri tercih edin. Link tabanlı akış yine de versiyon geçmişinizi koruyabilir: link üzerinden yapılan her yükleme yeni bir versiyon olur, gönderen “harici katkıda bulunan” olarak yakalanır ve denetim izi için zaman damgası eklenir.
Kopyala-yapıştır ve yeniden yüklemeyi kaldıran entegrasyonlara odaklanın:
Güvenilir olaylar ve uç noktalar sunun: contract.created, version.added, status.changed, signed.completed. Bu, diğer sistemlerin durum ve dosyaları senkronize etmesini sağlar ve polling gerektirmez.
Bir sözleşme inceleme aracı, yoğun bir inceleyicinin iki soruyu hızlıca yanıtlayıp yanıtlayamadığına göre başarılı olur: ne değişti ve benden ne isteniyor. UI’yı bu anlara göre tasarlayın, dosya yönetimi etrafında değil.
Varsayılan deneyimi boş bir editör yerine adım adım bir inceleme yapısı yapın. İyi bir akış: sözleşmeyi aç → değişikliklerin ve açık maddelerin özeti görülür → değişiklikleri sırayla incele → yorum/karar bırak → gönder.
Açık çağrılar kullanın: “Değişikliği kabul et”, “Düzeltme iste”, “Yorumu çöz”, “Onaya gönder”. “Commit” veya “merge” gibi jargonlardan kaçının.
Versiyon karşılaştırması için bir yan yana görünüm sağlayın:
Kullanıcı listeden bir değişikliği tıkladığında, tam konuma kaydırın ve kısa bir vurgu ile görmesi sağlanın.
İzlenebilirlik güven verir. v1, v2 gibi tutarlı etiketler ve isteğe bağlı insan etiketleri (“Tedarikçi düzenlemeleri”, “Dahili hukuk temizliği”) kullanın. Versiyon etiketi her yerde görünmeli: başlıkta, karşılaştırma seçicisinde ve etkinlik akışında.
Klavye navigasyonunu destekleyin (tab sırası, sonraki/önceki değişiklik için kısayollar), okunabilir kontrast ve ölçeklenebilir metin. Arayüzü hızlı tutun: uzun sözleşmeleri parça parça render edin, kaydırma konumunu koruyun ve yorumları otomatik kaydedin.
En iyi mimari, ekibinizin teslim edip güvenliği sağlayabileceği ve sürdürebileceği mimaridir. Çoğu ürün için önce modüler monolith (bir deploy, net ayrılmış modüller) ile başlayın; ancak ölçek veya ekip büyüklüğü gerçekten gerektiğinde servislere bölün.
Tipik bir kurulum:
Çoğu ekip React (veya Vue) kullanır; buna bir belge görüntüleme katmanı (PDF viewer) ve redline için bir editör yüzeyi ekleyin. Gerçek zamanlı varlık ve güncellemeler için WebSockets (veya SSE) kullanarak inceleyicilerin yeni yorumları ve durum değişikliklerini sayfa yenilemeden görmesini sağlayın.
Hukuk ekipleri belgelere dair denetim izi bekler. “Yüklendi”, “paylaşıldı”, “yorum yapıldı”, “onaylandı”, “dışa aktarıldı” gibi olaylar için eklenemez günlükler uygulayın. Basit bir event-sourcing yaklaşımıyla immutable olayları saklayıp okunabilir modeller oluşturabilirsiniz.
İş akışını ve izinleri hızla doğrulamak istiyorsanız, Koder.ai gibi vibe-coding platformu React frontend + Go/PostgreSQL backend içeren çalışan bir prototipi sohbet tabanlı bir spesifikasyondan elde etmenize yardımcı olabilir. Bu, sözleşme veri modeli, RBAC, denetim olayları ve temel ekranları hızla oluşturup kaynak kodu dışa aktarmak için özellikle yararlıdır—ardından diff, OCR ve uyumluluk kontrollerini sertleştirirken kodu geliştirirsiniz.
Sözleşme inceleme araçları güven üzerine kurulur. Ürününüz “sadece dahili” olsa bile güvenlik ve yönetişimi temel gereksinimler olarak ele alın—çünkü sözleşmeler genellikle fiyatlama, kişisel veri ve pazarlık geçmişi içerir.
Tüm ağ trafiği için TLS kullanın ve verileri diskte şifreleyin. Belgeleri şifrelemekle yetinmeyin: meta veriler (taraf adları, yenileme tarihleri, onay notları) da şifrelenmeli; meta veri genellikle sorgulanması ve sızdırılması daha kolaydır.
Nesne depolamada sunucu tarafı şifrelemeyi etkinleştirin ve anahtarların merkezi yönetildiğinden (ve döndürüldüğünden) emin olun. Redline’ları ayrı artefaktlar olarak saklıyorsanız, bu türetilmiş dosyalara da aynı kontrolleri uygulayın.
Birden fazla workspace (müşteri, departman, bağlı kuruluş) destekliyorsanız, tenant verisi ayrımını katı uygulayın. Bu, yalnızca UI filtrelerinde değil veri katmanında da uygulanmalı; her sorgu tenant/workspace kimliğiyle sınırlandırılmalı.
Varsayılan roller minimal erişime sahip olmalı; yükseltilmiş eylemler (dışa aktar, sil, paylaşım linki oluşturma, admin ayarları) açık izinler gerektirmeli. Bunu RBAC modelinize bağlayın ki denetim günlükleri anlamlı olsun.
Yedeklemeler işe yarar olmalıysa geri yüklenebilir olmalıdır. Şunları tanımlayın:
Kimin geri yükleme başlatabileceğini ve kazara üzerinin yazılmasını nasıl önleyeceğinizi dokümante edin.
Güvenlik ve uyumluluk için bir denetim izi tutun: kimlik doğrulama olayları, izin değişiklikleri, belge erişimleri/indirmeleri ve kilit iş akışı eylemlerini kaydedin. Üçüncü taraf sağlayıcıları (depolama, e-posta, e-imza entegrasyonu) canlıya almadan önce güvenlik duruşu, veri konumu ve ihlal süreçleri açısından değerlendirin.
Bir sözleşme inceleme web uygulaması güven üzerine kurulur: kullanıcılar izlenen değişikliklerin doğru olduğuna, izinlerin uygulandığına ve onay iş akışının her adımının düzgün kaydedildiğine güvenmek ister. Test ve işletme, bitirme dokunuşu değil çekirdek ürün özellikleri olarak ele alınmalı.
Yüksek riskli davranışlarla başlayın:
Sözleşme dosyaları büyük olabilir ve versiyonlar birikebilir. Aşağıyı simüle eden yük testleri yapın:
Anahtar eylemler için p95 gecikmeyi izleyin: belge açma, diff oluşturma, arama ve dışa aktarma.
Uçtan uca izleme için instrument ekleyin:
Yaygın olaylar için runbook’lar oluşturun (takılı diff işi, dönüştürme hatası, arama bozulması). Hafif bir durum sayfası ekleyin: /status.
Kontrollü bir yayına çıkın: küçük bir beta kullanıcı grubu davet edin, uygulama içinde geri bildirim toplayın ve haftalık yineleyin. Yayınları küçük ve geri alınabilir tutun (özellik bayrakları yardımcı olur). Sürekli bakım; bağımlılık yamaları, güvenlik incelemeleri, periyodik erişim denetimleri ve e-imza entegrasyonu için regresyon testleri içermelidir.
Başlangıçta sık tekrar eden, kapatılabilir bir döngüyle başlayın:
Kullanıcılar işi hâlâ e-posta veya paylaşılan sürücülerde “bitirmek” zorundaysa, MVP’niz temel bir adımı kaçırıyor demektir.
Rolleri ve kısıtlarını erken tanımlayın (hukuk, satış, tedarik, dış danışman). Ardından her rolü küçük bir iş listesine eşleyin:
Bu, hukuki ekiplerin ihtiyaç duyduğu iş akışı ve güven özellikleri olmadan genel bir doküman aracına dönüşmeyi önler.
“Versiyon”u farklı kuralların uygulandığı açık durumlar seti olarak ele alın:
Bu tanımlar kimlerin düzenleyebileceğini, neyin saklanacağını ve neyin “son” sayılacağını belirler.
Üç katmanlı bir model kullanın:
Bu, dosyalar değişse bile belge geçmişi ile konuşma geçmişini tutarlı tutar.
Denetim kaydı eklenemez ve değiştirilemez olmalıdır. Aşağıdaki gibi olayları kaydedin:
version_uploadedcomment_addedstatus_changedpermission_grantedexport_generatedKim/ne/zaman/nereye dair yeterli bağlamı saklayın; ancak denetim kaydına tüm belgeleri tekrar tekrar koymaktan kaçının.
Basit bir rol tabanlı erişim kontrolü (RBAC) ve eylem düzeyinde izinler ile başlayın:
Bir matter/projeyi asıl güvenlik sınırı yapın, belgeler bu erişimi miras alsın ve tüm izin kontrolleri sunucu tarafında yapılıp kaydedilsin.
Kısıtlı misafir hesapları (veya sıkı kapsamlı paylaşım linkleri) kullanın:
Ek korumalar: damgalama(watermark), hassas matter’lar için indirme kısıtları, iç notların harici görünmez olması.
Kullanıcı beklentilerine uygun bir diff stratejisi seçin:
Çoğu ekip DOCX’i kararlı bloklara ayrıştırıp, boşluk/format normalizasyonu yaptıktan sonra blokları diff’leyerek yürür.
Yorumları belirli bir versiyona ve bir metin aralığına (başlangıç/bitiş) bağlayın ve çevresel bağlamı saklayın. Metin kaydığında yeniden bağlama (nearby context matching) stratejisi kullanın; “yüzen” yorumlar yerine sağlam bir yeniden yerleştirme tercih edin.
Ayrıca çözüm durumunu (açık/çözüldü/tekrar açıldı) takip edin ve yorum eylemlerini denetim kaydına dahil edin.
Tam metin arama ile yapılandırılmış meta veriyi birleştirin:
Paylaşılabilir, izinlere duyarlı kaydedilmiş görünümler (saved views) ekleyin ki kullanıcılar göremeyecekleri sonuçlarla karşılaşmasın.