Randevu Takviminde Özel Etkinlik Yetkisi Nasıl Planlanır?

Randevu takviminde özel etkinlikler gizlenebilir mi?

Google Calendar ile randevu akışı kurarken ekibin takvimi düzenlemesi, kişisel veya hassas etkinliklerin ayrıntılarını görmesi gerektiği anlamına gelmez. Google'ın 2026'da duyurduğu writerWithoutPrivateAccess yetkisi, özel olmayan etkinlikler üzerinde okuma ve yazma izni verirken özel etkinlikleri yalnızca meşgul zaman bloğu olarak gösterir. Calendar API sürüm notu bu rolün özel etkinlik ayrıntılarını görme veya değiştirme izni vermediğini açıklıyor. Randevu otomasyonunda bu özellik yararlıdır; fakat tek başına hasta, müşteri veya ekip verisi için eksiksiz bir gizlilik çözümü değildir.

Önce takvimin kime ait olduğunu belirleyin

Randevu sistemi kurulurken “takvim” tek bir kutu gibi düşünülürse yetki hataları doğabilir. İşletme takvimi, her çalışanın kişisel takvimi ve müşteriye gönderilen davetler farklı sahiplik ve paylaşım düzenlerine sahiptir. Bir çalışanın kişisel takvimini merkezi randevu kaynağı yapmak, izin değişikliği veya işten ayrılma sırasında sorun yaratabilir. İşletme yönetimindeki randevu takvimi ile kişisel zaman bloklarını nasıl eşleştireceğinize proje başında karar verin.

Yetki matrisi basit olmalı: takvimi kim oluşturur, kim randevu ekler, kim iptal eder, kim yalnızca uygunluk görür ve kim özel etkinlik ayrıntılarını hiç görmez? Her rolü bir kullanıcı veya entegrasyon hesabıyla eşleyin. Birden fazla şube ya da hizmet ekibi varsa erişim kapsamını ekibin gerçek sorumluluğuyla sınırlandırın. “Herkese düzenleyici” yaklaşımı uygulamada hızlı görünse de sonradan hangi değişikliği kimin yaptığını anlamayı güçleştirir.

Yeni erişim rolü tam olarak ne sağlar?

Google Calendar paylaşım belgesi, freeBusyReader rolünün yalnızca uygunluk bilgisini görmesine; reader rolünün etkinlikleri okumasına; writerWithoutPrivateAccess rolünün özel olmayan etkinlikleri okuyup yazmasına ve özel etkinlikleri meşgul blokları olarak görmesine izin verildiğini listeler. writer daha geniş okuma ve yazma yetkisine sahiptir. Bu ayrım, randevuyu düzenlemesi gereken ama kişisel görüşmenin başlığını görmemesi gereken temsilci için anlamlıdır.

Google'ın Temmuz 2026 duyurusu, yeni paylaşım düzeyinin Calendar ayarlarında kullanıcı tarafından verilebildiğini, özel etkinliklerin temsilcinin aramasında görünmediğini ve özel etkinliklerin yeniden planlanamadığını söylüyor. Duyuru özelliğin Workspace müşterileri yanında kişisel hesaplarda da sunulduğunu belirtiyor. Yine de hesabın arayüzünde bu seçeneğin gerçekten göründüğünü ve kuruluş paylaşım politikasının erişimi sınırlayıp sınırlamadığını doğrulayın. Sadece duyuruya dayanarak bütün kullanıcıların aynı yetkiyi etkin biçimde kullanabildiğini varsaymayın.

Uygunluk ile içerik gizliliğini ayrı test edin

Özel etkinliği gizlemek, o zaman diliminin müsait gösterilmesi demek değildir. Randevu sistemi, meşgul bloğunu uygunluk hesabında dikkate almalıdır. Basit kabul testi şöyle olabilir: takvim sahibi özel bir toplantı oluşturur; sınırlı düzenleme yetkisi verilen kullanıcı o saati meşgul olarak görür, başlığı ve açıklamayı görmez; randevu motoru da aynı saate yeni talep açmaz. Ardından normal randevunun oluşturulabildiği ve gerektiğinde değiştirilebildiği sınanır.

Bu testleri yalnızca bir kullanıcı hesabında değil, gerçek yetki kombinasyonlarında yürütün. Takvim sahibinin görünümü ile temsilcinin görünümü farklıdır; kişisel hesabın görünümü başka olabilir. Paylaşılan etkinliğe davetli bir kişinin kopyası da kendi takvim paylaşım kurallarına tabidir. Resmî paylaşım rehberi, davetlinin takvimindeki kopyanın onun paylaşım ayarlarına göre görüneceğini açıklar. Bu nedenle “kaynak takvimde özel işaretledik, herkes için gizli” diye genel hüküm vermeyin.

