Kayıt talep portalı: işe yarayan gizlilik kontrolleri

Kayıt talepleri neden kontrollü bir sürece ihtiyaç duyar?

Bir kayıt talebi basit görünebilir: Biri bir belge ister, bir personel belgeyi bulur ve belge gönderilir. Gerçekte her talep birkaç karar içerir. Personelin talebi kaydetmesi, talebi kimin yaptığını doğrulaması, bu kişinin hangi kayıtları alabileceğini kontrol etmesi, doğru dosyaları bulması, bir son tarih belirlemesi ve teslimatın nasıl yapıldığını kaydetmesi gerekir.

Kontrollü bir kayıt talep portalı bu adımları tek yerde toplar. Talepler; alındı, kimlik kontrolü gerekiyor, inceleniyor, teslimata hazır, teslim edildi ve kapatıldı gibi net durumlardan geçer. Bir vakaya atanan herkes, eski mesajları aramadan sorumlusunu, son tarihini ve sıradaki işlemi görebilir.

E-posta kutuları bu zinciri kolayca koparır. Bir talep ortak bir posta kutusuna ulaşabilir, iki kişiye yönlendirilebilir ve herkes diğerinin ilgilendiğini düşündüğü için yanıtsız kalabilir. E-tablolar adları ve tarihleri listeler, ancak genellikle tüm geçmişi göstermez: Personel hangi dosyaları kontrol etti, kimlik doğrulandı mı veya talep sahibi kayıtları aldı mı?

Kimlik ve erişim birbirinden ayrı kontrollerdir. Bir kişi kimliğini kanıtlayabilir, ancak kendisiyle bağlantılı her kaydı alma iznine sahip olmayabilir. Örneğin bir ebeveyn çocuğunun okul dosyasını isteyebilir. Personelin ebeveynlik yetkisini doğrulaması ve bir belgede paylaşım kısıtlaması olup olmadığını kontrol etmesi gerekebilir. Portal, hassas kanıt belgelerini birçok personelin görebildiği bir talep notuna koymadan her kararı kaydetmelidir.

Net durum etiketleri, ilk yanıttan sonra taleplerin kaybolmasını da önler. Bir personel daha fazla bilgi isterse, "açık" yerine "talep sahibi bekleniyor" gösterin. Personel kayıtları bulmuş ancak bir incelemecinin paylaşımı onaylaması gerekiyorsa, "onay bekleniyor" durumunu kullanın. Bu ayrımlar işin nerede durduğunu gösterir ve yöneticilerin geciken vakaları erken fark etmesine yardımcı olur.

AppMaster gibi kodsuz bir araç, bu süreci talep formu, personel kuyruğu, role dayalı görünümler ve son tarih hatırlatıcıları içeren bir uygulamaya dönüştürebilir. Her talebin tek bir sorumlusu, kaydedilmiş bir karar yolu ve personelin daha sonra bulabileceği bir teslimat kaydı olmalıdır.

Kimin kayıt talep edebileceğine ve kayıtlara erişebileceğine karar verin

Formu oluşturmadan önce net sınırlar belirleyin. Talep gönderebilecek grupları tanımlayın: kayıtta adı geçen kişi, izin verilen durumlarda ebeveyn veya yasal vasi, bir kuruluş adına hareket eden çalışan ya da yetkili temsilci. Her grubun kendine özgü kanıt kuralları ve talep seçenekleri olmalıdır.

Her personele aynı görünümü vermeyin. Gerçek sürece uygun roller atayın. Talep alma personeli formun eksiksiz olup olmadığını kontrol eder ve talebi doğru ekibe yönlendirir. İnceleme personeli kayıtları bulur ve talep sahibinin almaması gereken bölümleri çıkarır. Onay sorumluları kısıtlı, hukuki veya son derece hassas dosyaları ele alır. Teslimat personeli onaylanan kayıtları gönderir ve alıcının bunları aldığını doğrular.

Küçük bir ekipte bir kişi birden fazla görevi üstlenebilir, ancak portal yine de hangi görevi gerçekleştirdiğini kaydetmelidir. Bu, sonraki incelemeleri çok kolaylaştırır.

Temsilciler için sınırlar belirleyin

Bir temsilci yalnızca başka birinin adını yazarak erişim kazanmamalıdır. İmzalı yetki belgesi, vasilik belgesi veya şirket yetkilendirmesi gibi talebe uygun kanıtlar isteyin. Personel belgenin güncel olduğunu, doğru kişiyi belirttiğini ve istenen kayıt türüne izin verdiğini kontrol etmelidir.

Temsilci erişimi için bir sona erme tarihi belirleyin. Örneğin bir avukatın tek bir dava için fatura kayıtlarını isteme izni olabilir, ancak bu izin tüm kayıt kategorilerini süresiz olarak açmamalıdır. Yetki süresi dolduğunda veya talep değiştiğinde portal yeni bir onay isteyebilir.

Hassas kategorilere erişimi kısıtlayın

Bazı kayıtlar, sıradan hesap bilgilerinden daha sıkı erişim kuralları gerektirir. Sağlık bilgileri, ödeme ayrıntıları, disiplin dosyaları, devlet tarafından verilen kimlik bilgileri ve başka bir kişiyi ilgilendiren kayıtlar için ayrı kurallar oluşturun. Talep alma personeli talebi görebilir, ancak asıl dosyayı yalnızca atanmış bir incelemeci açabilir.

Bir yönetici rolü değiştirdiğinde, geçici erişim verdiğinde, bir temsilciyi onayladığında veya bir kısıtlamayı kaldırdığında denetim kaydı oluşturun. Personeli, zamanı, nedeni ve etkilenen talebi kaydedin. Bir müşteri daha sonra gizlilik endişesi dile getirirse bu geçmiş, kimin neden erişim sahibi olduğunu açıklar.

Personelin ihtiyaç duyduğu bilgileri toplayan bir talep formu tasarlayın

Bir kayıt talep portalı, gereksiz kişisel veriler için bir toplama noktasına dönüşmeden personelin doğru dosyayı bulmasına yardımcı olmalıdır. Her alanın bir amacı olmalı: talep sahibini tanımlamak, kayıtları bulmak, izni doğrulamak veya yanıtı göndermek.

Aramayı daraltabilecek en küçük ayrıntı grubuyla başlayın. Bir müşteri hesabı kaydı talebi için kişinin tam adı, doğum tarihi veya hesap numarası, kayıt türü ve tarih aralığı yeterli olabilir. Personel mevcut müşteri kimliğiyle hesabı bulabiliyorsa tam ev adresini istemeyin.

Açık etiketler kullanın ve hassas bilgileri neden istediğinizi açıklayın. "Hesap numarası (biliyorsanız)" ifadesi, "Referans" ifadesinden daha anlaşılırdır. İsteğe bağlı alanları açıkça belirtin. Personel bir bilgi olmadan talebi işleme alamıyorsa bu alanı zorunlu yapın ve "Kayıt sahibinin doğum tarihini girin" gibi özel bir mesaj gösterin.

Yetkiyi doğrulamak için yeterli bilgi toplayın

Talep sahibinin kayıtlarda adı geçen kişiyle ilişkisini sorun. Basit bir seçenek listesi bunu netleştirir:

• Kendi kayıtlarımı istiyorum
• Ebeveyn veya yasal vasi benim
• Kayıt sahibinden yazılı izin aldım
• Bir kuruluşu veya mirası temsil ediyorum

Bir kişi başka biri adına kayıt istediğinde kayıt sahibinin adını ve personelin incelemesi için gereken yetki ayrıntılarını toplayın. Portal imzalı bir onay formu veya yasal yetki kanıtı isteyebilir, ancak ilgisiz kişisel bilgiler talep etmemelidir. Personelin yetkiyi kabul ettiğini, reddettiğini veya daha fazla kanıta ihtiyaç duyduğunu kaydedebileceği bir alan ekleyin.

Güncellemeler ve teslimat için talep sahiplerinden e-posta veya telefon gibi bir iletişim yöntemi seçmelerini isteyin. Talebin varlığını ortaya çıkaran bir durum güncellemesi göndermeden önce iletişim bilgilerinin talep sahibine ait olduğunu doğrulayın.

Kimlik belgelerini dikkatle kabul edin

Kimlik doğrulama çoğu zaman dosya yüklemeyi gerektirir, ancak yüklemeler gizlilik riski yaratır. Kabul edilen dosya türlerini sınırlandırın, makul bir boyut sınırı belirleyin ve personelin tam olarak hangi belgeleri kabul ettiğini açıklayın. Bazı durumlarda resmi kimlik fotoğrafı uygun olabilir. Başka durumlarda daha az hassas bir belge veya mevcut hesap üzerinden doğrulama yeterlidir.

Kimlik yüklemelerini genel eklerden ayrı tutun. Bunları "Personel incelemesi için kimlik belgesi" olarak etiketleyin ve personelin bunları yalnızca talebi doğrulamak için kullandığını belirtin. İnsanlardan kimlik belgelerini normal e-posta ile göndermelerini istemeyin.

AppMaster bu iş akışını zorunlu alanlar, koşullu bölümler ve kısıtlı personel görünümüyle destekleyebilir. Örneğin "Yazılı iznim var" seçildiğinde onay yükleme alanı açılabilir. Kişisel kayıt talebinde ise yalnızca o talep türü için gereken kimlik kontrolü gösterilebilir.

Talep iş akışını kurun

Bir kayıt talep portalının başvurudan teslimata kadar net bir yolu olmalıdır. Personel, e-postaları, e-tabloları veya özel sohbetleri açmadan her talebin mevcut durumunu görebilmelidir. İş akışını insanların tutarlı biçimde kullanabileceği kadar basit tutun.

Küçük bir durum kümesiyle başlayın. Talep Alındı durumuyla başlar, ardından talebi kimin gönderdiği doğrulanırken Kimlik incelemesi durumuna geçer. Atanan kişi ilgili kayıtları bulurken Aranıyor durumunu kullanın. Bir yönetici veya gizlilik sorumlusu yanıtı kontrol edecekse Onay durumunu, personel dosyaları veya mesajı hazırladığında Hazır durumunu, talep sahibi aldıktan sonra da Teslim edildi durumunu kullanın.

Her durumun bir sorumlusu ve net bir işlemi olmalıdır. Kimlik doğrulamasını tamamlayan çalışan talebi Aranıyor durumuna taşıyabilir ve kayıtları bulabilecek kişiye atayabilir. Böylece herkes başka birinin ilgilendiğini düşündüğü için talepler ortak kuyrukta beklemez.

Son tarihi, talep sahibi taslak formu başlattığında değil, personel talebi kabul ettiğinde belirleyin. Portal geciken talepleri önce gösterebilir ve tarih yaklaşmadan hatırlatmalar gönderebilir. Son tarihten yedi gün önce ve ardından iki gün önce gönderilecek hatırlatmalar, personele eksik kayıtları bulması veya onay alması için zaman verir.

İletişim için ayrı alanlar kullanın. Talep sahibine gösterilen mesaj "Kimliğinizi doğruladık ve kayıtlarınızı buluyoruz" diyebilir. Dahili notlarda eksik kimlik kontrolü, bulunamayan dosya konumu veya onay sorumlusunun talebi neden geri gönderdiği tutulabilir. Talep sahipleri bu notları hiçbir zaman görmemelidir.

Basit bir belge talep iş akışı beş adımdan oluşabilir:

1. Portal, alınan talebi oluşturur ve alındı onayı gönderir.
2. Adı belirlenmiş bir personel kimliği kontrol eder ve sonucu dahili notlara kaydeder.
3. Sorumlu kişi son tarihi belirler, kayıtları arar ve gerekiyorsa onay ister.
4. Onaylanan yanıt Hazır durumuna geçer, ardından personel seçilen güvenli teslimat yöntemiyle gönderir.
5. Sorumlu kişi talebi Teslim edildi olarak işaretler ve teslim tarihini kaydeder.

AppMaster ile ekip, Data Designer'da durumları modelleyebilir, görsel Business Process Editor'da mantık oluşturabilir ve sorumluluk, son tarihler ve teslimat durumları için bir personel paneli hazırlayabilir. Aynı portal, personel notlarını veya başkalarının kayıtlarını açığa çıkarmadan talep sahiplerine kendi taleplerinin sınırlı bir görünümünü sunabilir.

Kimlik kontrollerini gereksiz bilgi paylaşmadan yönetin

Kimlik kontrolleri, kaydın hassasiyetine uygun olmalıdır. Herkese açık bir belge için yapılan sıradan bir talepte yalnızca hesapla oturum açmak yeterli olabilir. Sağlık, finans, istihdam veya hesap kayıtları için yapılan taleplerde ise herhangi bir şey paylaşılmadan önce daha güçlü kanıt gerekir.

Portal yayına girmeden önce her talep türü için kabul edilen kimlik kurallarını belirleyin. Özel kayıt talep eden biri, resmi fotoğraflı kimlik ve müşteri numarası veya güncel adres gibi eşleşen bir hesap bilgisi sunabilir. Başkası adına hareket eden temsilci de yetki kanıtı sunmalıdır.

Personelin hangi kanıtları kabul ettiğini talep sayfasında açıkça belirtin. Kimliği doğrulamak için gereken en küçük kanıtı isteyin. Ad, doğum tarihi ve hesap bilgisi yeterliyse tam kimlik belgesi toplamayın.

Personele tek bir eşleştirme süreci sunun

Benzer taleplerin benzer biçimde ele alınması için personel aynı kontrol listesini kullanmalıdır. Liste; adın eşleştiğini, verilen bilgilerin mevcut kayıtla uyuştuğunu, kimliğin güncel olduğunu ve temsilcinin işlem yapma izni bulunduğunu doğrulamayı içerebilir.

Doğrulama işini incelenen belgelerden ayrı tutun. Doğrulama personeline kimlik kanıtına erişim verin, ancak talep edilen kayıtları kontrol onaylanana kadar kısıtlı tutun. Diğer personelin yalnızca "doğrulandı", "eksik" veya "başarısız" gibi basit bir durumu görmesi yeterlidir.

Başarısız bir kontrol için nedeni açık biçimde kaydedin: "Ad hesap kaydıyla eşleşmiyor" veya "Fotoğraflı kimliğin süresi dolmuş." Kimlik numaralarını, görselleri veya ek kişisel ayrıntıları genel personel notlarına kopyalamayın. Talep sahibine yeniden ne göndermesi gerektiğini açıklayan kısa bir mesaj gönderin.

Geçici dosyaları zamanında silin

Bir kişi doğrulama dosyası yüklediğinde sona erme tarihi belirleyin. Kısa bir saklama süresi, kontrol tamamlandıktan sonra maruziyeti sınırlar. Portal, bir yasa veya kurum içi politika daha uzun saklama gerektirmiyorsa süre dolduğunda dosyaları otomatik olarak silmelidir.

Her karar için bir denetim kaydı tutun. Personeli, tarihi ve saati, sonucu, talep referansını ve reddedilen taleplerin nedenini kaydedin. Yöneticiler özel belgeleri ekip genelinde görünür kılmadan net bir geçmişe erişebilir.

AppMaster, izinleri ve durum adımlarını görsel olarak modelleyebilir. Böylece kimlik kanıtı doğru personele yönlendirilirken talep edilen kayıtlar onay verilene kadar kilitli tutulur.

