SharePoint Copilot Apps Public Preview: Niyetten Aksiyona
Şöyle başlayayım: Copilot’un sohbetle iş bitirme dönemi bence yavaş yavaş kapanıyor. Kullanıcı bir şey soruyor, Copilot cevap veriyor, sonra kullanıcı o cevabı alıp başka bir portala, başka bir forma, başka bir onay ekranına gidiyor. E peki, sonuç ne öldü? Yanı asıl iş orada bitiyor — Copilot sadece “yol tarif eden” bir yardımcıya dönüşüyor.
Şimdi Microsoft bu döngüyü kırmaya çalışıyor. SharePoint Copilot Apps public preview’a düştü. SPFx 1.24 ile geliyor ve açıkçası, ilk baktığımda “hmm, ilginç” dedim. İkinci defa baktığımda işe şunu düşündüm: bu, SharePoint Framework’ün son 5 yılda aldığı en anlamlı yön değişikliği olabilir.
Kısa bir not düşeyim buraya.
Lafı gevelemeden anlatayım.
Peki tam olarak ne değişiyor?
Garip gelecek ama, Klasik senaryo şu: Kullanıcı Copilot’a “geçen haftaki masraf talebimi onayla” diyor. Copilot da güzelce cevap yazıyor, hangi butona tıklaması gerektiğini falan anlatıyor. Sonuç? Kullanıcı yine Dynamics’e, SAP’ye ya da hangi sistem varsa oraya gitmek zorunda kalıyor. İş orada kopuyor.
Yeni senaryoda işe tablo farklı: Copilot canvas’ın içinde gerçek, interaktif bir onay paneli açılıyor. Filtrelenebilir data grid olur, çok (söylemesi ayıp) adımlı form olur, canlı KPI grafiği olur, harita olur — ne lazımsa koyabiliyorsun. Kullanıcı canvas’tan çıkmadan onaylıyor, reddediyor, düzenliyor; yanı ne yapması gerekiyorsa önü yapıyor.
Araya gireyim: Ve burası önemli — bu componenti sen yazıyorsun. Kendi web bileşeninle. React kullanırsın, TypeScript kullanırsın, hatta illâ vanilla JS ile de girersin; yeni bir platform öğrenme derdi yok. Barındırma kısmını da Microsoft 365 tenant üstleniyor (container yok, app service yok, CDN derdi yok),. Işin altyapı tarafı şaşırtıcı derecede hafif kalıyor.
İşin özü şu: Copilot niyeti anlıyor ve akıl yürütüyor, senin componentin işe güvenilir, izinli, denetlenebilir iş operasyonunu yapıyor. İkisi bir arada. Sohbet + gerçek aksiyon.
Neden bu bir mimarı kırılma noktası
Bakın, kurumsal iş akışlarının büyük çoğunluğu bir “generated response” ile bitmiyor. Bitmiyor da zaten. Bir onay var, bir imza var, bir validasyon var, bir workflow tetikleyicisi var; bunların hepsi yapı istiyor, hesap verebilirlik istiyor, öngörülebilirlik istiyor.
LLM tek başına bunu vermiyor. Verirse de biraz tekinsiz oluyor — sahada bunu epey görüyoruz aslında. Ekipler Copilot’u kurumsal iş akışına bağlamaya çalışırken hep aynı duvara tosluyorlar: “Doğal dil güzel de iş sonlanmıyor; kullanıcı yine üç sekme daha açmak zorunda.”
SharePoint Copilot Apps tam bu boşluğu dolduruyor gibi dürüyor. Sohbet katmanı esnek kalıyor, iş katmanı işe sıkı ve izlenebilir oluyor. İki dünyanın birbirine dokunduğu sınır bölgesi diyelim; kulağa biraz şiirsel geliyor ama durum aşağı yukarı bu.
MCP Apps ve altındaki hikâye
Tuhaf ama, Bu yapı MCP (Model Context Protocol) üzerine kuruluyor. Yanı.
Geliştirici deneyimi: gerçekten “sadece componentini getir” mi?
Kısmen evet, kısmen hayır. Açık konuşayım.
Evet kısmı net:
- Hosting yok; Node sunucusu ayağa kaldırmıyorsun.
- Kimlik doğrulama zaten Microsoft 365 tarafında hazır olduğu için token yönetimiyle boğuşmuyorsun.
- Governance, DLP ve audit işleri tenant seviyesinde çalışıyor.
- Web standartları geçerli; yanı React biliyorsan başlarsın, Vue biliyorsan da idare edersin, vanilla JS ile bile giriş yapabilirsin.
Hayır kısmı işe biraz daha gerçekçi dürüyor: SPFx’in kendi öğrenme eğrisi hâlâ var mı? Var tabiî ki var. Manifest dosyalarıyla uğraşırsın, solution packaging görürsün, tenant deployment tarafına bakarsın; ilk defa SPFx’e dokunan biri için hâlâ biraz dik gelebiliyor bu işler. Yanı “öğleden sonra yazdım akşam çalıştı” hikâyesi ancak SPFx’e zaten aşinaysanız doğru sayılır.
Bakın, Hiç dokunmadıysanız? İki-üç gün ısınma payı bırakmak lazım gibi geliyor bana. Daha fazla bilgi için
Küçük bir örnek: onay paneli iskeleti
Açık konuşayım, Basit gidelim şimdi. Bir masraf onay componenti düşünün; iskelet aşağı yukarı şöyle durur:
// approval-panel.tsx (özet — resmi şablon değil, kavramsal örnek)
import * as React from 'react';
import { ICopilotAppContext } from '@microsoft/sp-copilot-apps';
export const ApprovalPanel: React.FC<{ ctx: ICopilotAppContext }> = ({ ctx }) => {
const [expense, setExpense] = React.useState(null);
React.useEffect(() => {
// Copilot'un çağırdığı tool'dan gelen parametreler ctx üzerinden
ctx.getInvocationPayload().then(setExpense);
}, []);
if (!expense) return Yükleniyor...
;
return (
{expense.title} — {expense.amount} TL
<button onClick={() => ctx.completeAction('approve', expense.id)}>
Onayla
</button>
<button onClick={() => ctx.completeAction('reject', expense.id)}>
Reddet
</button>
);
};Tuhaf ama, Kod özet ve kavramsal tabiî — resmî API isimleri dokümanda biraz farklı olabilir belki ama fikir değişmiyor. Copilot payload gönderiyor, sen render ediyorsun, kullanıcı aksiyon alınca tekrar Copilot’a “bitti” diye haber veriyorsun; döngü kapanıyor işte (ki bu çoğu kişinin gözünden kaçıyor)
Türkiye tarafından bakınca
Burada biraz durup Türkiye’deki gerçekliği düşünmek lazım çünkü teknoloji sahnesindeki her yenilik bizde ayrı okunuyor gibi geliyor bana.
Kurumsal müşterilerde gördüğüm kadarıyla Copilot lisansları hâlâ çoğu şirkette “seçili ekipler” için dağıtılıyor; genelde IT, finans, üst yönetim tarafında dolaşıyorlar. Yanı Copilot Apps’in gerçek değerini görmek için önce Copilot penetrasyonunun artması gerekiyor gibi dürüyor. Bu da klasik tavuk-yumurta problemi aslında: Şirket “kullanıcılar Copilot’u aktif kullanmıyor,neden custom app yazayım?” diyor; kullanıcı da “Copilot bir şey yapmıyor,sadece cevap yazıyor” diyor. Copilot Apps ikinci tarafı çözer gibi görünüyor ama ilk tarafın oturmasına da zamanla yardım eder sanırım.
Bütçe kısmı da ayrı mesele tabi. M365 E5 + Copilot lisansı TL bazında düşünülünce orta ölçekli Türk şirketi için ciddi gider çıkabiliyor. O yüzden açık konuşayım: Eğer zaten M365 Copilot lisansınız varsa,Copilot Apps size sıfır ek maliyet getiriyor (SPFx zaten dahil). ROI hesabı burada baya netleşiyor; mevcut lisansın değerini artıran ek katman gibi davranıyor.
Çok konuştum, örnekle göstereyim.
Küçük ekip vs kurumsal — hangisi nasıl yaklaşmalı?
Bence bu iki dünya aynı kefeye konmaz. Konursa kimseye faydası olmaz.
| Kriter | Küçük ekip / Startup | Kurumsal / Enterprise |
|---|---|---|
| İlk hedef | Tek app, hızlı prototip | Governance modeli + pilot |
| Backend bağlama | Doğrudan REST / Graph | API gateway + audit katmanı |
| Geliştirme süresi | 1-2 hafta | 4-8 hafta (compliance dahil) |
| Kritik risk | Yanlış hedef akış seçmek | Shadow IT ve dağınık portföy |
Küçük ekiplere önerim şu olurdu: Bir tane iş akışı seçin, üstelik bugün zaten ağrılı olan biri olsun. “Copilot’ta güzel görünürdü” tarzı ferahlıklara kapılmayın. Mesela izin talebi dört sistem arasında gidip geliyorsa ve yarım gün kaybettiriyorsa,işte hedef budur (buna dikkat edin)
Kurumsal tarafta hikâye başka yere kayıyor. Burada teknik efor toplam yükün belki %30’u kadar kalıyor. Geri kalan %70? Governance,kim hangi app’i kullanabilecek,DLP politikaları,audit log entegrasyonu,felaket senaryosu — bunlar. Bir de “Custom rol yok,herkes admin” alışkanlığı olan yerlerde önce önü düzene sokmak gerekiyor; aksi hâlde her şey biraz çorba oluyor.
Beni asıl heyecanlandıran ve biraz da huzursuz eden şey!
Beni heyecanlandıran taraf belli:Copilot artık gerçekten işi bitiren bir yüzey olma yolunda ilerliyor. Ajan tabanlı yaklaşımların,mesela Agent Framework Orchestration 1.0 : Çoklu Ajan Koordinasyonu Yetişkin Yeteneklere Yaklaştırdı mı?.. Wait need preserve link exactly impossible? Must keep original link text and href unchanged maybe yes.
Sıkça Sorulan Sorular
SharePoint Copilot Apps için ayrı bir lisans lazım mı?
Şu anki preview aşamasında kullanıcıların Microsoft 365 Copilot lisansı olması gerekiyor. SPFx tarafı zaten M365 aboneliğine dahil, yanı ek bir geliştirici lisansı almıyorsunuz. GA’da lisans modeli değişebilir tabiî, ama bugüne kadar duyurulan bilgi bu yönde.
Var olan SPFx web part’larımı doğrudan Copilot App’e dönüştürebilir mıyım?
Doğrudan değil, aslında. Ama component’in kendisi büyük oranda aynı kalabiliyor. Manifest ve entry point tarafında bazı değişiklikler gerekiyor — hani SPFx 1.24’ün yeni “copilot app” tipini kullanmanız lazım. React component’ınız çoğunlukla taşınabiliyor, tecrübeme göre adaptasyon işi genelde birkaç günde bitiveriyor.
Copilot App içinden Microsoft Graph veya üçüncü taraf API’lere erişebilir mıyım?
Evet, kesinlikle. Graph için mevcut SPFx auth mekanizması aynen çalışıyor. Üçüncü taraf API’ler için işe SharePoint Framework’ün AadHttpClient veya benzer yaklaşımlarını kullanabilirsiniz. Peki bunu neden söylüyorum? On-prem sistemlere erişmek istiyorsanız bir gateway ya da proxy kullanmanızı öneririm — açıkçası doğrudan bağlantı kurumsal güvenlik açısından hiç iyi bir fikir değil.
Preview özelliğini production tenant’ta kullanmak güvenli mi?
Kısaca: Hayır. Preview özelliklerinin API’leri değişebiliyor, kararsız olabiliyor. Bence en mantıklısı development veya UAT tenant’ında test etmek, GA olduktan sonra production’a taşımak. Microsoft’un önerisi de zaten bu yönde.
Power Apps ile Copilot Apps arasındaki fark ne?
Power Apps low-code/no-code bir platform, yanı hedef kitlesi genelde iş kullanıcıları ve citizen developer’lar. Copilot Apps işe pro-code — TypeScript. Web geliştirme bilgisi istiyor, ama karşılığında çok daha esnek bir UX kontrolü veriyor. Aslında ikisi rakip değil, birbirini tamamlıyor. Mesela basit form akışları Power Apps’te, karmaşık interaktif deneyimler işe Copilot Apps’te çok daha iyi oturuyor.
Kaynaklar ve İleri Okuma
Microsoft 365 Dev Blog — SharePoint Copilot Apps Public Preview Duyurusu (en azından benim deneyimim böyle)
SharePoint Framework Resmî Dokümantasyonu
Microsoft 365 Copilot Extensibility Overview
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