Randevu otomasyonuna uygulanacak adımlar

İlk adım, kullanılan takvimleri ve olay türlerini envantere almaktır. Randevu, kişisel zaman, ekip toplantısı, bakım aralığı ve iptal gibi olayları ayırın. İkinci adımda hangi olayın varsayılan, hangisinin özel görünürlükte olacağını tanımlayın. Üçüncü adımda temsilci ve entegrasyon hesabına gereken en dar rolü verin; yalnızca uygunluk sorgusu yapan bir bileşenin düzenleme yetkisine ihtiyacı olmayabilir. Dördüncü adımda randevunun oluşturma, değiştirme, iptal ve tekrar deneme akışlarını test edin.

Beşinci adım, sistemler arasındaki eşzamanlamayı kontrol etmektir. Takvimde elle taşınan bir randevu CRM kaydını etkiliyor mu? CRM'de iptal edilen randevu takvimden de kaldırılıyor mu? Bağlantı kesilirse son doğru kayıt nerede kalıyor? Bu soruların yanıtını API özelliği vermez; entegrasyon tasarımı verir. Benzer operasyon problemleri için diş kliniğinde randevu çakışması rehberimiz hekim ve kaynak uygunluğunu birlikte ele alıyor.

Tekrarlayan etkinliklerde neden özel test gerekir?

Google'ın 2026 sürüm notu, tekrarlayan bir etkinliğin tek örneğinde görünürlüğü daha kısıtlı hâle getirmenin serideki tüm örnekleri etkileyebileceğini belirtiyor. Daha gevşek görünürlük değişikliği ise tek örnekte yok sayılabilir; ana tekrar serisini düzenlemek gerekebilir. Bu davranış, her hafta aynı saatte duran kişisel zaman bloğu veya düzenli ekip toplantısı için önemlidir. Bir örneği özel yapmanın yalnızca o gün için etkili olduğunu varsayarsanız diğer haftaların uygunluğu ve görünürlüğü beklenmedik şekilde değişebilir.

Bu nedenle tekrar eden olay testinde ana seriyi, tek örneği ve iptal edilen örneği ayrı izleyin. Arayüzde görünen sonucu API cevabıyla karşılaştırın. Test sırasında gerçek müşteri adı ya da kişisel sağlık bilgisi kullanmayın. Özellikle klinik gibi alanlarda veri erişimi sadece takvim rolüyle çözülmez; uygulama içi yetki, kayıt saklama ve ilgili hukuki yükümlülükler ayrıca uzman değerlendirmesi gerektirir. Burada verilen yaklaşım hukuki uygunluk iddiası değil, teknik tasarım kontrolüdür.

Hata senaryolarını baştan yazın

Bir yetkili randevuyu düzenlemeye çalışırken erişim reddi alabilir. Bunun nedeni rolün dar tutulması, olayın özel işaretlenmesi veya kuruluş paylaşım ayarı olabilir; mesaj yalnızca “sistem hatası” dememeli. Bir randevu iki sistemde farklı saatle görünebilir; saat dilimi ve eşzamanlama kaynağı kontrol edilmelidir. Bir özel etkinlik başlığı görünüyorsa rol, olay görünürlüğü ve davetli kopyası ayrı incelenmelidir. Takvim bağlantısı koptuğunda sistem yeni uygunluğu tahmin ederek aşırı rezervasyon yapmamalı; güvenli bekleme ve manuel doğrulama yolu bulunmalıdır.

Uygulama kabul kriterleri ölçülebilir cümlelerle yazılabilir: sınırlı yetkili özel etkinlik başlığını göremez; aynı saat randevuya kapalıdır; normal randevu oluşturulabilir; iptal sonrası uygunluk geri döner; erişim kesilirse ekip uyarılır. Bu kriterler “entegrasyon çalışıyor” gibi belirsiz bir kabule göre çok daha yararlıdır.

Hizmet kararı

İhtiyacınız yalnızca ekip üyelerinin takvim paylaşımıysa mevcut Calendar ayarları yeterli olabilir. Müşteri formu, çoklu çalışan uygunluğu, hatırlatma, CRM kaydı ve iptal kuralları birlikte yönetilecekse özel bir otomasyon gerekebilir. Webinle'nin otomasyon yazılımları hizmeti bu tür iş akışlarını kapsam ve denetlenebilirlik üzerinden değerlendirir. Mevcut takvimleriniz, rolleriniz ve hata senaryolarınızla teklif isteyebilirsiniz; uygulanacak paylaşım ve veri koruma düzeni proje ortamında ayrıca doğrulanmalıdır.