Son tarihleri ve teslimat durumunu takip edin

Bir kayıt talep portalındaki tek bir personel görünümü üç soruya yanıt vermelidir: Bunun son tarihi ne zaman, şu anda sorumlusu kim ve şimdiye kadar ne oldu? Her talebin üst kısmına son tarihi, mevcut sorumluyu ve durumu yerleştirin. Personel bu bilgileri bulmak için mesajları veya e-tabloları açmak zorunda kalmamalıdır.

Talebin gerçek durumunu anlatan etiketler kullanın. Personelin tüm kayıtları mı yoksa yalnızca bir kısmını mı gönderdiğini gizleyebilecek belirsiz bir "kapatıldı" etiketinden kaçının.

• Alındı: Portal talebi kaydetti, ancak personel incelemeye başlamadı.
• Kimlik kontrolü: Personelin talep sahibinin kimliğini doğrulaması gerekiyor.
• Kayıtlar toplanıyor: Atanan ekip belgeleri buluyor ve inceliyor.
• Talep sahibi veya departman bekleniyor: İlerleme başka birine bağlı.
• Kısmen teslim edildi: Personel bazı kayıtları gönderdi, diğerlerini göndermesi gerekiyor.
• Tamamlandı: Personel onaylanan son kayıtları teslim etti.

Talep sahibi fotoğraflı kimlik veya daha net bir tarih aralığı gibi bilgiler sağlarken son tarih sayacını duraklatın veya işaretleyin. Başka bir departmandan bilgi beklenirken geçen süreyi de kaydedin. Bu bekleme süreleri, birikmiş işin kayıt ekibinde mi yoksa başka bir yerde mi olduğunu gösterir.

Durum değiştiğinde sade bir dille güncelleme gönderin. Örneğin: "Kimliğinizi doğruladık ve şimdi istediğiniz kayıtları topluyoruz." Personel yalnızca bazı belgeleri teslim ederse bunu doğrudan söyleyin: "Şu anda mevcut olan kayıtları gönderdik. Kalan öğeleri hâlâ inceliyoruz ve 18 Mayıs'a kadar sizi bilgilendireceğiz." Dahili etiketleri, ekip adlarını veya talep sahibinin bilmesine gerek olmayan ayrıntıları kullanmayın.

Zaman çizelgesini eksiksiz tutun

Her talebin, personelin gelişigüzel üzerine yazamayacağı bir etkinlik geçmişi olmalıdır. İlk son tarihi, değiştirilmiş tüm tarihleri, değişikliği yapan kişiyi ve kısa nedeni kaydedin. "Talep sahibi kimliğini 4 Mayıs'ta gönderdi" ifadesi, "son tarih güncellendi" ifadesinden daha yararlıdır.

AppMaster'da oluşturulan kodsuz bir kayıt talep portalı, personel durumu kontrollü bir iş akışı üzerinden güncellerken bu geçmişi talep kaydının yanında gösterebilir. İş akışı sorumluları atayabilir, tarihleri hesaplayabilir ve personelin bilgileri araçlar arasında kopyalamasını gerektirmeden güncellemeler gönderebilir.

Personel bir talebi tamamlandı olarak işaretlemeden önce son bir teslimat kaydı girmesini zorunlu tutun. Teslim tarihini, yöntemi ve teslimatı doğrulayan personeli kaydedin. Bu kayıt, sonraki sorulara hızlı yanıt verir.

Örnek: Bir müşteri kayıtlarının kopyalarını istiyor

Eski bir müşteri olan Maya, kayıt talep portalını açar ve önceki yıla ait hesap belgelerini ister. Formda tam adı, hesapta kullandığı e-posta adresi, biliyorsa hesap referansı ve ihtiyaç duyduğu belge türleri sorulur. Faturaları ve imzalı hizmet kayıtlarını seçer.

