SharePoint Copilot Apps: Sohbete Gerçek Arayüz Geliyor
Geçenlerde bir müşterinin Copilot chat’inde şunu izledim: kullanıcı izin bakiyesini sordu, Copilot uzun bir metin döktü, kullanıcı “tamam. Nasıl talep edeceğim?” dedi, sonra ayrı bir İK portalına gitti, oradan kayboldu, yarım saat sonra geri döndü. Tanıdık geldi mi? Bana her hafta en az üç farklı kurumda tanıdık geliyor, yanı olay yeni değil; biraz da klasik kurumsal sürünme.
İşte tam burada Microsoft’un duyurduğu SharePoint Copilot Apps haberini görünce “nihayet” dedim. Çünkü Copilot’un dil tarafı zaten fena değil. Yanı metni anlıyor, cevap yazıyor, toparlıyor. Ama iş sadece kelime değil; bazen bir şeyi görmeniz, dokunmanız, üstüne tıklamanız gerekiyor —. Bunu yaparken başka sekmeye zıplamamak baya iş görüyor.
Sohbet güçlü, ama her şey için yetmiyor
Şöyle düşünün. Basit bir masraf onayı için Copilot’a yazıyorsunuz; “Hangi masraf?”, “Tutar ne?”, “Kategori ne?” derken üç-dört tür gidip geliyorsunuz. Sonunda size bir link veriyor ve finans portalına atıyor. Oysa çoğu zaman yapmanız gereken tek şey bir “Onayla” butonuna basmak.
Bu küçük bir sürtünme gibi dürüyor. Değil. Bir şirkette binlerce çalışan varsa ve her (belki yanılıyorum ama) biri günde 4-5 kez bu bağlam değişimini yaşıyorsa (hani şu context switching mevzusu), ortaya ciddi bir verimlilik vergisi çıkıyor; kurumsal müşterilerimde gördüğüm kadarıyla insanların bilgisayar başında geçirdiği zamanın bayağı bir kısmı doğru aracı bulmaya gidiyor. Acı ama gerçek.
SharePoint Copilot Apps tam burada devreye giriyor: kullanıcı bir şey istediğinde, ihtiyacı olan UX bileşeni doğrudan Copilot canvas’ında beliriyor. Onay kutusu, form, takvim, küçük bir dashboard — ne lazımsa. Sohbetten çıkmadan iş bitiyor.
Peki teknik tarafta ne değişiyor?
Lafı gevelemeden söyleyeyim. Microsoft, MCP (Model Context Protocol) tabanlı yeni bir uygulama modeli getiriyor. Buna UX bileşenleri ekliyor. Yanı MCP artık sadece tool call yapıp sonuç olarak metin döndüren bir yapı değil; gerektiğinde gerçek bir arayüz parçası da döndürebiliyor. Bu parça da Copilot canvas’ının içinde native gibi çalışıyor (bu beni çok şaşırttı)
Geliştirici açısından güzel taraf şu: SPFx (SharePoint Framework) ile yazıyorsunuz. Yeni dil yok, yeni runtime yok, “Microsoft yine başka bir şey çıkardı” diye iç çekmek yok. React biliyorsanız React kullanıyorsunuz (yanlış duymadınız). Angular seviyorsanız Angular var. Hani ne farkı var diyorsunuz, değil mi? Vue, Svelte, hatta düz TypeScript bile olur — yanı seçenek dar değil.
Bu yaklaşım bana doğru geliyor. Microsoft yıllarca “önce bizim platformumuzu öğrenin” modundaydı. Şimdi işe “sız ne biliyorsanız önü kullanın, biz uyarlayalım” diyor. Küçük gibi duran ama stratejik etkisi baya büyük olan farklardan biri bu.
Coding agent’lar bu işte nerede dürüyor?
Bir de şu var. Standart web stack kullanıldığı için GitHub Copilot, Claude, Codex — hangi coding agent’ı kullanıyorsanız — bunlara zaten yabancı değil. Scaffold etmek, refactor etmek ya da bug ayıklamak için önce agent’a yeni platform öğretme derdi yaşamıyorsunuz; iyi tarafı bu.
AZ-400 sertifikasına çalışırken ben de bunu net gördüm: SPFx tarafında AI asistanları epey olgunlaşmış durumda. Tek başınıza takıldığınız noktada Copilot Chat çoğu zaman işi toparlıyor; bazen de sizi yanlış yola sokup sonra geri çeviriyor ama olsun.
Mimarı olarak nereye oturuyor?
Klasik Copilot extension senaryosunda akış kabaca şöyleydi: kullanıcı sorar → Copilot tool çağırır → tool JSON döner → Copilot bunu metne çevirir → kullanıcı görür. İlginç, değil mi? Yanı veri vardı ama görsel temsil yoktu; temsil varsa da çoğu zaman Copilot’un kendi dar formatına sıkışıyordu.
Yeni modelde zincir kırılıyor. Tool artık sadece veri değil, doğrudan bir UX bileşeni de döndürebiliyor. Aşağıdaki gibi düşünün:
// Klasik MCP tool response
{
"result": "Kalan izin günleri: 12",
"type": "text"
}
// SharePoint Copilot Apps ile
{
"component": "LeaveBalanceCard",
"props": {
"remaining": 12,
"used": 8,
"actions": ["request", "viewHistory"]
},
"type": "ui-component"
}Şöyle söyleyeyim, İkinci formatta Copilot canvas’ı bu bileşeni render ediyor; kullanıcı doğrudan “Talep Et” butonuna basabiliyor, hatta küçük bir takvim seçicide tarih seçebiliyor. Hepsi sohbet kutusunun içinde kalıyor ki bence asıl olay da bu.
Türkiye’deki kurumlar için anlamı ne?
Burada biraz durmak lazım çünkü Türkiye’deki kurumsal Microsoft 365 kullanımı küresel ortalamadan biraz farklı gidiyor gibi görünüyor. Birkaç gözlem paylaşayım:
- SharePoint yatırımı zaten var — Banka, sigorta, holding, kamu… büyük kısmında SharePoint Online ya da on-prem aktif durumda. Yanı SPFx geliştirebilen ekip ya mevcut ya da çok zorlanmadan kurulabiliyor.
- Copilot lisansları yeni yeni yayılıyor — E5 + Copilot kombinasyonu hâlâ birçok CFO’ya pahalı geliyor ama 2026 itibarıyla pilot grupların büyüdüğünü ben de görüyorum. — bunu es geçmeyin
- Yerelleştirme ihtiyacı yüksek — Türkçe arayüz, KVKK uyumu ve iç sistem entegrasyonları (Logo, Mikro, Netsis, SAP) sürekli karşımıza çıkıyor; SharePoint Copilot Apps burada işe yarayabilir çünkü UI’ınızı kendi dilinizde ve kendi sistemlerinize bağlı şekilde yazabiliyorsunuz. (bence en önemlisi)
Bence en kritik nokta üçüncüsü. Çünkü dışarıdan gelen şablon yanıtlar çoğu zaman Türkçe kurumsal jargonla uyuşmuyor; bazen cümle düzgün ama ruh yok oluyor açıkçası. Ama sız kendi UX bileşeninizi yazarsanız — mesela “Avans Talep Formu” gibi — veri kaynağı da sizde olur, validation da sizde olur, butona basınca tetiklenen iş akışı da sizin kontrolünüzde kalır.
Startup mı enterprise mı? Nerede mantıklı?
Bu soruyu sık alıyorum ve cevap kısa aslında: ölçeğe göre değişiyor.
Küçük bir ekipseniz, diyelim 10-20 kişilik startup’sınız; dürüst olayım SharePoint Copilot Apps muhtemelen size göre değil.
M365 E3/E5 lisansı,
SPFx geliştirme ortamı,
deployment pipeline…
Bunların maliyeti küçük ekipte fazla kaçabiliyor.
Onun yerine doğrudan Teams app ya da Power Apps Custom Page daha hızlı sonuç verir.
Hatta bazı durumlarda basit bir Slack bot bile yeter.
Ama laf uzatmadan şunu da ekleyeyim: eğer işiniz büyürse o ilk tercihleri tekrar gözden geçirmeniz gerekebilir.
Büyük resim böyle.
Ama 500+ çalışanlı kurumsanız. Hâlihazırda SharePoint kullanıyorsanız tablo değişiyor.
Hele bir de intranet’ınız Viva Connections üzerinde dönüyorsa iş iyice anlam kazanıyor çünkü:
- Geliştirme stack’ınız zaten kurulu
- Identity ve permission tarafı Entra ID üzerinden hallediliyor
- Kullanıcılar Copilot’u zaten açmaya başladı — bunu es geçmeyin
- Aynı bileşeni hem Teams’de hem SharePoint sayfasında hem de Copilot’ta kullanabiliyorsunuz
İnanın, Son madde özellikle değerli geliyor bana.
Bir kez yazıp üç yerde çalıştırmak,
geliştirici verimliliği açısından baya iyi.
Neyse uzatmayayım.
İşin özeti bu kadar net.
Maliyet tarafında acı gerçek ne?
Garip gelecek ama, Açık konuşayım.
Microsoft 365 Copilot lisansı şu anda kullanıcı başına aylık yaklaşık 30 dolar civarında.
Türkiye’de TL bazında düşününce rakam hiç hafif durmuyor.
1000 kişilik kurumda yıllık kabaca 360 bin dolar eder;
bugünkü kurla yaklaşık 14-15 milyon TL gibi düşünebilirsiniz.
Üstelik bu sadece Copilot tarafı.
Altta zaten E3 veya E5 lisanslarının olması gerekiyor.
Çok konuştum, örnekle göstereyim.
Burada, sharePoint Copilot Apps kullanmak için ekstra lisans gerekmemesi güzel haber.
Ama geliştirme maliyeti var tabiî.
SPFx bilen developer Türkiye’de çok böl değil;
bulduğunuzda da maliyet şaşırtabiliyor.
O yüzden ben genelde şunu öneriyorum:
İzin talebi,
masraf onayı,
oda rezervasyonu…
Günde defalarca kullanılan bir şey seçin ki ROI’yi anlatmak kolay olsun;
sonraki işler için bütçe almak da biraz rahatlasın.
Peki pratikte nasıl başlanır?
Denecekse bence sıra şöyle olmalı:
Önce ortam kurulur,
sonra küçük prototip çıkarılır,
en son gerçek sisteme bağlanılır.
Kolay gibi dürüyor ama çoğu proje tam burada dağılıyor.
Bak şimdi:
1. Geliştirici ortamını kurun.
Node.js LTS,
Yeoman,
SPFx generator
ve tabiî ki Microsoft 365 developer tenant lazım.
Microsoft’un Developer Program’ı üzerinden 90 günlük (yenilenebilir) ücretsiz tenant alabiliyorsunuz.
Bu arada Microsoft Agent Framework: Katmanlı SDK Tasarımının İç Yüzü
yazımdaki SDK katmanlama mantığı
SharePoint Copilot Apps mimarisini anlamak için iyi hazırlık olur;
özellikle katmanların birbirine nasıl oturduğunu görmek açısından faydalı geliyor.
Şöyle söyleyeyim, Neyse devam edelim:
2. Basit bir prototip yazın.
Hello world tarzında olsun;
bir bileşen,
bir prop,
bir buton yeter.
Copilot canvas’ında render olduğunu görün önce.
Bu kısım sandığınızdan kolay olabilir;
coding agent’a bırakırsanız yarım saatte ayağa kalkıyor genelde.
Tabi sonra ince ayar çıkıyor ama ilk görüntüyü almak hızlı oluyor.
Dürüst olmak gerekirse, Neyse devam edelim:
3. Gerçek use case’e bağlayın.
Mock data ile oyalanmayın;
gerçek SharePoint listesi ya da Graph API endpoint’i kullanın.
Asıl tat buradan geliyor çünkü kullanıcı gerçekten fayda görmeye başlıyor.
Yoksa demo demo kalıyor,
hepimiz biliyoruz o filmi.
Sız ne dersiniz?
Deneyen öldü mu?
Küçük karşılaştırma tablosu: nereye ne uyar?
| Senaryo | En İyi Seçenek | Neden? |
|---|---|---|
| Sohbet içinde hızlı onay/aksiyon | SharePoint Copilot App | Ekrandan çıkmadan iş biter |
| Karmaşık iş akışı, çoklu sayfa | Power Apps | Form ağırlıklı senaryolarda hâlâ baya iyi gider |
| Teams içinde standalone uygulama | Teams App (SPFx veya React) | Daha geniş ekran alanı verir |
| Sadece veri sorgulama | Klasik Copilot Plugin | Zaten UI gerekmiyorsa fazlasına gerek yok |
| Intranet ana sayfa entegrasyonu | Viva Connections + SPFx | Aynı bileşeni hem intranette hem Copilot’ta kullanırsınız |
Bana eksik gelen taraflar neler?
Madalyonun diğer yüzüne bakalım şimdi.
Kağıt üstünde hoş dürüyor ama hâlâ biraz ham hissettiriyor.
Birkaç çekincem var:
Birincisi mobile deneyim.
Copilot canvas masaüstünde ferah,
mobilde işe daralıyor;
kompleks UX bileşeni telefonda sıkışabilir.
Responsive tasarımı en baştan doğru düşünmek lazım,
sonradan yamamak acıtıyor.
İkincisi performans.
Her UX bileşeni JavaScript yüklemesi demek;
sohbete beş farklı bileşen bindirirseniz canvas ağırlaşır mı?
Bu konuda Microsoft’tan net benchmark henüz görmedim,
production’da görmek gerekecek sanırım.
Üçüncüsü. En önemlisi governance.
Bir kullanıcı sohbette
“izin durumumu göster”
dediğinde hangi app çalışacak?
Tenant’ta yirmi farklı SharePoint Copilot App varsa
Copilot doğru olanı seçebilecek mi?
Bu app discovery meselesi,
daha önce Binlog MCP Server: Build Sorunlarını Copilota Çözdürmek
yazısında değindiğim MCP routing problemine benziyor;
çözülebilir ama dikkat istiyor,
aksi hâlde işler karışabiliyor.
Neyse çok dağıttım,
konuya dönelim.
“FinOps açısından bakınca?” diye sorarsanız…
Sona gelirken küçük bir not bırakayım.
Bu tür Copilott extension’ları çoğaldıkça
her UX bileşeninin arkasında ayrı ayrı LLM çağrıları oluşabiliyor;
özellikle component render edilirken context üretmek gerekiyorsa durum daha da belirginleşiyor.
Bu da tüketimi artırıyor,
yanı credit tarafını hafife almamak lazım.
Yakın zamanda Copilot Usage Metrics API’ye ai_credits_used Geldi: FinOps İçin Ne Anlama Geliyor?
yazısında bahsetmiştim;
o metriği takip etmek şimdi daha da önemli hâle geldi.
Pilot aşamasında
“her şeyi UX bileşenine çevirelim”
hevesine kapılmayın derim.
Hangi senaryo gerçekten UI istiyor,
hangisi düz metinle çözülüyor —
bunu önceden ayırmak lazım.
Evet.
Başka türlü bütçe sessizce eriyebiliyor,
sonra kimse nedenini hatırlamıyor.
Peki neden?
Çünkü teknoloji güzel diye her yere yapıştırınca
iş çözülmüyor;
bazen sade cevap daha hızlı oluyor,
bazen de küçük bir kart gerçekten hayat kurtarıyor.
Tam da öyle.
Bunu biraz açayım.
`
Sıkça Sorulan Sorular
SharePoint Copilot Apps için ekstra lisans lazım mı?
Size bir şey söyleyeyim, Hayır, ekstra bir şey ödemiyorsunuz. Aslında Microsoft 365 Copilot lisansınız ve uygun bir SharePoint planınız varsa direkt kullanabiliyorsunuz. Ama tabiî geliştirme yapacak ekibin SPFx ortamını kurması ve Microsoft 365 developer tenant’ına erişimi olması gerekiyor.
React bilmiyorum, başka bir şey kullanabilir mıyım?
Vallahi kullanabilirsiniz. SPFx; Angular, Vue, Svelte ya da düz TypeScript ile de çalışıyor. React örneklerin büyük çoğunluğunu oluşturuyor, hani topluluk en geniş orada diye, ama bu bir zorunluluk değil. Bence ekibiniz hangi stack’te rahatsa önü seçin, gereksiz yere öğrenme yüküne girmeyin (en azından benim deneyimim böyle)
Mevcut SPFx web part’larımı Copilot App’e dönüştürebilir mıyım?
Tam birebir kopyala-yapıştır olmuyor açıkçası, ama kodun %70-80’ını yeniden kullanabiliyorsunuz (yanlış duymadınız). Yanı UX bileşeninin Copilot canvas’ı içinde çalışacak şekilde manifest’ının ayarlanması, prop yapısının güncellenmesi. Event handling tarafının MCP modeline uyarlanması gerekiyor. Tecrübeme göre bu genelde birkaç günlük bir refactor işi, çok da korkunç değil.
Bu on-premises SharePoint’te de çalışıyor mu?
Burada, dürüst olmak gerekirse, Hayır. Sadece SharePoint Online ve Microsoft 365 Copilot ekosistemi içinde çalışıyor (evet, doğru duydunuz). On-premises sunucularla doğrudan bir entegrasyonu yok. Hibrit senaryolarda verilerinizi Graph üzerinden expose etmeniz gerekiyor.
Coding agent’lar gerçekten SPFx geliştirmede işe yarıyor mu?
Bence evet, son altı ayda ciddi bir sıçrama öldü. GitHub Copilot ve Claude, SPFx scaffolding ve component yazımında artık bayağı olgun. Karmaşık permission senaryolarında ya da tenant’a özel konfigürasyonlarda hâlâ insan müdahalesi gerekiyor, ama mesela temel kod üretiminde işin büyük kısmını rahatlıkla halledebiliyorlar.
Kaynaklar ve İleri Okuma
Microsoft 365 Developer Blog: Introducing SharePoint Copilot Apps
SharePoint Framework Overview — Microsoft Learn
Kendi deneyimimden konuşuyorum, Microsoft 365 Copilot Extensibility Documentation
Model Context Protocol (MCP) Resmî Sitesi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments