Yönetici araçları için iyimser kilitleme: sessiz üzerine yazmaları önleyin

Sorun: birçok kişinin düzenlediği kayıtlarda sessiz üzerine yazmalar

“Sessiz üzerine yazma”, iki kişinin aynı kaydı açıp ikisinin de değişiklik yapmasıyla olur ve son kaydetme işlemini yapan kişi kazanır. İlk kişinin değişiklikleri uyarı olmadan kaybolur ve genellikle geri almak zordur.

Yoğun bir yönetici panelinde bu durum gün boyunca fark edilmeden yaşanabilir. İnsanlar birden fazla sekme açar, ticketlar arasında geçiş yapar ve 20 dakika boyunca açık kalan bir forma geri döner. Sonunda kaydettiklerinde, kaydı en son haliyle güncellemiyorlardır — üzerine yazmaktadırlar.

Bu durum kamuya açık uygulamalardan ziyade arka ofis araçlarında daha sık görülür çünkü işler işbirlikçi ve kayıt tabanlıdır. İç ekipler aynı müşteri, sipariş, ürün ve talepleri tekrar tekrar düzenler; kamu uygulamalarında daha çok “kullanıcı kendi verisini düzenler” senaryosu görülürken, yönetici araçları “birçok kullanıcı paylaşılan veriyi düzenler” şeklindedir.

Anlık zarar genellikle dramatik olmaz ama hızla birikir:

• Bir ürün fiyatı promosyon sonrası eski değere döner.
• Destek görevlisinin iç notu kaybolur, bir sonraki görevli aynı adımları tekrarlar.
• Sipariş durumu geriye döner (örneğin “Shipped” tekrar “Packed” olur) ve yanlış takip tetiklenir.
• Müşteri telefon numarası veya adresi eski bilgilerle değiştirilir.

Sessiz üzerine yazmalar üzücüdür çünkü herkes sistemin doğru kaydettiğini düşünür. "Bir şey yanlış gitti" anı yoktur; sadece raporlar tutarsız görünür veya bir ekip arkadaşı "Bunu kim değiştirdi?" diye sorduğunda karışıklık olur.

Böyle çatışmalar normaldir. Araç paylaşılıyor ve faydalı olduğu için olur; takımın işi yanlış yapması demek değildir. Amaç iki kişinin düzenlemesini tamamen engellemek değil, kaydın biri düzenlerken değişip değişmediğini tespit edip o anı güvenli şekilde ele almaktır.

Eğer AppMaster gibi no-code bir platformda dahili bir araç inşa ediyorsanız, bunu erken planlamak faydalıdır. Yönetici araçları hızla büyür ve ekipler bir kez bağımlı hale geldiğinde "bazen" veri kaybetmek güven sorununa dönüşür.

İyimser kilitleme sadece

İki kişi aynı kaydı açıp ikisi de Kaydet tuşuna bastığında, eşzamanlılık vardır. Her iki kişi de eski bir anlık görüntüden başlar, ama kaydetmeler olduğunda sadece biri “en son” olabilir.

Koruma yoksa son kaydetme kazanır. Bu, ikinci kaydın ilk kişinin değişikliklerini sessizce değiştirmesiyle sonuçlanır.

İyimser kilitleme basit bir kuraldır: “Kayıt, düzenlemeye başladığım halindeyse değişikliklerimi kaydedeceğim.” Kayıt arada değiştiyse, kaydetme reddedilir ve kullanıcı bir çatışma görür.

Bu, kimsenin düzenlediğini engelleyen pesimist kilitlemeden farklıdır. Pesimist kilitleme genelde sert kilitler, zaman aşımları ve insanların bloke olması demektir. Para transferi gibi hassas durumlarda işe yarayabilir ama gün boyunca birçok küçük düzenlemenin yapıldığı yoğun yönetici panolarında genelde sinir bozucudur.

İyimser kilitleme çoğunlukla daha iyi bir varsayılandır çünkü işi akıtmayı sürdürür. İnsanlar paralel çalışabilir ve sistem yalnızca gerçek bir çarpışma olduğunda devreye girer.

En iyi uyduğu durumlar:

• Çatışmalar mümkün ama sürekli değilse.
• Düzenlemeler hızlıysa (birkaç alan, kısa form).
• Başkalarını engellemek takımın yavaşlamasına neden olursa.
• "Biri güncelledi" mesajını açıkça gösterebiliyorsanız.
• API'niz her güncellemede bir sürüm (veya zaman damgası) kontrolü yapabiliyorsa.