Portal RR-1048 numaralı talebi oluşturur ve Maya'ya bir referans numarası verir. Talebi yalnızca kayıt ekibi görebilir. Personel ortak klasörlerde veya eski gelen kutularında arama yapmadan önce Maya'nın kayıtları alma hakkı olup olmadığını kontrol eder.

Bir personel gönderilen e-posta adresini hesap kaydıyla karşılaştırır ve bu adrese bir doğrulama mesajı gönderir. Maya kontrolü tamamlar. Portal tarihi, incelemeciyi ve sonucu kaydeder. Ekip artık Maya'nın kişisel bilgilerini dahili mesajlara kopyalamadan belgeleri arayabilir.

Aramada tüm faturalar bulunur, ancak imzalı hizmet kayıtlarından biri eksiktir. Çünkü talepte hizmet tarihi veya konumu yoktur. Personel ilgisiz belgeleri göndermek yerine durumu "Daha fazla bilgi gerekiyor" olarak değiştirir ve portal üzerinden kısa bir mesaj gönderir. Maya yaklaşık ayı ve hizmet konumunu yanıtlar.

Personel kalan kaydı iki gün sonra bulur. Son tarih, Maya'nın göremediği dahili notlarla birlikte görünür durumda kalır. Ekip, tamamlanan kısmı bekletmek yerine önce faturaları portalın korumalı teslimat alanı üzerinden gönderir. Maya kısmi teslimatın hazır olduğuna dair bildirim alır.

Talep "Kısmen teslim edildi" durumunda açık kalır. Personel imzalı hizmet kaydını yükledikten sonra ikinci bir teslimat bildirimi gönderir. Portal her dosyayı, teslim tarihini, alıcıyı ve paylaşımı onaylayan personeli kaydeder.

Teslimat süresi sona erdiğinde personel RR-1048'i kapatır. Son kayıt, kimlik doğrulamasının geçtiğini, personelin ek bilgi istediğini, iki teslimat gönderildiğini ve talebin belirli bir tarihte kapandığını gösterir. Denetim izi, ekibin neyi ve neden paylaştığını açıkça ortaya koyar.

Özel bilgileri açığa çıkaran yaygın hatalar

Bir kayıt talep portalındaki gizlilik ihlallerinin çoğu sıradan kestirme yollardan başlar. Bir personel hızlıca yardımcı olmak ister, ek dosyayı gönderir ve e-posta adresinin talep sahibine ait olduğunu varsayar. Yazım hatası, yönlendirilmiş bir mesaj veya ele geçirilmiş bir gelen kutusu, tüm kaydın yanlış kişiye açılmasına neden olabilir.

Bunun yerine kontrollü bir teslimat adımı kullanın. Portal, kimlik doğrulamasından sonra alıcıyı doğrulamalı, paylaşımı kimin onayladığını kaydetmeli ve talep sahibine dosyaları alabileceği korumalı bir alan sunmalıdır. Personel, talep sahibinin belgelere erişip erişmediği dahil teslimat durumunu görebilmelidir.

Her çalışana kimlik belgelerine erişim vermek başka bir sorun yaratır. Sürücü belgesi veya pasaport kopyası, talep özetinden çok daha hassastır. Erişimi kimlik doğrulamasını yapan küçük grupla sınırlayın ve diğer personele yalnızca "kimlik onaylandı" veya "daha fazla bilgi gerekiyor" gibi sonucu gösterin.

Birinin e-posta göndermesi veya sesli mesaj bırakması nedeniyle talebi kapatmayın. Personel sonucu doğrulamalıdır: Belgeler teslim edildi, talep geri çekildi, kimlik kontrolü başarısız oldu veya onaylanmış bir neden paylaşımı engelledi. Bu, talep sahibini korur ve bir anlaşmazlık çıkarsa net bir kayıt bırakır.

Belirsiz durumlar da gecikmelere yol açar. "Beklemede" ifadesi sırada ne olduğunu veya görevin kime ait olduğunu söylemez. Eylem ve sorumlu ile bağlantılı durumlar kullanın:

• Talep sahibinin kimlik bilgilerini sağlaması bekleniyor
• Kimlik kontrolü adı belirlenmiş bir personele atandı
• Kayıt aramasının son tarihi belirli bir tarih
• Paylaşım onay bekliyor
• Teslim edildi, teslim tarihi kaydedildi

Teslimattan sonra etkinlik geçmişini koruyun. Personel portalın talebi ne zaman aldığını, kimliğin kim tarafından kontrol edildiğini, hangi dosyaların paylaşıldığını ve talep sahibinin bunları nasıl aldığını göstermek zorunda kalabilir. Bu izi silmek takip işlemlerini zorlaştırır ve yanlışlıkla yapılan bir paylaşımı gizleyebilir.

AppMaster, ekiplerin bu gizlilik kontrollerini portala yerleştirmesine yardımcı olabilir. Görsel iş akışı araçları her adımı atayabilir, role göre erişimi kısıtlayabilir ve platform arka ucu ile kullanıcı arayüzünü oluştururken denetim geçmişini koruyabilir. Daha az kişisel veri toplayın, bu verileri daha az kişiye gösterin ve her paylaşım kararını kaydedin.

Yayına almadan önce hızlı kontroller

Portal gerçek belgelerle kullanılmadan önce gerçek kişisel veri içermeyen örnek bir taleple test edin. Bu yöntem, risk düşükken izin boşluklarını ve belirsiz görev geçişlerini ortaya çıkarır.

Formla başlayın. Her alan personelin talep sahibini tanımlamasına, kaydı bulmasına, yetkiyi doğrulamasına veya yanıtı göndermesine yardımcı olmalıdır. Bu görevlerden hiçbirini desteklemeyen alanları kaldırın. Bir hesap kaydı talebi için ad, hesap referansı, iletişim yöntemi ve istenen kayıt türü yeterli olabilir. Tam bir kişisel profile nadiren ihtiyaç vardır.

Bu yayına alma kontrol listesini kullanın:

• Personel talebi kabul ettiğinde her talebe adı belirlenmiş bir sorumlu ve son tarih atandığını doğrulayın.
• Bir personel test hesabıyla oturum açın ve hesabın yalnızca rolüne atanmış talepleri görüntüleyebildiğini, düzenleyebildiğini veya onaylayabildiğini kontrol edin.
• Yöneticilerin, asıl sorumlu görevde olmadığında talebi yeniden atayabildiğini kontrol edin.
• Talep geçmişinin durum değişikliklerini, kimlik kontrolü kararlarını, notları ve teslimat ayrıntılarını kaydettiğini doğrulayın.
• Geçmişi hem aktif hem de tamamlanmış bir talepten açın. Personel her ikisinde de aynı eksiksiz geçmişi bulabilmelidir.

Teslimat yolunu test edin

Teslimatı ayrı bir izin kontrolü olarak ele alın. Personel gerçek bir kayıt göndermeden önce talep sahibinin kimliğini, onaylanan teslimat kanalını ve alıcının adresini veya hesabını doğrulamalıdır. Doğru belgeyi yanlış e-posta adresine göndermek de gizlilik ihlalidir.

Sunmayı planladığınız her teslimat seçeneğini test edin. Portal güvenli indirme ve e-posta sağlıyorsa indirmenin yalnızca onaylanan talep sahibine ait olduğunu, e-posta bildirimlerinin hassas kayıt ayrıntılarını açığa çıkarmadığını doğrulayın. "Teslim edildi" gibi son bir durumu yalnızca personel onaylanan yöntemi tamamladıktan sonra kullanın.

Personel görünümünü kontrol edin

