Birleşik denetim zaman çizelgesi: kim ne yaptı, ne zaman, neden için şema ve UI

Birleşik denetim zaman çizelgesi nedir (ve neden işe yarar)

Birleşik denetim zaman çizelgesi, ürününüzdeki olayların zaman sırasına göre tek, okunabilir bir akışıdır. Araçlar arasında atlamadan ne olduğunu anlamanızı sağlar. Ayrı oturum/giriş günlükleri, veritabanı geçmiş tabloları ve iş akışı izleyiciler yerine, olayların hikâyesini anlatan tek bir yeriniz olur.

Ekipler genellikle bir şey ters gittiğinde acıyı hisseder: bir müşteri değişikliği onaylamadığını söyler, bir kayıt “gizemli” şekilde güncellenir veya bir hesap tehlikede görünür. Veri genellikle vardır, ama dağınıktır, farklı etiketlenmiştir ve ham günlükleri açıklamaya dönüştürecek küçük detaylardan yoksundur. Soruşturmalar yavaşlar ve insanlar tahminde bulunmaya başlar.

Birleşik denetim zaman çizelgesinin beş soruyu yanıtlaması gerekir:

• Kim yaptı (kullanıcı, servis veya sistem)
• Ne yaptı (eylem ve hedef)
• Ne zaman oldu (kesin zaman damgası, açık bir zaman diliminde)
• Nerede oldu (web, mobil, API)
• Neden oldu (sebep, istek veya onay)

Kapsam önemlidir. Çoğu ürün için oturumlar ve girişler, CRUD veri değişiklikleri, iş akışı adımları (onaylar ve durum geçişleri) ve kilit sistem olayları (izin değişiklikleri veya başarısız erişim denemeleri gibi) kapsanmalıdır. Bunları iyi açıklayabiliyorsanız, günlük denetim sorularının çoğunu çözersiniz.

Ayrıca bunun ne olmadığını netleştirmek faydalıdır. Birleşik denetim zaman çizelgesi tam bir SIEM değildir ve derinlemesine analiz aracı değildir. Amaç, destek, güvenlik incelemeleri ve iç hesap verebilirlik için hızlı, güvenilir cevaplar sunmaktır.

No-code platformlarda (örneğin AppMaster) uygulama geliştiriyorsanız, backend mantığı, UI aksiyonları ve entegrasyonlar aynı olay formatını yayımlayabildiği için birleşik bir zaman çizelgesi daha da faydalı olur. Bu, ürünün hikâyesini okuyan herkes için tutarlılık sağlar.

Hangi olaylar dahil edilmeli: girişler, veri değişiklikleri, iş akışı adımları