Önlediği şey “sessiz üzerine yazma” problemidir. Veri kaybı yerine temiz bir durma: “Bu kayıt açtığınızdan beri değişti.”

Yapamayacağı şeyler de önemlidir. İki kişinin aynı eski bilgiye dayanarak farklı ama geçerli kararlar almasını engellemez ve değişiklikleri otomatik birleştirmez. Ayrıca kontrolü sunucu tarafında atlıyorsanız aslında hiçbir şey çözülmüş sayılmaz.

Ortak sınırlamalar:

• Çatışmaları otomatik çözmez (hala bir seçim gerekir).
• Kullanıcı çevrimdışı düzenleyip sonra senkronize ederse kontrol yoksa yardımcı olmaz.
• Kötü izinleri düzeltmez (birisi düzenleme yetkisine sahipse yine düzenleyebilir).
• Sadece istemcide kontrol yaparsanız çatışmaları yakalayamazsınız.

Pratikte iyimser kilitleme, düzenlemede eklenen bir "son görülen" belirteci ve sunucuda "sadece eşleşiyorsa güncelle" kuralından ibarettir. AppMaster ile bir yönetici paneli inşa ediyorsanız bu kontrol genellikle güncellemelerin yürütüldüğü iş mantığında (Business Process) bulunur.

İki yaygın yaklaşım: sürüm sütunu vs updated_at

Kullanıcı formu açıkken kaydın değişip değişmediğini tespit etmek için genelde iki sinyalden biri seçilir: bir sürüm numarası veya bir updated_at zaman damgası.

Yaklaşım 1: Sürüm sütunu (artan tam sayı)

Bir version alanı (genellikle tam sayı) ekleyin. Düzenleme formunu yüklediğinizde mevcut version da gelir. Kaydettiğinizde aynı değeri geri gönderirsiniz.

Güncelleme yalnızca saklı sürüm, kullanıcının başladığı değerle eşleşiyorsa başarılı olur. Eşleşiyorsa kaydı güncellersiniz ve versionu 1 artırırsınız. Eşleşmiyorsa üzerine yazmak yerine bir çatışma döndürürsünüz.

Bunu anlamak kolaydır: sürüm 12 demek “bu 12. değişiklik”. Ayrıca zamanla ilgili kenar durumlarını da engeller.

Yaklaşım 2: updated_at (zaman damgası karşılaştırması)

Çoğu tabloda zaten bir updated_at alanı vardır. Fikir aynı: form açıldığında updated_at okunur, kaydederken gönderilir; sunucu yalnızca updated_at değişmediyse günceller.

İyi çalışabilir, ama zaman damgalarının tuzakları vardır. Farklı veritabanları farklı hassasiyet saklayabilir. Bazıları saniyeye yuvarlar, hızlı düzenlemeleri kaçırabilir. Birden fazla sistem aynı veritabanına yazıyorsa saat kayması ve zaman dilimi sorunları kafa karıştırabilir.

Basit bir karşılaştırma şöyledir:

• Sürüm sütunu: en net davranış, veritabanları arası taşınabilir, saat problemi yok.
• updated_at: genellikle zaten mevcut olduğu için “bedava” olur, ama hassasiyet ve saat yönetimi sorun yaratabilir.

Çoğu ekip için öncelikli sinyal olarak bir sürüm sütunu daha iyidir. Açık, öngörülebilir ve loglarda veya destek kayıtlarında referans vermek kolaydır.

AppMaster'da bu genelde Data Designer'da bir version alanı eklemek ve güncelleme mantığınızın kaydetmeden önce bunu kontrol etmesini sağlamak anlamına gelir. Yine de denetleme için updated_at'ı tutabilirsiniz, ama hangi düzenlemenin güvenli olduğunu sürüm numarası belirlesin.

Her düzenleme ile ne saklanır ve ne gönderilir

İyimser kilitleme ancak her düzenleme, kullanıcının formu açtığı andaki “son görülen” işaretçiyi taşıdığında çalışır. Bu işaretçi version numarası veya updated_at zaman damgası olabilir. Onsuz sunucu kaydın düzenleme sırasında değişip değişmediğini anlayamaz.

