POWER APPS’TE VERİ DOĞRULAMA: HATALARI AZALTAN FORM YAKLAŞIMI

Kurumsal bir uygulamada en pahalı hata türlerinden biri, sisteme yanlış girilmiş ama doğruymuş gibi ilerlemiş veridir. Power Apps ile hızlı geliştirme yaparken bu risk daha görünür hale gelir: form hızla ayağa kalkar, kullanıcı sayısı artar ve “küçük” doğrulama eksikleri kısa sürede operasyonel soruna dönüşür.

Bu makalede, Power Apps’te veri doğrulamayı yalnızca “zorunlu alan” düzeyinde değil, hataları en baştan yakalayan, kullanıcıyı doğru şekilde yönlendiren ve bakım maliyetini düşüren bir form yaklaşımı olarak ele alacağız. Amaç; veri kalitesini artırırken geliştirme ekibinin üzerinde birikmiş destek yükünü azaltmak.

Odak noktamız; Power Fx ile istemci tarafı kontroller, Dataverse/SharePoint gibi veri kaynaklarında kural katmanı, hata mesajı tasarımı, yeniden kullanılabilir doğrulama bileşenleri ve canlı ortamda izleme disiplinidir. Yazının sonunda, doğrulama kurgusunu standartlaştırmak için uygulanabilir bir kontrol listesi de bulacaksınız.

Power Apps’te veri doğrulama neden stratejik bir konudur?

Veri doğrulama çoğu ekipte “güzel olsa iyi olur” kategorisine itilir; çünkü ilk sürüm hedefi genellikle hızdır. Ancak üretimde işler değişir: hatalı e-posta formatları, boş bırakılan kritik alanlar, tutarsız tarih aralıkları veya yanlış kimlik numarası gibi problemler, raporlama katmanında patlar ve düzeltme maliyeti katlanır.

Doğrulama yaklaşımını stratejik yapan şey, yalnızca hata yakalaması değil; aynı zamanda iş kurallarını görünür kılmasıdır. Örneğin “teslim tarihi, talep tarihinden önce olamaz” kuralını formda ve veri katmanında uyumlu kurgulamak, hem kullanıcıyı yönlendirir hem de entegrasyonların güvenilirliğini artırır.

Hata türleri: biçim, tutarlılık ve iş kuralı

Pratikte doğrulama üç gruba ayrılır: biçim doğrulama (telefon, e-posta gibi), tutarlılık doğrulama (başlangıç-bitiş tarihleri, alt-üst limitler) ve iş kuralı doğrulama (onay akışına girebilme koşulları, rol bazlı zorunluluklar). Bu ayrım, form tasarımında hangi kontrolün nerede yapılacağını netleştirir.

Kurumsal etkiler: raporlama, entegrasyon, destek yükü

Hatalı verinin maliyeti sadece kullanıcıya “düzeltin” demek değildir. BI raporları yanlış karar üretebilir, otomasyon akışları başarısız olabilir, CRM/ERP entegrasyonları hatalı kayıtları yayabilir. Bu yüzden doğrulama; güvenilir veri, doğru rapor ve düşük operasyon maliyeti için temel bir yatırım gibidir.

Form yaklaşımı: doğrulama nerede yaşamalı?

Power Apps’te doğrulama kurgusunu tek bir yere yığmak çoğu zaman sürdürülebilir değildir. En iyi sonuç; istemci tarafında hızlı geri bildirim, kayıt anında kesin kontrol ve mümkünse veri katmanında kalıcı kural bileşimi ile alınır. Böylece kullanıcı hatayı anında görür, sistem hatalı kaydı engeller ve veri kaynağı da “son savunma hattı” olur.

EditForm, DataCard ve kontrol hiyerarşisi

Canvas uygulamalarında EditForm kullanıyorsanız, her alan bir DataCard içinde yaşar. Doğrulama mantığını DataCard düzeyinde toplamak, hem yeniden kullanım hem de okunabilirlik sağlar. Kartın DisplayMode, Required, Error ve Update alanlarını doğru kurgulamak; formun bütününde tutarlı davranış üretir.

Kuralın yeri: istemci, kayıt anı ve veri kaynağı

Hızlı geri bildirim için istemci doğrulaması (ör. alanın hemen altında hata) idealdir. Kayıt anında (SubmitForm veya Patch) kesin kontrol ise zorunludur. Veri kaynağı seviyesinde (Dataverse iş kuralları, zorunlu kolonlar, benzersiz alanlar) kurallar, dış sistemlerden gelen kayıtları da korur.

İstemci tarafı doğrulama: kullanıcıyı durdurmadan yönlendirin