Portalın oluşturulmasında görev almayan bir personelden örnek bir talebi işlemesini isteyin. Bu kişi talebin kime ait olduğunu, son tarihini, hangi kimlik kanıtının kontrol edildiğini ve kayıtların teslim edilip edilmediğini görebilmelidir. Bu yanıtları bulmak için mesajları veya e-tabloları araması gerekiyorsa yayına almadan önce iş akışını düzeltin.

AppMaster ile ekipler bu kontrolleri talep verilerinde modelleyebilir, rol izinlerini belirleyebilir ve personel ekranlarını aynı talep geçmişi etrafında oluşturabilir. İlk sürümü basit tutun. Net sorumluluk, sınırlı erişim ve eksiksiz denetim izi, kalabalık bir yönetici ekranından daha önemlidir.

Portalı oluşturmak için sonraki adımlar

Müşterinin hesap kayıtlarını istediği durum gibi tek bir talep türüyle başlayın ve başka kategoriler eklemeden önce sürecin tamamını oluşturun. Kayıtları alan, inceleyen ve gönderen personelden erken aşamada test etmelerini isteyin. Eksik alanları ve belirsiz görev geçişlerini proje toplantılarından daha hızlı fark ederler.

Otomasyon eklemeden önce durum tanımlarını yazın. Her durum personele ne olduğunu, sonraki işlemin kime ait olduğunu ve talep sahibinin bu durumu görüp göremeyeceğini söylemelidir. "Kimlik kontrolü gerekiyor" personelin kimlik kanıtını incelemesi gerektiği anlamına gelir. "Teslimata hazır" ise kayıtların onaylandığı ve seçilen güvenli yöntemle gönderilebileceği anlamına gelir.

İlk durum kümesini basit tutun:

• Gönderildi: Portal talebi aldı.
• İnceleniyor: Personel talep ayrıntılarını ve izinleri kontrol ediyor.
• Kimlik kontrolü gerekiyor: Talep sahibi gerekli kanıtı sağlamalı.
• Kayıtlar hazırlanıyor: Personel belgeleri topluyor ve inceliyor.
• Teslim edildi veya kapatıldı: Personel kayıtları gönderdi ya da talebi neden karşılayamadığını kaydetti.

Gizlilik kurallarını kuruluşunuzda bu kurallardan sorumlu kişilerle birlikte inceleyin. Bu kişiler talep ayrıntılarını kimlerin görebileceğini, personelin hangi kimlik kanıtlarına ihtiyaç duyduğunu, portalın yüklenen dosyaları ne kadar süre saklayacağını ve hangi teslimat yöntemlerine izin verildiğini doğrulamalıdır. Bu kararları personelin hatırlamasına bırakmak yerine iş akışına yerleştirin.

Bir kayıt talep portalını AppMaster'da kodsuz bir uygulama olarak oluşturabilirsiniz. Talepleri, talep sahibi ayrıntılarını, kimlik kontrollerini, belgeleri ve durum geçmişini tanımlamak için Data Designer'ı kullanın. Talep formunu ve personel görünümlerini web arayüzü oluşturucusuyla hazırlayın. Ardından Business Processes ile işleri atayın, son tarihleri belirleyin, erişimi kısıtlayın ve durum mesajları gönderin. AppMaster, AppMaster Cloud, AWS, Azure, Google Cloud veya kendi ortamınızda dağıtılmak üzere arka ucu, web uygulamasını ve kaynak kodunu oluşturabilir.

Canlı gönderimleri kabul etmeden önce örnek taleplerle test yapın. Eksiksiz bir talep, eksik bilgileri olan bir talep, başarısız bir kimlik kontrolü ve son tarihini kaçıran bir talep ekleyin. Talep sahibinin her adımda ne gördüğünü kontrol edin, ardından personelin yalnızca rolünün gerektirdiği kayıtlara ve kişisel verilere erişebildiğini doğrulayın.

Yayına almadan önce kafa karıştıran bölümleri düzeltin. Personel, e-postalar veya ortak klasörler arasında arama yapmadan net bir belge talep iş akışını yürütebilmelidir.