Kayıt üzerinde normal iş alanlarınızın yanında sunucunun kontrol ettiği bir eşzamanlılık alanı olsun. Minimum set şöyle görünür:

• id (sabit tanımlayıcı)
• iş alanları (isim, durum, fiyat, notlar vb.)
• version (her başarılı güncellemede artan tam sayı) veya updated_at (sunucunun yazdığı zaman damgası)

Düzenleme ekranı yüklendiğinde form, o eşzamanlılık alanının son görülen değerini saklamalıdır. Kullanıcı bunu düzenlememeli; gizli bir alan veya form durumu olarak tutulmalı. Örnek: API version: 12 döner, form 12'yi kaydeder ve Kaydet'e kadar değişmez.

Kullanıcı Kaydet'e bastığında iki şeyi gönderin: değişiklikler ve son görülen işaretçi. En basit biçim, güncelleme istek gövdesine id, değişen alanlar ve expected_version (veya expected_updated_at) eklemektir. AppMaster'da UI inşa ediyorsanız bunu normal bir bağlı değer gibi ele alın: kaydı yükleyin, formda tutun ve güncellemeyle geri gönderin.

Sunucuda güncelleme koşullu olmalıdır. Eşleşiyorsa güncelleyin; eşleşmiyorsa sessizce birleştirmeyin.

Bir çatışma yanıtı açık ve UI tarafından kolay işlenebilir olmalıdır. Pratik bir çatışma yanıtı şunları içerir:

• HTTP durum 409 Conflict
• “Bu kayıt başka biri tarafından güncellendi.” gibi kısa bir mesaj
• mevcut sunucu değeri (current_version veya current_updated_at)
• isteğe bağlı olarak, UI'nın ne değiştiğini gösterebilmesi için mevcut sunucu kaydı

Örnek: Sam Müşteri kaydını sürüm 12'de açar. Priya değişiklik kaydeder ve sürüm 13 olur. Sam daha sonra expected_version: 12 ile Kaydet dener. Sunucu 409 döndürür ve sürüm 13'teki güncel kaydı gönderir. UI artık Sam'e Priya'nın değişikliklerini gözden geçirme şansı verir.

Uçtan uca iyimser kilitlemeyi uygulama adımları

İyimser kilitleme temelde bir kuraldır: her düzenleme, kaydın en son saklanan sürümüne dayandığını kanıtlamalıdır.

1) Bir eşzamanlılık alanı ekleyin

Her yazmada değişen bir alan seçin.

Özel bir tam sayı version en kolay anlaşılacak olandır. 1'den başlatın ve her güncellemede artırın. Güvenilir bir updated_at zaten varsa onu da kullanabilirsiniz; ama onun her yazmada güncellendiğinden (arka plan işleri dahil) emin olun.

2) Okumada bu değeri istemciye gönderin

UI düzenleme ekranını açtığında mevcut version (veya updated_at) yanıtın içinde gelsin. Bunu form durumunda gizli bir değer olarak saklayın.

Bunu bir fiş gibi düşünün: “Ben son okuduğum şeye göre düzenliyorum.”

3) Güncellemede bu değeri zorunlu kılın

Kaydette istemci düzenlenen alanlar ile birlikte son görülen eşzamanlılık değerini gönderir.

Sunucuda güncelleme koşullu olmalıdır. SQL terimleriyle:

UPDATE tickets
SET status = $1,
    version = version + 1
WHERE id = $2
  AND version = $3;

Güncelleme 1 satır etkiliyorsa kaydetme başarılıdır. 0 satır etkileniyorsa birisi zaten kaydı değiştirmiş demektir.

4) Başarı sonrası yeni değeri döndürün

Başarılı kaydın ardından güncellenmiş kaydı ve yeni version (veya yeni updated_at) değerini döndürün. İstemci form durumunu sunucudan gelenle değiştirsin. Bu, eski sürümle çift kaydetmeyi engeller.

5) Çatışmaları normal bir sonuç olarak ele alın

Koşullu güncelleme başarısız olursa net bir çatışma yanıtı (genellikle HTTP 409) dönün ve şunları sağlayın:

• şu anki sunucu kaydı
• istemcinin denediği değişiklikler (veya yeniden oluşturmak için yeterli bilgi)
• mümkünse hangi alanların farklı olduğunun listesi

AppMaster'da bu PostgreSQL model alanı, okuma uç noktası ve koşullu güncellemeyi yapan bir Business Process ile güzelce eşlenir; Business Process başarı veya çatışma dallarına ayrılır.