İstemci tarafı doğrulama, kullanıcı deneyiminin en kritik parçasıdır. Burada amaç, kullanıcıyı her adımda bloklamak değil; yanlış girdiyi doğru şekilde açıklamak ve düzeltilmesini kolaylaştırmaktır. “Hata var” demek yerine, “Neyi, nasıl düzeltmeli?” sorusunu yanıtlayan mesajlar üretmelisiniz.

Zorunlu alanlar ve bağlamsal koşullar

Her alan her zaman zorunlu olmayabilir. Örneğin “Fatura Adresi”, “Teslimat Tipi = Kargo” seçildiğinde zorunlu olmalıdır. Bu tür koşullu doğrulamalar için DataCard.Required benzeri yaklaşımlar veya butonun DisplayMode kontrolü kullanılır. Böylece kullanıcı yalnızca ilgili durumda ek alan doldurur.

Biçim doğrulama: e-posta, telefon ve kimlik numarası

Biçim doğrulama için IsMatch, Match ve Substitute gibi fonksiyonlarla basit ama etkili kontroller yapılabilir. Burada hedef; gereksiz sert regex’lerle kullanıcıyı bezdirmek değil, bariz hataları yakalamaktır. E-posta için minimal bir desen, telefon için rakam uzunluğu ve ülke formatı gibi pragmatik kurallar tercih edin.

// Kaydet butonunu yalnızca geçerli form durumunda etkinleştirme (Power Fx)
btnKaydet.DisplayMode =
If(
    IsBlank(txtAdSoyad.Text) ||
    !IsMatch(txtEposta.Text, "^[^\s@]+@[^\s@]+\.[^\s@]+$") ||
    dtBaslangic.SelectedDate > dtBitis.SelectedDate,
    DisplayMode.Disabled,
    DisplayMode.Edit
);

// Alan bazlı hata mesajı (örnek: e-posta)
lblEpostaHata.Visible = !IsBlank(txtEposta.Text) && !IsMatch(txtEposta.Text, "^[^\s@]+@[^\s@]+\.[^\s@]+$");
lblEpostaHata.Text = "E-posta biçimi geçersiz. Örnek: ad.soyad@firma.com";

Tutarlılık doğrulama: alanlar arası ilişkileri güvence altına alın

Kurumsal formlarda hataların önemli bir kısmı alanlar arası tutarsızlıktan gelir. Tarih aralıkları, min-max limitler, birbirine bağlı seçim listeleri, departman-proje eşleşmesi gibi ilişkiler; yalnızca tek alan kontrolüyle yakalanamaz. Bu yüzden doğrulama kurgusu, formun veri modelini “hikaye gibi” okuyan bir mantıkla kurulmalıdır.

Tarih aralıkları ve sayısal limitler

Başlangıç ve bitiş tarihi gibi alanlarda, seçimi daha yapılırken kullanıcıyı yönlendirebilirsiniz. Örneğin bitiş tarihini başlangıçtan önce seçmeyi engellemek için tarih seçicide MinDate/MaxDate kısıtları ve ek hata mesajı birlikte kullanılabilir. Sayısal alanlarda Value() dönüşümü ve IsNumeric kontrolü ile veri tipi hataları azaltılır.

Bağımlı seçimler ve iş akışı koşulları

“Ülke seçilmeden şehir seçilemez” veya “Maliyet merkezi seçilmeden onaya gönderilemez” gibi bağımlılıklar, kullanıcıyı doğru sıraya yönlendirmelidir. Dropdown bileşenlerinde Items ve DisplayMode kontrolleriyle seçim sırası doğal şekilde yönetilebilir. Ayrıca koşul sağlanmadığında ilgili alanı görünmez yapmak yerine, nedenini açıklamak çoğu zaman daha iyi bir deneyim üretir.

Hata mesajı tasarımı: teknik değil, anlaşılır dil

Doğrulama yalnızca doğru/yanlış değildir; iletişimdir. Hata mesajı kötü tasarlanmışsa kullanıcı tekrar tekrar aynı hatayı yapar ve destek ekibine ulaşır. Hedef; kısa, net ve eylem odaklı mesajlar üretmektir. “Geçersiz değer” yerine “0–100 aralığında bir oran girin” demek gibi.

Alan altında mesaj, form üstü özet ve bildirim dengesi

En etkili yöntem çoğu zaman alanın hemen altında mesaj göstermektir. Buna ek olarak, formun üst kısmında “3 alan eksik” gibi bir özet kullanıcıyı hızlandırabilir. Toast/Notify mesajları ise kritik durumlarda (kayıt başarısız, yetki yok) kullanılmalıdır. Her şey için Notify kullanmak, kullanıcıyı mesaj yağmuruna tutar.

