Sohbet tabanlı onaylar, Telegram veya e-posta bağlantılarıyla istekleri onaylamayı/silmesini sağlar; süresi dolan token'lar ve denetim izi ile güvenli bir akış sunar.
Onaylar genellikle insanların tembelliğinden dolayı beklemez. Bekleme, karar vermek için doğru anla kişinin aynı yerde olmamasından kaynaklanır. Bir istek kimsenin sık kontrol etmediği bir araçta kalır ya da onaylayıcı masasında değilken gelir ve sessizce “sonra” olur.
En yaygın darboğazlar basittir:
İşte burada iç iş akışları için sohbet tabanlı onaylar yardımcı olabilir. Basitçe, onaylayıcıya zaten kullandığı bir kanalda (genellikle Telegram veya e-posta) kısa bir mesaj gider; içinde net detaylar ve iki işlem: onayla veya reddet. Amaç tüm süreci sohbete taşımak değil. Amaç, insanların gösterge panosu aramadan küçük, zamana duyarlı kararlar vermesini sağlamaktır.
Bu en iyi şekilde hızın uzun bir incelemeden daha önemli olduğu düşük-orta riskli kararlar için çalışır. Örnekler: küçük bir satın alımı onaylamak, paylaşılan bir klasöre erişim vermek, bir program değişikliğini onaylamak veya belirli limit dahilinde müşteri iadesini onaylamak.
Kararın dikkatli analiz, çoklu gözden geçirici veya görev ayrımı gerektirdiği durumlarda bu yanlış bir araçtır. Yüksek riskli işlemler (büyük ödemeler, İK işlemleri, tedarikçi sözleşmeleri) için sohbet düğmesi hızlı tıklama baskısı yaratabilir; bu da istemediğiniz bir durumdur.
Bu tür bir akışı AppMaster gibi bir no-code araçla kurarsanız, gerçek kazanım “onay sürtünmesini” azaltırken süreci kontrol altında, izlenebilir ve anlaşılması kolay tutmaktır.
Sohbet tabanlı onay akışı basit bir döngüdür: biri izin ister, doğru kişi nerede olursa olsun hızlı cevap verir ve sistem ne olduğunu kaydeder. İşlediğinde, "biletini görmedim" sorununu ortadan kaldırır ama onayları izlenmeyen günlük sohbete dönüştürmez.
Üç rol vardır.
Sistem onaylayıcıları iki yaygın yerde bilgilendirebilir: hızlı yanıtlar için Telegram mesajı ve gelen kutusunda yaşayanlar için e-posta. Her ikisi de aynı temel detayları göstermeli, böylece onaylayıcının neyi onayladığını tahmin etmesine gerek kalmaz.
Tipik bir mesaj kısa bir özet, ana alanlar (tutar, tedarikçi, sebep, maliyet merkezi) ve üç net işlem içerir: Onayla, Reddet veya Değişiklik iste. “Değişiklik iste” isteğin yakın olduğu ama örneğin bir makbuz veya proje kodu gibi eksik bir ayrıntı olduğu durumlarda kullanışlıdır.
Onaylayıcı bir işlem seçtiğinde sistem hemen dört şey yapmalıdır:
İç iş akışları için sohbet tabanlı onaylarda en güvenli desen: mesajda tam bağlam göster, ama gerçek işlem sistemde gerçekleşsin ("EVET diye cevap verme" yerine). AppMaster ile kurarsanız, mesajlaşma modülü Telegram ve e-posta bildirimleri iletebilir; arka uç mantığınız ise durumları zorlar ve her kararı kaydeder.
Süresi dolan token, bir kişinin belirli bir işlemi sınırlı süre için yapmaya yetkili olduğunu kanıtlayan kısa, rastgele bir koddur. Sohbet tabanlı onaylarda, Telegram düğmesi veya e-posta onay bağlantısını günlük kullanım için yeterince güvenli yapan şey budur.
Token'ı sadece bir kilide uyan geçici bir "anahtar" olarak düşünün. Onayla veya Reddet'e tıkladığınızda sistem token'ı okur, kontrol eder ve ardından işlemi kaydeder.
Bir bağlantıdaki token tam olarak bir izin vermelidir: "bu istek için bu onay kararını ver." Token, tam istek geçmişine, hesabınıza veya başka bir şeye erişim vermemelidir.
İyi token'lar şunlarla bağlıdır:
Süre sonu, bir mesaj iletildiğinde, posta kutusu ele geçirildiğinde veya biri bağlantıya günler sonra tıkladığında zararı sınırlar. Acil maddeler için birkaç saatlik pencere, normal işler için 24–72 saat yaygın bir aralıktır.
Tek kullanımlık token'lar genellikle onaylar için en iyisidir. Bir kez kullanıldıktan sonra ikinci tıklama engellenmelidir, sayfa açık olsa bile. Çoklu kullanım token'ları "tespit et" gibi işlemler için mantıklı olabilir, ama onay/reddet için çift gönderim ve kafa karışıklığı riski taşır.
İptal, ayrıntılar değiştiğinde önemlidir. İstek tutarı, tedarikçi veya kapsam düzenlendiyse eski token'ları iptal edin ve yenilerini verin. AppMaster gibi araçlarda bu, onay kaydında (expires_at, used_at, revoked_at) basit alanlar ve kabul etmeden önce bunları doğrulayan küçük bir iş süreci olarak modellenebilir.
Korkutucu bir hata göstermeyin. Net bir sonuç gösterin:
Sonra tek güvenli bir sonraki adım sunun: mevcut onaylayıcı(lar)a yeni bir token ile taze bir onay mesajı gönderin.
İyi bir onay mesajı birinin birkaç saniyede karar vermesini sağlar; herhangi bir şeyi açmasına gerek yok. Kötü bir mesaj ise tahmin yaptırır veya hassas ayrıntıları sohbet geçmişine iter. Sohbet tabanlı onaylarda hedef "karar için yeterli" ve "sızdırmak için yeterli değil" olmalıdır.
Telefon ekranında iyi okunan tutarlı bir özetle başlayın. Karar için kritik bilgileri üstte, sonra detayları, en sonra işlem düğmelerini veya bağlantıları koyun.
Onaylayıcılar genellikle sadece birkaç alana bakarak evet ya da hayır diyebilir:
Örnek (Telegram veya e-posta): “Satın alma isteği: Bluetooth barkod okuyucu, $189, 2 Şub’a kadar gerekli, neden: depo biriminden kırık olanı değiştirme.”
Mesajların yönlendirilip ekran görüntüsü alınacağını varsayın. Hem mesaj metninde hem de URL'de sırları tutmayın.
Tam kart numaraları, banka bilgileri, şifreler, özel müşteri verileri veya sadece finans ya da İK için olan dahili yorumlar gibi hassas bilgileri eklemeyin. Hassas bir şeye referans vermeniz gerekirse, "Tedarikçi teklifi: dosyada" gibi kısa bir etiket kullanın.
Onay bağlantıları için token'ı opak ve kısa ömürlü tutun. Okunabilir verileri (tutar veya kullanıcı e-posta gibi) bağlantıya koymayın; bunun yerine bunları mesaj gövdesine koyun.
Son olarak, bağlantı süresi dolarsa veya şüpheli görünüyorsa insanların yine de doğru öğeyi onaylayabilmesi için güvenli bir geri dönüş sağlayın: bir İstek ID'si (örnek: PR-10438) ve basit bir "Uygulamada aç" seçeneği ekleyin. AppMaster ile inşa ediyorsanız, İstek ID'sini ana çapaç olarak ele alın: onaylayıcının dahili portalde arayıp doğru isteği doğrulayabileceği şey budur.
İlk Telegram veya e-posta onay isteğini göndermeden önce "tamamlandı"nın ne anlama geldiğine karar verin. Sohbet tabanlı onaylar yüzeyde basit hissettirir, ama iş akışının net durumları yoksa bozulurlar.
Veritabanınızda saklayacağınız küçük bir istek durum setiyle başlayın. Sıkıcı ve tahmin edilebilir tutun ki herkes ve tüm raporlar aynı şekilde okusun.
Sonra kimlerin onaylayabileceğini tanımlayın. "Mesajı ilk gören"e güvenmeyin. Onay haklarını bir role veya ekibe bağlayın ve ana onaylayıcı yoksa ne olacağını kararlaştırın.
Erken karar verilmesi gereken basit bir kural seti:
Birden çok onaylayıcı varsa bir desen seçin ve adlandırın. "Any-of" ilk onayın isteği tamamladığı anlamına gelir. "All-of" listedeki herkesin onaylaması gerektiği anlamına gelir. Ayrıca all-of akışında bir reddetmeyi nasıl ele alacağınızı kararlaştırın (genellikle: bir reddetme süreci sonlandırır).
Son olarak, onaydan sonra ne olacağını yazın. Örnek: onaylanan bir satın alma isteği bir ödeme görevi oluşturabilir, muhasefeyi bilgilendirir ve orijinal isteği düzenlenemez hale kilitler. AppMaster'da bu, veritabanı durum değişikliklerine ve sonraki adımları tetikleyen bir Business Process'e temiz şekilde eşlenir.
İç iş akışları için sohbet tabanlı onaylar kurarken akışı küçük tutun: bir istek kaydı, bir karar ve net bir denetim girdisi. İleride ekstra kurallar ekleyebilirsiniz ama temel şekli değiştirmeyin.
Önce karar vermek için gereken alanlara sahip tek bir "Request" kaydı oluşturun: ne olduğu, kim sordu, kimin onaylaması gerektiği ve tutar veya etki. Herkese mesaj atmadan önce status = Pending olarak ayarlayıp kaydedin; böylece her işlem işaret edilebilecek gerçek bir şeye sahip olur.
Sonra süresi olan bir onay token'ı oluşturun. Bunu isteğe ve hedef onaylayıcıya referans veren ayrı bir “ApprovalToken” kaydında, artı expires_at ve used_at ile saklayın. Bu bağlama önemlidir: bir mesajı yönlendirmenin farklı bir kişinin onaylamasına engel olur.
İşte basit bir oluşturma sırası:
Pending durumuyla kaydet.action parametresi olan bir token, kısa bir süreyle.Tıklamayı işlerken bunu bir işlem gibi ele alın: "süresi dolmamış" ve "kullanılmamış" olup olmadığını kontrol edin, token'ın hem isteğe hem de onaylayıcıya uyduğunu doğrulayın, sonra isteği Approved veya Rejected olarak güncelleyin. Kim hangi kararı verdi, ne zaman verdi ve ne seçtiğini kaydedin.
AppMaster'da bu, Data Designer modeline (Request, ApprovalToken, ApprovalAudit) ve doğrulama ve güncellemeyi yürüten bir Business Process'e iyi uyar. Telegram ve e-posta için yerleşik mesajlaşma modüllerini kullanın ki aynı süreç her iki kanalı da bilgilendirebilsin.
İşi bitirirken iki kısa mesaj gönderin: biri istek sahibine ("Maria tarafından onaylandı, 10:42") ve biri onaylayıcıya ("Kaydedildi, token kapatıldı"). Bu geri bildirim tekrar tıklamaları ve destek taleplerini azaltır.
Bir denetim izi sadece uyumluluk için değildir. Sonradan temel soruları cevaplamanın yoludur: Bunu kim onayladı, ne zaman, nereden ve hangi bilgiye dayanarak? Sohbet tabanlı onaylarda anahtar, her seferinde birkaç alanı tutarlı şekilde kaydetmektir, her şeyi değil.
Bir "onay işlemi"nin ne sayılacağına karar verin. Genellikle bu, Telegram mesajı veya e-posta onay bağlantısından tek bir tıklamadır. Her işlem bir değiştirilemez kayıt oluşturmalıdır.
Her seferinde aynı temel alanları kaydedin:
Reddedilme nedenleri toplamak değerlidir ama basit tutun: kısa bir metin alanı artı isteğe bağlı küçük bir etiket seti (örnek: "bütçe", "eksik bilgi", "politika"). Sebep zorunlu ise bunu sadece Reddet için yapın ve uzunluğu sınırlayın ki gerçekten faydalı bir şey yazılsın.
Uyuşmazlıkları ele almak için istekte okunaklı bir geçmiş gösterin: oluşturuldu, gönderildi, onaylandı/reddedildi ve varsa yeniden gönderimler. Günlükte sırları ifşa etmeyin. Tam ödeme ayrıntılarını veya özel notları saklamak yerine güvenli bir anlık görüntü (tedarikçi adı, tutar, maliyet merkezi) saklayın ve hassas verileri korumalı ayrı bir alanda tutun.
Raporlama hafif tutulabilir. Kullanışlı sinyaller şunlardır:
AppMaster ile pratik bir yaklaşım, Data Designer'da ayrılmış bir “ApprovalActions” tablosu ve istek durumunu değiştirmeden önce denetim kaydını yazan tek bir Business Process adımıdır. Bu, mesaj yönlendirildiğinde veya token süresi dolduğunda bile geçmişi güvenilir kılar.
Çoğu sohbet tabanlı onay iç iş akışı sıkıcı nedenlerle başarısız olur: biri bağlantıya iki kez tıklar, yönlendirir veya istek mesaj gönderildikten sonra değişir. Bunların çoğunu birkaç kolay uygulanabilir kural ile önleyebilirsiniz.
Klasik bir tuzak onay bağlantısını bir şifre gibi görmektir. Bir token yeniden kullanılabiliyorsa aynı işlem iki kez kaydedilebilir. Bağlantı yönlendirilirse farklı biri asla görmemesi gereken bir şeyi onaylayabilir.
Bir diğer yaygın sorun token'ı hedef onaylayıcıya bağlamamaktır. Sisteminiz sadece "bu token geçerli mi?" diye kontrol ediyorsa, bağlantıya sahip herhangi bir giriş yapmış kullanıcı (veya bağlantıya sahip biri) işlem yapabilir. Token'ı hem istekle hem de onaylayıcı kimliğiyle bağlayın ve kanal güvensizse giriş zorunlu kılın.
Süresinin bitmesi iki yönde sorun yaratır. Asla süresi dolmayan token'lar kalıcı arka kapılar olur. Çok hızlı süresi dolan token'lar ise destek yükü yaratır ve insanların süreci "aşmak" için yollar bulmasına neden olur. Pratik bir pencere (örneğin birkaç saat) hedefleyin ve her zaman yeni bağlantı isteme için güvenli bir yol sunun.
İstek değişiklikleri başka bir kötü onay kaynağıdır. Mesaj gönderildikten sonra biri tutarı veya tedarikçiyi düzenler, onaylayıcı güncel olmayan görünümde "Onayla"ya tıklar.
Aşağıdaki semptomlara dikkat edin:
Basit bir düzeltme seti (AppMaster gibi araçlarda uygulanması kolay) tek kullanımlık token'lar, onaylayıcı bağlama ve net hata ekranları içerir. Örneğin: "Bu bağlantının süresi doldu. Yeni bir onay mesajı isteyin." Bu tek cümle çoğu panik tıklamayı ve gölge onayları engeller.
Sohbet tabanlı onaylar basit çünkü kullanıcı sadece Onayla'ya dokunuyor gibi görünür. Güvenlik işi kullanıcıların görmediği kısımlarda: bağlantıları nasıl oluşturduğunuz, token'ları nasıl doğruladığınız ve uç durumları nasıl ele aldığınızda yatar.
Onay bağlantısından başlayın. HTTPS-only uç noktaları kullanın ve token'ı bir parola gibi değerlendirin. Sunucu erişim günlükleri, analizler ve sohbet önizlemeleri gibi kopyalanan yerlere token'ı koymayın. Pratik bir hile, tam istek URL'lerini günlüklememek ve sunucu tarafında yalnızca kısa bir token fingerprint saklamaktır.
Rate limiting büyük bir kazanımdır. Token doğrulama ve nihai onay/reddet uç noktası tahmin ve tekrar denemelere karşı korunmalı. Token'lar uzun olsa bile rate limit'ler gürültülü saldırıları durdurur ve kazara çift dokunuşları engeller.
Bazı onaylar diğerlerinden daha yüksektir. Tedarikçi ödemeleri veya müşteri verilerine erişim gibi şeyler için, kullanıcı bağlantıya tıkladıktan sonra hızlı bir giriş veya MFA gibi ek bir adım isteyin. AppMaster'da bu, Business Process içinde bir kural olarak modellenebilir: düşük riskli istekler geçerli token ile tamamlanırken, yüksek riskliler durumu değiştirmeden önce kimlik doğrulamalı oturuma yönlendirilir.
Roller değiştiğinde token'ları iptal etmenin temiz bir yoluna sahip olun. Biri ekip değiştirirse, şirkette ayrılırsa veya telefonu kaybolursa o kişi için bekleyen tüm token'ları ve dokunduğu bekleyen istekleri geçersiz kılabilmelisiniz.
Başlangıçta alınacak birkaç karar:
Örnek: bir yönetici onay e-postasını bir meslektaşına gönderirse, sistem ya işlemi engellemelidir ya da meslektaşı onaylamadan önce oturum açmaya zorlamalıdır.
Operasyonlar yöneticisi Maya, gönderme tezgahı için 180$'lık bir etiket yazıcısını değiştirmek istiyor. Dahili "Purchase Request" formunu açar, tedarikçi, tutar ve kısa bir not girer, sonra gönderir. İstek Pending durumunu alır ve ekip lideri Jordan'a atanır.
Jordan hızlıca taranabilen bir Telegram mesajı alır: "Maya'dan satın alma isteği: Etiket yazıcısı, $180. Bu hafta gerekli." Altında iki net işlem vardır: Approve ve Reject. Her işlem tek kullanımlık, süresi olan token'a bağlı bir düğme veya kısa bir komuttur.
Jordan Reject'e dokunur ve sebep ekler: "Lütfen onaylı tedarikçi listesini kullanın ve teklifi ekleyin." Sistem hemen iki şey yapar. İlk olarak, isteği Jordan'ın nedeniyle birlikte Rejected olarak günceller. İkinci olarak, Maya'yı aynı kanalda (veya kurallarınıza göre e-posta ile) bilgilendirir ki nerede hata olduğunu düzeltip yeniden gönderebilsin.
Gizlilikte, basit bir denetim izi temel soruları kağıt işi olmadan cevaplar:
Biri token süresi dolduktan sonra Approve veya Reject bağlantısına tıklarsa işlem gerçekleşmez. Bunun yerine "Bu işlem bağlantısının süresi doldu" gibi net bir mesaj görür ve istek Pending kalır. Bu eski mesajlardan kaynaklanan kazara onayları önler ve kaydınızı temiz tutar.
Bu tür bir akışı AppMaster gibi bir no-code araçta basit bir istek tablosu, bir durum alanı ve Telegram veya e-posta işlemleri gönderen ve denetim kaydı yazan bir business process ile kurabilirsiniz.
İç iş akışları için sohbet tabanlı onaylardan hızlı değer almak için güvenli, ölçülebilir ve desteklemesi kolay küçük bir sürüm yayınlayın. Zaten gecikmelere yol açan bir istek türünü seçin (küçük satın almalar veya erişim isteği gibi) ve önce bir ekiple deneyin.
Yayınlamadan önce kısa bir kontrol listesi ile son bir geçiş yapın:
İlk haftadan sonra dönüş süresini ölçün: "istenen" ile "karar verilen" arasındaki süre ve insanların mesajı ne sıklıkta görmezden gelip hatırlatma gerektirdiği. "Onay için medyan süre" gibi basit bir metrik iyileşmeleri görünür kılar.
Erken bir yönetici görünümü planlayın. Güzel olmasına gerek yok ama istek ID'sine, istek sahibine ve duruma göre arama yapabilmeli ve tam karar geçmişini görebilmelidir. Birisi "dün onayladım, nereye gitti?" dediğinde ops veya muhasebe ekipleri bunu kullanır.
Ağır kodlama olmadan bunu inşa etmek isterseniz, AppMaster isteği ve denetim tablolarını modellemenize, onay/reddet mantığını görsel bir akışla tasarlamanıza ve aynı iş akışının parçası olarak Telegram veya e-posta mesajları göndermenize yardımcı olabilir. Küçük başlayın, gerçek kullanımı izleyin, sonra temel oturduğunda hatırlatmalar, delege etme ve tırmanış gibi ekstraları ekleyin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