Kullanıcıyı rahatsız etmeden çatışmaları ele alan UI desenleri

İyimser kilitleme işin yarısıdır. Diğer yarı, kaydetme reddedildiğinde kullanıcıya gösterilen ekrandır.

İyi çatışma UI'ının iki hedefi vardır: sessiz üzerine yazmaları durdurmak ve kullanıcının görevini hızlıca tamamlamasına yardım etmek. İyi yapıldığında bu, kullanıcı için yolunuza çıkan yardımcı bir koruma gibi hissedilir.

Desen 1: Basit engelleme iletişim kutusu (en hızlı)

Düzenlemelerin küçük olduğu ve kullanıcıların yeniden uygulamayı kolayca yapabileceği durumlarda kullanın.

Mesaj kısa ve spesifik olsun: “Bu kayıt düzenlerken değişti. En güncel sürümü görmek için yeniden yükleyin.” Ardından iki açık eylem verin:

• Yeniden yükle ve devam et (birincil)
• Değişikliklerimi kopyala (isteğe bağlı ama faydalı)

“Değişikliklerimi kopyala” kullanıcıların kaydetmediği değerleri panoya koyabilir veya yeniden yüklemeden sonra formu koruyabilir, böylece yeniden yazmak zorunda kalmazlar.

Tek alanlı güncellemeler, geçişler, durum değişiklikleri veya kısa notlar için iyi çalışır. AppMaster gibi araçlarda da uygulanması en kolay olandır.

Desen 2: “Değişiklikleri gözden geçir” (değerli kayıtlar için en iyisi)

Kayıt önemliyse (fiyatlandırma, izinler, ödemeler) veya form uzunsa, kullanıcıyı bir çatışma ekranına yönlendirin ve karşılaştırma gösterin:

• “Sizin düzenlemeleriniz” (kaydetmeye çalıştığınız)
• “Güncel değerler” (veritabanından gelen son hâl)
• “Açtığınızdan beri ne değişti” (çatışan alanlar)

Sadece ilgili alanları gösterin. Her çatışan alan için basit seçenekler sunun:

• Benimki kalsın
• Onlarınkini al
• Birleştir (örneğin etiketler veya notlar gibi durumlarda anlamlıysa)

Kullanıcı çatışmaları çözdüğünde en yeni sürüm değeriyle tekrar kaydetme yapılır. Zengin metin veya uzun notlar varsa küçük bir diff görünümü (eklenen/kaldırılan) gösterin.

Zorlayarak üzerine yazmaya ne zaman izin verilmeli (ve kim yapabilir)

Zorla üzerine yazma bazen gerekir ama nadir ve kontrol altında olmalıdır. Eğer eklerseniz, kısa bir gerekçe isteyin, kimin yaptığına dair log tutun ve sadece admin veya denetçi gibi rollere izin verin.

Normal kullanıcılar için varsayılan “Değişiklikleri gözden geçir” olmalı. Zorla üzerine yazma, kaydın sahibi olduğunda, düşük riskli olduğunda veya sistem gözetim altında kötü veriyi düzeltirken savunulabilir.

Örnek senaryo: iki ekip arkadaşı aynı kaydı düzenliyor

İki destek temsilcisi, Maya ve Jordan, aynı müşteri profilini güncelliyor. İkisi de müşteri durumunu değiştirip çağrı sonrası not ekliyor.

Zaman çizelgesi (iyimser kilitleme etkin, version veya updated_at ile):

• 10:02 - Maya Müşteri #4821'i açar. Form Status = "Needs follow-up", Notes = "Called yesterday" ve Version = 7 olarak yüklenir.
• 10:03 - Jordan aynı müşteriyi açar ve o da Version = 7 görür.
• 10:05 - Maya Status'ı "Resolved" yapar ve not ekler: "Issue fixed, confirmed by customer." Kaydeder.
• 10:05 - Sunucu kaydı günceller, Version'u 8'e çıkarır (veya updated_at güncellenir) ve kim ne zaman değiştirdiğine dair bir audit kaydı saklanır.
• 10:09 - Jordan farklı bir not yazar: "Customer asked for a receipt" ve Kaydet'e basar.