Görünürlük ve erişilebilirlik

Hata mesajları renk ile desteklenebilir ama yalnızca renge güvenmeyin. İkon, metin ve uygun boşluk ile mesaj okunabilir olmalıdır. Kurumsal uygulamalarda erişilebilirlik önemlidir; düşük kontrastlı etiketler veya çok küçük yazı, doğrulamanın etkisini düşürür. Mesaj dili kurum terminolojisine uyumlu olmalı, teknik terimler minimumda tutulmalıdır.

Kayıt anı doğrulaması: SubmitForm ve Patch senaryoları

İstemci tarafı doğrulama kullanıcıyı yönlendirir ama tek başına yeterli değildir. Kullanıcı internet bağlantısı sorunları yaşayabilir, başka ekranlar aynı kaynağa yazabilir veya aynı anda iki kişi aynı kaydı değiştirebilir. Bu nedenle kayıt anında, “son kontrol” katmanı şarttır.

Form doğrulaması ile veri kaynağı hatalarını ayırın

SubmitForm sonrası hata oluştuğunda, hatanın kaynağı her zaman kullanıcı girdisi değildir. Yetki, zorunlu kolon, benzersiz alan, ağ problemi gibi sebepler olabilir. Bu yüzden hata yönetimini; “doğrulama hatası” ve “sistem hatası” olarak ayırmak gerekir. Kullanıcı girdisini düzeltecek mesaj ile tekrar denemeyi önerecek mesaj aynı olmamalıdır.

Patch ile kontrollü kayıt ve hata yakalama

Patch daha esnek kontrol sunar; ancak hata yönetimini sizin kurgulamanız gerekir. Errors fonksiyonu ve IfError ile birlikte, kullanıcıya anlaşılır geri bildirim verip kayıt akışını güvenli hale getirebilirsiniz. Kritik alanlarda, benzersizlik kontrolü gibi ön doğrulamaları da Patch öncesi yapabilirsiniz.

// Patch ile kayıt ve hata yakalama (Power Fx)
Set(varKayıtSonucu,
    IfError(
        Patch(
            Talepler,
            If(IsBlank(varSeciliKayit), Defaults(Talepler), varSeciliKayit),
            {
                Baslik: txtBaslik.Text,
                TalepSahibi: User().Email,
                BaslangicTarihi: dtBaslangic.SelectedDate,
                BitisTarihi: dtBitis.SelectedDate,
                Oncelik: ddOncelik.Selected.Value
            }
        ),
        Blank()
    )
);

If(
    IsBlank(varKayıtSonucu),
    Notify("Kayıt oluşturulamadı. Zorunlu alanları kontrol edin veya daha sonra tekrar deneyin.", NotificationType.Error),
    Notify("Kayıt başarıyla kaydedildi.", NotificationType.Success)
);

// Veri kaynağı hatasını detaylı incelemek için
// First(Errors(Talepler, varKayıtSonucu)).Message

Dataverse ve yönetişim: kalıcı kurallar olmadan güven olmaz

Canvas uygulaması, kullanıcı arayüzünü kontrol eder; ancak veri katmanı, kurumsal güvenliği sağlar. Eğer birden fazla uygulama aynı tabloya yazıyorsa veya Power Automate, API entegrasyonları devreye giriyorsa; yalnızca istemci doğrulamasına güvenmek risklidir. Dataverse kullanıyorsanız iş kuralları, zorunlu kolonlar, benzersiz anahtarlar ve alan türleriyle güçlü bir temel kurabilirsiniz.

İş kuralları, zorunlu alanlar ve benzersiz alanlar

Dataverse iş kuralları; form üzerinde ve sunucu tarafında çalışabilen kurgular sunar. Zorunlu kolonlar ve veri tipleri, hatalı kayıtların içeri girmesini engeller. Benzersiz alanlar (ör. talep numarası) için unique constraint yaklaşımı, mükerrer kayıtların önüne geçer. Bu kurallar, uygulama değişse bile veri kalitesini korur.

Rol bazlı doğrulama ve güvenlik

Bazı alanlar yalnızca belirli rollere açık olabilir. Örneğin “Onay Durumu” sadece yöneticiler tarafından değiştirilmeli. Bu durumda doğrulama sadece UI’da değil; güvenlik rolü, alan düzeyi güvenlik ve iş kurallarıyla birlikte düşünülmelidir. Böylece kullanıcı arayüzü atlatılsa bile sistem yanlış güncellemeyi kabul etmez.