Birleşik zaman çizelgesi, gerçek eylemlerin gerçekleştiği yerlerden veri çekmezse işe yaramaz. Çoğu ürünün dört ana kaynağı vardır: kimlik doğrulama (girişler ve oturumlar), veri değişiklikleri (oluşturma, güncelleme, silme), iş akışı adımları (onaylar, atamalar, durum geçişleri) ve entegrasyonlar (webhook'lar, içe aktarımlar, botlar).

Başlangıç için küçük bir olay kategorisi seti tanımlayın ve buna sadık kalın. Kategoriler uygulamayı değil niyeti açıklamalıdır. Örneğin, şifre sıfırlama ile bir API anahtarının döndürülmesi farklı sistemlerden gelse bile her ikisi de erişim olayıdır. İnsanların zaman çizelgesini hızlı tarayabilmesi için access.login.succeeded veya data.customer.updated gibi tutarlı adlandırma kullanın.

Her şey denetlenmek zorunda değildir. Pratik bir kural: durumu değiştiren, erişimi değiştiren veya iş sonuçlarını tetikleyen eylemleri kaydedin. Sayfa görüntülemeleri, otomatik kaydetmeler ve tekrar eden arka plan denemeleri gibi gürültuyu atlayın; olay çözümlemesi için gerekiyorsa bunları dahil edin.

Kimlik (actor) türlerini açık hale getirin ki “kim” asla tahmin edilmesin. Bir zaman çizelgesi öğesi, eylemin bir kullanıcı, yönetici, servis hesabı veya otomasyon tarafından yapıldığını net şekilde söylemelidir.

Başlangıç için basit olay grupları örneği:

• Erişim: giriş başarılı/başarısız, çıkış, MFA değişiklikleri, şifre sıfırlama
• Veri: kayıt oluşturuldu/güncellendi/silindi, toplu düzenlemeler, dışa aktarmalar
• İş akışı: durum değişikliği, onay/red, atama, SLA ihlali
• Entegrasyon: içe aktarma tamamlandı/başarısız, webhook alındı, dış senkronizasyon
• Yönetici/güvenlik: rol değişiklikleri, izin değişiklikleri, API anahtarı olayları

Uygulamanız çok kiracılı (multi-tenant) ise her olayda tenant kimliğini ekleyin. Ayrıca ortamı (prod, staging, dev) kaydedin ki soruşturmalar sırasında zaman çizelgelerini karıştırmayın.

Zaman çizelgesini okunabilir yapan minimum veri modeli

Bir zaman çizelgesi, her satır aynı temel soruları yanıtladığında birleşik hisseder. Her sistem farklı logluyorsa, şifreli kayıtlar değil, net bir hikâye ortaya çıkar.

Her olayı tek bir basit yapıya standardize edin. İleride ekstra ayrıntılar saklayabilirsiniz, ama zaman çizelgesinin her zaman tutarlı bir başlığı olmalı.

Bulunması gereken beş alan

Bir satırın detay paneli açmadan anlaşılmasını sağlayan minimum alanlar:

• event_id: belirli bir olayı referans almak için benzersiz, sabit bir kimlik
• timestamp: ne zaman olduğu (mümkünse milisaniye hassasiyetiyle)
• actor: bunu yapan (kullanıcı, servis hesabı, otomasyon)
• action + target: ne oldu ve kime/neyi yapıldı (ör. “updated” + “Invoice #1042”)
• outcome: başarı/başarısızlık (ve başarısızsa kısa bir sebep kodu)

Bu beş alan zaman çizelgesini okunabilir kılar. Ancak soruşturmalar genellikle tek satırlardan ziyade olay zincirleri içerir.

Günlükleri hikâyeye çeviren üç ID

Ekranlar, API'ler ve arka plan işleri arasında aktiviteyi takip etmenizi sağlayan birkaç tanımlayıcı ekleyin:

• correlation_id: bir kullanıcı niyetini birden fazla adımda bağlar (tıklama -> doğrulama -> güncelleme -> bildirim)
• session_id: olayları bir oturumla ilişkilendirir; hesap paylaşımı veya kaçırma modellerini tespit etmeye yardımcı olur
• request_id (veya trace_id): API çağrılarını ve arka plan işlerindeki zinciri bağlar

Zaman son sürprizdir. Zaman damgalarını UTC'de saklayın ve UI'nın doğru sıralama yaparken local zamanı gösterebilmesi için bir timezone alanı (veya actor'un locale'i) tutun.

Örnek: bir kullanıcı “İade onayla”ya tıklar. Zaman çizelgesi görünür bir eylem gösterebilir; aynı zamanda correlation_id onayı, durum değişikliğini, müşteriye gönderilen e-postayı ve otomatik ödeme adımını tek bir tutarlı zincir halinde gruplayabilir.

Şema önerisi: tablolar ve alanlar (pratik, kusursuz değil)

Birleşik denetim zaman çizelgesi, her anda tek bir olay kaydettiğinizde en iyi çalışır ve detayları bunun üzerine iliştirirsiniz. Temel satırı küçük ve tutarlı tutun; değişen detayları ayrı yere koyun.

Temel tablolar

Çoğu ürünü kapsayan dört tablo:

• audit_event: id, tenant_id, occurred_at, event_type (login, data_change, workflow), actor_id, target_type, target_id, summary, ip, user_agent, request_id, correlation_id, why_id (nullable)
• audit_actor: id, tenant_id, actor_type (user, api_key, system), user_id (nullable), display_name, role_snapshot (opsiyonel JSON)
• audit_target (opsiyonel, bir olayın birden çok hedefi olabilir): event_id, target_type, target_id, label (örneğin “Invoice INV-1042”)
• audit_change: event_id, field_path (örneğin billing.address.city), old_value_json, new_value_json, value_type, redacted (bool)

Hedefler için en basit model audit_event içinde target_type + target_id tutmaktır. Bir olay birden fazla kaydı etkiliyorsa audit_target ekleyin ve hızlı filtreleme için audit_event üzerinde birincil hedefi saklayın.

Değerler için, alan başına satırlar audit_change içinde tutmak UI'ı okunabilir ve aranabilir kılar. Tam anlık görüntülere (snapshots) ihtiyacınız varsa audit_evente old_record_json ve new_record_json ekleyebilirsiniz; ama depolama kontrolü için bunları opsiyonel tutun.

İş akışı alanları

İş akışı adımları için audit_eventde (sadece event_type='workflow' olanlar) şu sütunları ekleyin: workflow_id, step_key, transition_key, from_status, to_status, result (success, blocked).

Hızı koruyan indeksler

Çoğu ekran “bir tenant için son etkinlik”, “bir kayıtla ilgili her şey” veya “bir kişi tarafından yapılan her şey” sorgular. Bu yolara indeks ekleyin:

• (tenant_id, occurred_at desc)
• (tenant_id, target_type, target_id, occurred_at desc)
• (tenant_id, actor_id, occurred_at desc)
• audit_change üzerinde: (event_id), ve alan bazlı filtreleme yapıyorsanız (field_path)

“Neden”i yakalamak: sebepler, onaylar ve bağlam

Sadece “kim ne yaptı, ne zaman” gösteren bir zaman çizelgesi en zor soruyu yanıtlamaz: neden yaptılar? Neden yoksa soruşturmalar tahminlere dönüşür ve insanlar eski biletler veya sohbet dizilerini takip etmek zorunda kalır.

Sebep kodları serbest metinden daha iyidir (çoğunlukla)

Serbest metin faydalı olabilir, ama düzensiz olur. İnsanlar aynı şey için farklı ifadeler kullanır veya hiç yazmayı unutur. Kısa, tutarlı bir reason_code temiz filtreleme sağlar; gerektiğinde opsiyonel reason_text insan detayını ekler.

Hem olaya hem de iş akışı geçişine koyun ki her giriş bağlam taşısın:

• reason_code (veri veya durum değiştirildiğinde zorunlu)
• reason_text (opsiyonel, kısa ve gözden geçirilmiş)

Pratik bir yöntem, alan başına 10-30 arası sabit sebep kodu tanımlamaktır (fatura, erişim, sipariş, destek gibi). Bunları stabil tutun ve yenilerini yavaşça ekleyin.

Onaylar ve otomasyon bağlamı

“Neden” çoğu zaman “bir politika böyle dedi” veya “birisi onayladı” demektir. Onay bağlamını yapılandırılmış alanlarda saklayın ki başka bir sistemi açmadan soruları hızlıca cevaplayabilesiniz.

Herhangi bir olay onaylanmış, otomatikleştirilmiş veya bir başkası adına yürütülmüşse, ilgili olduğunda şu alanları saklayın:

• approved_by_actor_id ve approved_at
• approval_rule_id (veya policy_name) ve decision (approved/denied)
• reference_id (ticket, case veya change request numarası)
• automation_rule_name ve rule_version
• automation_inputs (güvenli, minimal parametreler örn. threshold=5000)

Bir uyarı: “neden” alanları gizli bilgilerin sızdığı yerler olabilir. Şifreler, API anahtarları, tam oturum tokenları veya ham ödeme bilgilerini reason_text veya automation_inputs içinde saklamayın. Bir değer hassassa kırpılmış bir versiyonunu (son 4 hane) veya token_present=true gibi bir gösterge saklayın.

Örnek: iade limiti yükseltildi. Zaman çizelgesi “Limit 500'den 5000'e değişti” derken reason_code=RISK_REVIEW, approved_by=Maria, policy=RefundLimitPolicy v3, reference_id=CASE-18422 ve automation_rule_name boş (manuel) olabilir. Bu giriş durumu açıklamak için yeterlidir.

UI düzeni: soruları hızlı cevaplayan tek ekran

İyi bir birleşik denetim zaman çizelgesi arama sonuçları sayfası, bir hikâye ve bir fiş (receipt) karışımı gibidir. Amaç hızdır: 10 saniye içinde ne olduğunu fark edebilmelisiniz, ardından bir satırı açıp harekete geçmek için yeterli bağlamı görmelisiniz.

Basit üçlü panel düzeni

Her şeyi aynı ekranda üç alana koyun: solda filtre paneli, ortada zaman çizelgesi listesi ve sağda detay çekmecesi (veya slide-over). Detaylar incelenirken liste görünür kalmalı ki yerinizi kaybetmeyin.

Filtreleri az fakat faydalı tutun. Olay veya destek görüşmeleri sırasında insanların ilk başvurduğu filtrelerle başlayın:

• Tarih aralığı (hızlı ön ayarlar: son 1 saat, son 24 saat)
• Actor (kullanıcı, API anahtarı, sistem)
• Hedef (kayıt, nesne türü, iş akışı örneği)
• Olay türü (login, update, approval, export)
• Sonuç (success, failed, denied)

Ortadaki listede her satır açmadan “kim/ne/zaman/neden” sorusunu yanıtlamalı. Zaman damgası (zaman dilimiyle), actor adı (ve gerekiyorsa rol), eylem fiili, hedef etiketi ve kısa bir sebep snippet'i gösterin. Sebep yoksa boş bırakmayın; yerine “Sebep belirtilmemiş” gibi net bir yer tutucu gösterin.

Detay çekmecesi: kanıtı gösterin

Detay görünümü güven kazanacağınız yerdir. Tam bağlamı gösterin: girişler için actor IP'si ve cihaz, veri düzenlemeleri için önce/sonra alan değerleri, onaylar için iş akışı adımı, atanan kişi ve karar.

Yük (payload) üzerinde bir “İlgili olaylar” şeridi ekleyin ki “İstek oluşturuldu” -> “Yönetici onayladı” -> “Ödeme başarısız” gibi yakın adımlara atlayabilesiniz. Denetçiler ve mühendisler için raw payload görünümü ekleyin ama varsayılan gizli olsun.

Başarısızlık durumlarını belirgin yapın. Reddedilen veya başarısız sonuçlar için net stil kullanın ve “İzin reddedildi” veya “Doğrulama başarısız” gibi mesajlar gösterin.

Adım adım: gerçek bir üründe nasıl inşa edilir

Denetim zaman çizelgesini bir özellik gibi ele alın, bir günlük yığını gibi değil. Destek ve uyumluluk ekipleri “kim ne yaptı, ne zaman ve neden” sorusunu bir dakikadan kısa sürede yanıtlayamıyorsa, tekrar gözden geçirin.

Çoğu uygulama için işe yarayan bir yapım sırası:

• Önce küçük bir olay taksonomisi ve zorunlu alanları tanımlayın. Ne sayılır, hangi alanlar zorunlu: actor, zaman, eylem, nesne, sonuç ve correlation ID gibi alanları kilitleyin.

• Gerçeği zaten bilen kaynakları enstrümante edin. Kimlik doğrulama giriş ve token olayları üretir, CRUD katmanları alan değişiklikleri ile create/update/delete olayları üretir, iş akışı motorları adım ve karar olayları üretir.

• Olayları append-only bir denetim deposuna yazın. Denetim satırlarını güncellemeyin. Yazma sırasında sıkı doğrulama yapın (eksik actor, eksik nesne ID, geçersiz zaman damgası) ki “sonradan düzeltme” güveni bozmasın.

• İnsanların nasıl soruşturduğuna uygun okumalar (reads) inşa edin. Genelde üç görünüm gerekir: ana zaman çizelgesi, olay detay paneli ve “ilgili olaylar” sorguları (aynı correlation ID, aynı nesne, aynı actor, aynı oturum).

• Rol tabanlı erişim ekleyin ve destek ekibi gibi test edin. Denetim verileri hassas alanlar içerebilir; bu yüzden rol bazlı filtreleme ve maskelenmiş değerler ekleyin.

AppMaster içinde inşa ediyorsanız, denetim tablolarını Data Designer'da modelleyin, karar noktalarında İş Süreci Düzenleyicisinden olay yayınlayın ve UI oluşturucularla zaman çizelgesini yan yana render edin.

Yayınlamadan önce gerçek bir senaryo çalıştırın: bir yönetici bir sipariş tutarının değiştiğini raporlasın. Destek, sadece zaman çizelgesi ekranını kullanarak hangi alanın değiştiğini, hangi IP ve kullanıcıyla yapıldığını, hangi iş akışı adımının tetiklendiğini ve neden (veya “sebep yok”) görüyor olmalı.

Birleşik zaman çizelgelerini işe yaramaz yapan yaygın hatalar

Birleşik zaman çizelgesi, insanların ona güvenmesi ve hızlı okuyabilmesi durumunda işe yarar. Çoğu zaman çizelgesi öngörülebilir hatalar yüzünden başarısız olur.

Aşırı kayıt ilk hatadır. Her sayfa görüntüleme, fareyle üzerinde gezinme ve otomatik kaydetme bir olay olursa, önemli anlar kaybolur. Zaman çizelgesini durumu, erişimi veya sonucu değiştiren eylemlerle sınırlayın. Yüksek hacimli teknik günlükler gerekiyorsa, bunları ayrı tutun ve içsel olarak event ID ile bağlayın.

Az kayıt da aynı şekilde kötüdür. “Kayıt güncellendi” gibi actor, hedef veya net sonuç içermeyen bir giriş kimseye yardımcı olmaz. Her olay kim yaptı, neye müdahale etti, ne zaman oldu ve ne değişti bilgilerini içermelidir. Ürününüz sebep istiyorsa (veya onay gerektiriyorsa), bu bağlamı olayın üzerine kaydedin; ayrı bir sistemde saklamayın ki soruşturma sırasında erişilemesin.

Değiştirilebilir günlükler güveni yok eder. Yöneticiler denetim olaylarını düzenleyebiliyorsa artık bir denetim izi değil, notlar vardır. Denetim olaylarını append-only tutun. Yanlış kaydedildiyse, düzeltmeyi açıklayan yeni bir olay yazın.

Tutarsız fiiller filtrelemeyi ve taramayı zorlaştırır. Aynı eylem için “Updated”, “Changed” ve “Edited” üç farklı olay türü olmamalıdır. Küçük bir fiil seti seçin ve ona sadık kalın: örn. created, updated, deleted, approved, rejected, logged_in, permission_changed.

Son olarak, hassas verileri sızdırmayın. Ham difflar şifreler, tokenlar, kişisel veriler veya ödeme bilgileri içerebilir. Yalnızca gerekeni saklayın, hassas alanları maskelenmiş tutun ve belirli izne sahip olmayanlar için bazı detayları gizleyin. Örneğin “Telefon numarası değişti” gösterin ama eski ve yeni değerleri yalnızca yetkili biri görsün.

Göndermeden önce hızlı kontrol listesi

Zaman çizelgesini destek ve güvenlik gözünden test edin. Bir hassas kayıt seçin (örneğin müşteri ödemesi ayarı) ve sadece zaman çizelgesi ekranını kullanarak ne olduğunu açıklamaya çalışın.

Doğrulama soruları:

• Her zaman aktörü isimlendirebiliyor musunuz? Hassas kayıtlarda “yapan” bilgisi (kullanıcı, servis hesabı veya sistem), rol ve kullanılan kimlik doğrulama yöntemi (şifre, SSO, API anahtarı) gösterilmelidir.
• Ne değiştiyi kanıtlayabiliyor musunuz? Kilit alanlar için önce ve sonra değerlerini gösterin. Eğer değer çok hassassa maskelenmiş bir versiyon ve değişiklik olduğunu kanıtlayan bir hash gösterin.
• Bir eylemi uçtan uca takip edebiliyor musunuz? correlation_id giriş, UI eylemi, iş akışı adımları ve veritabanı yazmaları arasında bağlantı kurmalı.
• Destek doğru olayı hızlı bulabiliyor mu? Filtrelerin actor, hedef (kayıt türü ve ID), zaman aralığı ve sonuçlar (success, failed, denied) için çalıştığını doğrulayın.
• Denetim erişimi kontrollü ve dışa aktarmalar görünür mü? Denetim verilerini görüntüleyebilen ve dışa aktarabilenleri sınırlandırın; her görüntüleme/dışa aktarma işlemini kendi olayı olarak kaydedin (kim, ne zaman, ne dışa aktarıldı).

Basit bir son test: zaman çizelgesini yapmayan birine verin ve “Bu kayıt neden 15:12'de değişmiş?” diye sorun. 60 saniyede cevap veremiyorsa muhtemelen daha fazla bağlam alanı eklemelisiniz (reason, request ID, onay veya hata detayları).

Örnek: şüpheli bir değişikliği dakikalar içinde soruşturma

Bir destek müdürü size şöyle der: “Acme Corp müşteri kaydı yanlış görünüyor. Fatura e-postası değişti ve müşteri ekibinden kimse yapmadığını söylüyor.” Müşteri ID'si için birleşik zaman çizelgesini açarsınız.

Tüm ilgili olaylar aynı correlation_id paylaştığı için zincir nettir.

Önce bir giriş görürsünüz: Sam (satış temsilcisi) 09:12'de yeni bir cihazdan ve alışılmadık bir konumdan giriş yapmış. Oturum bloğu IP, user agent ve MFA durumunu içerir. İki dakika sonra “Müşteri kaydını görüntüleme” ve ardından “Müşteri kaydını düzenleme” olayları görünür.

Kayıt güncelleme olayı okunması kolaydır. Tam alan değişikliklerini (fatura e-postası eski -> yeni) ve kaynağı (web uygulama) listeler. Hemen altında reason_code olarak Customer requested update görünür, fakat not boş olabilir.

Ardından iş akışı girdileri neler olduğuna açıklık getirir. Bir otomasyon kuralı çalışmış: “Fatura e-postası değişirse finansı bilgilendir ve onay gerektir.” Zaman çizelgesi bekleyen bir onay adımını, ardından 09:18'de Dana (takım lideri) tarafından “CASE-4812’e istinaden onaylandı” şeklinde kısa bir notla onaylandı bilgisini gösterir.

Destek tahminde bulunmadan vakayı çözebilir:

• Aktörü doğrula: Sam'in girişi şüpheli görünüyor (yeni cihaz, not yok), Sam'in oturumu ona ait mi teyit et.
• Niyeti onayla: Dana'nın onay notu bir bilet numarası gösteriyorsa biletin varlığını doğrula; yoksa bu bir kırmızı bayraktır.
• Güvenli biçimde geri al: Eski e-postayı geri yükleyen düzeltme olayı oluşturun ve zorunlu bir sebep isteyin: “Şüpheli hesap kötüye kullanımı nedeniyle geri alındı.”
• Sonucu belgeleyin: Aynı correlation_id ile bir vaka notu ekleyin ki gelecekteki incelemeler tam hikâyeyi görsün.

Sonraki adımlar: güvenli açılım ve sürdürülebilirlik

Birleşik denetim zaman çizelgesi ancak insanlar ona güvendiğinde faydalıdır. İlk sürümü bir nice-to-have değil, bir güvenlik sistemi olarak ele alın.

Saklama, arama hızı ve maliyet için net hedefler belirleyin. Birçok ekip basit bir yaklaşım kullanır: 90 gün “sıcak” (hızlı), 1-2 yıl “ılık” (daha yavaş) ve daha uzun süreli arşivler.

Göndermeden önce “hızlı”nın ne demek olduğunu tanımlayın. Zaman çizelgesi tipik bir kayıt için 2 saniyenin altında açılmalıysa buna göre plan yapın: (target_type, target_id, occurred_at) ile indeksleyin, yükleri küçük tutun ve eski satırları arşivleyin.

Küçük adımlarla yayınlayın ki görünüm temiz ve veriler tutarlı kalsın:

• Gerçek soruşturmaları kapsayan 5-8 olay türü ile UI prototipi yapın.
• Daha fazla olay hacmi eklemeden önce saklama ve arşivleme kurallarını belirleyin.
• Temel arama ve filtreleri (actor, tarih aralığı, olay türü) ekleyin.
• Gerçek vakalara karşı doğrulayın: “Destek bu değişikliğin neden olduğunu söyleyebiliyor mu?”
• Ana görünüm güvenilir olduktan sonra olay türlerini genişletin.

Dışa aktarma ve raporlama caziptir, ama hataları çoğaltır. Ekran üzerindeki zaman çizelgesi güvenli ve olay isimleri ile bağlam stabil olana kadar dışa aktarmaları erteleyin. Dışa aktarmalar erişim kurallarına uymalı, zaman dilimini ve kullanılan filtreleri içermeli ve değiştirilmeye karşı kanıtlayıcı bir kimlik (export ID) eklemelidir.

Rolleri erken planlayın; denetim verileri genellikle hassas detaylar içerir:

• Zaman çizelgesini görüntüleme (kayıtla çalışan çoğu personel)
• Dışa aktarma (liderler veya uyumluluk yetkilileri ile sınırlı)
• Ham yükleri görüntüleme (güvenlik, mühendislik veya yalnızca yöneticiler)
• Saklama politikalarını yönetme (yalnızca yöneticiler)

AppMaster ile inşa ediyorsanız, Data Designer'da şemayı eşleyin, Business Processes’ten olay yayınlayın ve aynı noktada zaten kural uyguladığınız yerde denetim olaylarını tetikleyin. Bu, web ve mobil arasında “kim ne yaptı, ne zaman ve neden” tutarlılığını korur ve iş akışları gelişirken bakımı kolaylaştırır.