Koruma olmasa Jordan'ın kaydetmesi Maya'nın durumunu ve notunu sessizce üzerine yazabilirdi. İyimser kilitleme ile sunucu Jordan'ın expected_version: 7 isteğini reddeder çünkü kayıt artık Version = 8'dir.

Jordan net bir çatışma mesajı görür. UI ne olduğunu gösterir ve güvenli bir sonraki adım sunar:

• En yeni kaydı yeniden yükle (benim düzenlemelerimi at)
• Değişikliklerimi en güncel kayıt üzerine uygula (mümkünse önerilir)
• Farkları gözden geçir ("Benim" vs "Güncel") ve hangisini koruyacağını seç

Basit bir ekran şu bilgileri gösterebilir:

• “Bu müşteri 10:05'te Maya tarafından güncellendi”
• Değişen alanlar (Status ve Notes)
• Jordan'ın kaydetmediği notunun önizlemesi

Jordan “Farkları gözden geçir”i seçer, Maya'nın Status = "Resolved" olarak kalmasını sağlar ve kendi notunu mevcut notlara ekler. Yeniden kaydedince artık Version = 8 ile kaydeder ve işlem başarılı olur (sonra Version = 9 olur).

Son durum: veri kaybı yok, kim kimin üzerine yazdı bilinmiyor değil, ve Maya'nın durum değişikliği ile her iki not ayrı izlenebilir düzenlemeler olarak kalır. AppMaster ile yapılan bir araçta bu, güncellemede tek bir kontrol ve küçük bir çatışma çözüm diyaloguyla kolayca eşlenir.

Veri kaybına yol açan yaygın hatalar

Çoğu “iyimser kilitleme” hatası fikirden ziyade UI, API ve veritabanı arasındaki el değişiminde olur. Katmanlardan herhangi biri kuralları unutursa yine sessiz üzerine yazma yaşanabilir.

Klasik hata, düzenleme ekranı yüklendiğinde sürümü almak ama kaydederken bunu geri göndermemektir. Bu genelde formun sayfalar arasında yeniden kullanılması ve gizli alanın düşmesi ya da API istemcisinin sadece “değişen” alanları göndermesiyle olur.

Bir diğer tuzak, çatışma kontrollerini sadece tarayıcıda yapmak. Kullanıcı uyarı görse bile sunucu yine güncellemeyi kabul ederse farklı bir istemci (veya yeniden deneme) veriyi ezebilir. Sunucu nihai karar verici olmalıdır.

Veri kaybına en çok yol açan kalıplar:

• Kaydetme isteğinde eşzamanlılık belirteci eksik (version, updated_at veya ETag), böylece sunucunun karşılaştıracağı bir şey olmaz.
• Güncelleme sadece id ile filtrelenir, id + version ile değil.
• Düşük hassasiyetli updated_at kullanımı (örneğin saniye). Aynı saniyede iki düzenleme aynı görünür.
• Uzun alanları (notlar, açıklamalar) veya dizileri (etiketler, kalemler) tamamen değiştirmek, neyin değiştiğini göstermemek.
• Her çatışmayı “sadece yeniden dene” olarak ele almak; bu, eski değerleri yeni verinin üstüne yeniden uygulayabilir.

Somut örnek: iki destek lideri aynı müşteri kaydını açar. Biri uzun bir iç not ekler, diğeri durum değişikliği yapıp kaydeder. Eğer sizin kaydetme tüm kayıt yükünü (tam payload) yedekliyorsa, durum değişikliği notu silebilir.

Bir çatışma olduğunda, API yanıtı çok inceyse takımlar hâlâ veri kaybeder. Sadece "409 Conflict" dönmeyin. İnsanların düzeltmesi için yeterli bilgi verin:

• Sunucunun şu anki sürümü (veya updated_at)
• İlgili alanlar için en son sunucu değerleri
• Farklı olan alanların açık bir listesi
• Değiştiren kişi ve zaman (takip ediyorsanız)

AppMaster'da bunu uyguluyorsanız aynı disiplini uygulayın: sürümü UI durumunda tutun, kaydederken gönderin ve PostgreSQL'e yazmadan önce backend mantığında kontrol edin.

Yayına almadan önce hızlı kontroller

Bunu dağıtmadan önce "kaydetti" görünürken başka birinin işini sessizce ezebilecek hata modlarına bakın.

Veri ve API kontrolleri