Yeniden kullanılabilir doğrulama tasarımı: bileşenleştirin

Kurumsal ölçekte uygulama sayısı arttıkça, doğrulama kurallarını her ekranda tekrar yazmak kaçınılmaz şekilde tutarsızlık üretir. Aynı e-posta doğrulamasının farklı ekranlarda farklı regex’lerle yapılması gibi. Bu yüzden doğrulama yaklaşımını bileşen, fonksiyon benzeri pattern’ler ve standart mesaj sözlüğü ile yönetmek, sürdürülebilirlik açısından kritiktir.

Doğrulama yardımcıları ve mesaj sözlüğü

Canvas uygulamalarında “fonksiyon” yazamasanız da, yardımcı formülleri tek bir yerde tanımlayıp tekrar kullanabilirsiniz. Örneğin App.OnStart veya Screen.OnVisible içinde regex desenlerini, mesaj şablonlarını ve limitleri değişkenlere atayabilirsiniz. Mesajların merkezi bir sözlükte olması, metin tutarlılığı ve çeviri ihtiyaçları için avantaj sağlar.

Component Library ile standart alan bileşenleri

Component Library kullanarak “standart metin alanı”, “standart tarih aralığı” gibi bileşenler oluşturabilirsiniz. Bu bileşenlerin içine doğrulama mantığını ve hata gösterimini koyduğunuzda, yeni ekranlarda aynı davranışı otomatik elde edersiniz. Ayrıca stil, boşluk, ikon ve mesaj düzeni de standartlaşır; tasarım borcu büyümez.

Test, izleme ve iyileştirme: doğrulama yaşayan bir sistemdir

Doğrulama kurgusu “yapıldı bitti” değildir. İş kuralları değişir, yeni kullanıcı profilleri gelir, entegrasyonlar genişler. Bu yüzden doğrulama hatalarını ölçmek, hangi alanlarda kullanıcıların zorlandığını görmek ve sık karşılaşılan hataları daha erken yakalamak gerekir.

UAT senaryoları ve negatif test listeleri

Test planına negatif senaryoları dahil edin: boş değer, aşırı uzun metin, hatalı format, tarih çakışması, aynı kaydın eş zamanlı güncellenmesi. UAT sırasında kullanıcıların en çok takıldığı noktalar genellikle mesaj dilinin net olmaması veya doğrulamanın geç çalışmasıdır. Bu geri bildirimleri sürüme dahil etmek, üretim sonrası destek yükünü ciddi azaltır.

Telemetri, hata kayıtları ve ALM disiplini

Canlı ortamda başarısız kayıt denemeleri, hata mesajları ve performans sorunları izlenebilir olmalıdır. Power Platform yönetim araçları, ortam stratejisi ve çözüm (Solution) bazlı ALM yaklaşımı; doğrulama değişikliklerini kontrollü şekilde yayına almanızı sağlar. Böylece bir ekranda yapılan küçük bir değişiklik, diğer ekranların davranışını bozmaz.

Uygulanabilir kontrol listesi: hataları azaltan form standardı

Aşağıdaki maddeler, Power Apps’te veri doğrulama yaklaşımını standartlaştırmak için pratik bir başlangıç sağlar. Her projede aynı kalıpları uygulamak; kaliteyi yükseltirken yeni ekran geliştirme hızını da artırır.

• Zorunlu alanlar yalnızca iş ihtiyacı varsa tanımlanır; koşullu zorunluluklar netleştirilir.
• Biçim kontrolleri (e-posta, telefon) için tek bir desen ve tek bir mesaj standardı kullanılır.
• Alanlar arası tutarlılık (tarih aralığı, limit) hem UI’da hem kayıt anında doğrulanır.
• Hata mesajları kısa, eylem odaklı ve kurum terminolojisine uygun yazılır.
• Submit/Patch hataları “kullanıcı girdisi” ve “sistem hatası” olarak ayrıştırılır.
• Dataverse tarafında zorunlu kolon, benzersizlik ve iş kurallarıyla kalıcı güvenlik sağlanır.
• Ortak doğrulamalar bileşenleştirilir; kopyala-yapıştır mantığı azaltılır.
• Negatif test senaryoları UAT planına eklenir; üretim sonrası verilerle iyileştirme yapılır.

Bu yaklaşımı daha hızlı uygulamak ve ekip içinde ortak standart oluşturmak için Power Apps eğitimi içeriğimizde form tasarımı, Power Fx pratikleri, Dataverse kuralları ve ALM disiplinini uçtan uca ele alıyoruz.