Kayıt uçtan uca bir eşzamanlılık belirteci taşımalı. Bu version tam sayı veya updated_at olabilir, ama kayıtla beraber zorunlu bir alan olarak ele alınmalı, opsiyonel meta veri değil.

• Okumalar belirteci içermeli (UI bunu form durumunda saklamalı, sadece ekranda bırakmamalı).
• Her güncelleme son görülen belirteci geri göndermeli ve sunucu yazmadan önce doğrulamalı.
• Başarılıysa sunucu yeni belirteci döndürmeli ki UI senkronize kalsın.
• Toplu düzenlemeler ve satır içi düzenlemeler aynı kurala tabi olmalı; kısayol yapılmamalı.
• Aynı satırları düzenleyen arka plan işleri de kontrolleri uygulamalı (aksi takdirde rastgele görünen çatışmalar yaratırlar).

AppMaster ile inşa ediyorsanız, Data Designer'da version veya updated_at alanının varlığını ve Business Process içinde karşılaştırmanın yapıldığını iki kez kontrol edin.

UI kontrolleri

Sunucu bir güncellemeyi reddettiğinde sonraki adım açık olmalı.

Sunucu güncellemeyi reddettiğinde net bir mesaj gösterin: “Bu kayıt açtığınızdan beri değişti.” Ardından ilk güvenli adım olarak en güncel veriyi yeniden yüklemeyi sunun. Mümkünse "yeniden yükle ve değişikliklerimi yeniden uygula" yolu ekleyin; bu, küçük bir düzeltmenin yeniden yazma gerektirmesini engeller.

Eğer gerçekten gerekliyse kontrollü bir “zorla kaydet” seçeneği ekleyin. Rol ile sınırlandırın, onay isteyin ve kim zorla kaydettiğini loglayın.

Sonraki adımlar: önce bir iş akışına kilitlemeyi ekleyin ve genişletin

Küçük başlayın. İnsanların birbirine sıkça çarptığı bir yönetici ekranı seçin ve önce oraya iyimser kilitlemeyi ekleyin. Yüksek çakışma alanları genelde ticketlar, siparişler, fiyatlandırma ve envanterdir. Bir yoğun ekranda çatışmaları güvenli hale getirirseniz, deseni diğer ekranlara hızla uygulayabilirsiniz.

Varsayılan çatışma davranışınızı baştan seçin, çünkü bu hem backend mantığını hem de UI'yi şekillendirir:

• Blokla ve yeniden yükle: kaydetmeyi durdur, en güncel kaydı yeniden yükle ve kullanıcının değişikliği yeniden uygulamasını iste.
• Gözden geçir ve birleştir: “sizin değişiklikleriniz” vs “en güncel değişiklikler”i göster ve kullanıcının hangisini alacağına karar vermesini sağla.

Blokla-ve-yeniden-yükle, kısa düzenlemeler için daha hızlıdır. Gözden geçir-ve-birleştir, kayıtlar uzun veya yüksek riskliyse (fiyat tabloları, çok alanlı sipariş düzenlemeleri) daha değerlidir.

Bir akışı tamamlayıp test ettikten sonra genişletin:

• Bir ekran seçin ve en çok düzenlenen alanları listeleyin.
• Form payload'una bir version (veya updated_at) ekleyin ve kaydederken bunu zorunlu kılın.
• Veritabanı yazımında koşullu güncelleme yapın (sadece sürüm eşleşiyorsa güncelle).
• Çatışma mesajını ve sonraki adımı tasarlayın (yeniden yükle, değişikliklerimi kopyala, karşılaştırma görünümü).
• İki tarayıcıyla test edin: Sekme A'da kaydedin, sonra Sekme B'de eski veriyi kaydetmeyi deneyin.

Çatışmalar için hafif logging ekleyin. Basit bir “çatışma oldu” olayı; kayıt türü, ekran adı ve kullanıcı rolü bile çatışma noktalarını görmenize yardımcı olur.

AppMaster ile yönetici araçları inşa ediyorsanız (appmaster.io), ana parçalar netçe eşlenir: Data Designer'da bir sürüm alanı modelleyin, Business Processes içinde koşullu güncellemeyi zorunlu kılın ve UI oluşturucuda küçük bir çatışma diyalogu ekleyin. İlk iş akışı stabil hale geldikten sonra aynı deseni ekran ekran tekrar edin ve çatışma UI'sını tutarlı tutun ki kullanıcılar bir kez öğrendiklerinde her yerde güvensinler.