Power BI Yenileme Hatası: Gateway ve Kimlik Sorunları Çözümü (2026)

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-100 / MS-102 / AZ-104 sertifikalı danışmanlar · 25+ yıl saha deneyimi

Özet (TL;DR): Power BI'da zamanlanmış yenileme (scheduled refresh) aniden durursa üç sebepten biri neredeyse kesin: veri ağ geçidi (gateway) çevrimdışı/eski sürümde, kimlik bilgileri (credentials) süresi dolmuş ya da değişmiş, ya da rapor Microsoft'un resmi sınırlarından birine (2 saatlik zamanlanmış yenileme süresi, 10 GB sıkıştırılmamış veri, 4 üst üste başarısızlıkta otomatik devre dışı kalma) takılmıştır. Microsoft'un resmi sorun giderme dokümantasyonuna göre (son güncelleme 2026-09-24) en sık görülen hata kodu DM_GWPipeline_UnknownError'dur ve çoğunlukla ağ geçidi sürümünün eski olmasından kaynaklanır — Microsoft yalnızca son 6 aylık sürümü destekler. Bu yazıda hata mesajlarını, kök nedenleri ve adım adım çözümü; Logo/Netsis/Mikro gibi yerli ERP'lerle çalışan ortamlara özel notlarla birlikte veriyoruz.

Power BI panonuz (dashboard) her sabah patronun masasına yanlış ya da eksik rakamla mı düşüyor? Ücretsiz Power BI/veri ağ geçidi sağlık kontrolü isteyin — kurulumunuzu 1 iş günü içinde inceleyip raporlayalım.

Belirtiler: Power BI yenileme hatası nasıl görünür?

Sorun genelde üç şekilde fark edilir. Birincisi, rapor ekranında turuncu bir uyarı çubuğuyla "Yenileme başarısız oldu" mesajı görürsünüz. İkincisi, kayıtlı olduğunuz e-posta adresine Power BI'dan otomatik bir "yenileme başarısız" bildirimi gelir. Üçüncüsü — ve en tehlikelisi — hiçbir uyarı görmezsiniz, çünkü zamanlanmış yenileme art arda 4 kez başarısız olduğunda Power BI onu sessizce devre dışı bırakır; rapor günlerce eski veriyle açılmaya devam eder ve kimse fark etmez, ta ki bir toplantıda rakamlar tutmayana kadar.

Ayrıntıları görmek için anlam modelinin (semantic model — Power BI'ın raporun arkasındaki veri katmanına verdiği ad) ayarlar sayfasından Yenileme geçmişi'ni (Refresh history) açtığınızda genelde şu tam hata metinlerinden biriyle karşılaşırsınız:

• Unable to Connect. Details: "Unknown error in data gateway" — ayrıntılarda DM_GWPipeline_UnknownError kodu görünür.
• We reached the data gateway, but the gateway can't access the on-premises data source. — ayrıntılarda DM_GWPipeline_Gateway_DataSourceAccessError kodu.
• GatewayNotReachable — kimlik bilgilerini kaydetmeye çalışırken çıkar.
• Your data source can't be refreshed because the credentials are invalid. — bilgiler doğru olsa bile çıkabilen kafa karıştırıcı bir hata.
• Data source refresh is disabled because at least one data source is missing credentials.
• The received uncompressed data on the gateway client has exceeded the limit.

Hata kodu → anlam eşleme tablosu

Hata / Kod	Ne anlama gelir	İlk bakılacak yer
DM_GWPipeline_UnknownError	Ağ geçidi veri kaynağına ulaşamıyor; çoğunlukla eski sürüm veya sunucu erişilemez durumda	Ağ geçidi sürümü + hedef sunucudan bağlantı testi
DM_GWPipeline_Gateway_DataSourceAccessError	Ağ geçidi çalışıyor ama on-premises kaynağa (SQL/dosya sunucusu vb.) giremiyor	Kimlik bilgisi + hedef sunucunun kullanıcı/izin listesi
GatewayNotReachable	Ağ geçidi bulut servisine bağlanamıyor	Ağ geçidi Windows servisi çalışıyor mu, sürüm güncel mi
Kimlik bilgileri geçersiz (credentials invalid)	Parola değişmiş, önbellek eski, veya bağlayıcının isteğe bağlı bir parametresi eksik	Kimlik bilgilerini yeniden gir + tarayıcı önbelleğini temizle
DM_GWPipeline_Gateway_SpooledOperationMissing	Yenileme sürerken ağ geçidi servisi yeniden başlamış (Windows güncellemesi, çökme)	Ağ geçidi sunucusunun yeniden başlama geçmişi
Zamanlanmış yenileme süresi doldu (2 saat)	Model / sorgu 2 saatte bitmiyor (Premium'da 5 saat)	Model boyutu, artımlı (incremental) yenileme
10 GB sıkıştırılmamış veri sınırı	Tek tablo segmenti işlenirken bellek/veri sınırı aşılıyor	Gereksiz sütun/satırları azalt, DirectQuery değerlendir

Power BI'ın genel yetenekleri ve lisans yapısı hakkında bir arka plan gerekiyorsa Power BI nedir, nasıl çalışır rehberimize göz atabilirsiniz — bu yazı doğrudan yenileme sorunlarına odaklanıyor.

Hızlı tanı: İlk 10 dakikada kontrol edilecekler

Uzun bir kök neden avına girmeden önce Microsoft'un resmi kılavuzunun da önerdiği üç temel kontrolü yapın; sorunların büyük kısmı burada çözülür:

1. Ağ geçidi sürümü güncel mi? Yönetim portalında (Power BI hizmeti → Ayarlar → Bağlantıları ve ağ geçitlerini yönet) sürüm numarasına bakın; Microsoft yalnızca son 6 aylık sürümü destekler — 2026-09 itibarıyla en güncel sürüm Ağustos 2026 (3000.330) yayınıdır. Daha eskiyse önce onu güncelleyin; bağlantı sorunlarının önemli bir kısmı zaten aylık güncellemelerle kapanıyor.
2. Rapor için bir ağ geçidi seçili mi? Anlam modeli ayarlarında "ağ geçidi" bölümü boşsa, veri kaynağı değişmiş ya da hiç tanımlanmamış demektir.
3. Yenileme geçmişi ne diyor? Tam hata metnini kopyalayın — yukarıdaki tabloyla eşleştirin, tahmin yürütmeyin.

Bunlardan sonuç alamazsanız ağ geçidi makinesinde Olay Günlükleri > Uygulama ve Hizmet Günlükleri > On-premises data gateway Service yolunu açıp aynı zaman damgasındaki hatayı arayın; genelde kullanıcı arayüzündeki genel mesajdan çok daha ayrıntılı bir iç hata verir.

Kök neden analizi: en sık 5 sebep

Saha tecrübesi ve Microsoft'un resmi sorun giderme sayfası birlikte değerlendirildiğinde, yenileme hatalarının büyük çoğunluğu şu beş nedenden birine iniyor:

1) Ağ geçidi sürümü eski ya da servis çökmüş

Ağ geçidi ayda bir güncelleniyor ve Microsoft yalnızca son altı sürümü destekliyor. Windows güncellemesi sonrası sunucu yeniden başladığında ağ geçidi servisi otomatik açılmamışsa ya da eski bir sürümde kalmışsa GatewayNotReachable ya da DM_GWPipeline_UnknownError görürsünüz.

2) Kimlik bilgisi (credentials) süresi dolmuş veya değişmiş

Şirket parola politikası gereği parola değiştiyse, ya da veri kaynağı Microsoft Entra ID (kimlik doğrulama servisi) üzerinden OAuth ile bağlanıyorsa (SharePoint Online, Dynamics gibi) — bu token yaklaşık 1 saatte süresi dolan geçici bir erişim anahtarıdır ve Power BI'ın veri yüklemesi 1 saati geçerse yenileme kimlik hatasıyla başarısız olabilir.

3) Ağ / port erişimi kesilmiş

Ağ geçidi, buluta Azure Relay adlı bir aracı üzerinden 443 numaralı porttan (standart HTTPS trafiği) bağlanır. Güvenlik duvarı kuralı değiştiyse, proxy sunucu araya girdiyse ya da bir ağ segmentasyonu projesinde bu port kapatıldıysa ağ geçidi "canlı" görünmeyi keser.

4) Model / sorgu resmi sınırları aşıyor

2 saatlik zamanlanmış yenileme süresi (Premium'da 5 saat), 1 GB'lık sıkıştırılmış model sınırı, tablo başına 10 GB sıkıştırılmamış veri sınırı — bunlar büyüyen bir şirketin genelde 1-2 yıl içinde çarptığı duvarlardır. Rapor başta sorunsuz çalışır, veri hacmi arttıkça sessizce zaman aşımına düşmeye başlar.

5) Kapasite (Premium/Fabric) tıkanıklığı

Premium kapasitede aynı anda çok fazla model yenileniyorsa Power BI bazı yenilemeleri kasıtlı olarak erteler ("throttling"); hata bir bağlantı sorunu değil, kapasite yoğunluğu sorunudur.

Adım adım çözüm (en kolaydan en zora)

Aşağıdaki sırayla ilerleyin — her adım bir öncekinin işe yaramadığı durumda uygulanır, hepsini aynı anda yapmaya çalışmayın:

1. Ağ geçidini güncelleyin. En güncel sürümü indirin ve kurun; kurulum mevcut yapılandırmayı korur. Tek başına en çok sorunu çözen adım budur.
2. Windows servisini yeniden başlatın. Ağ geçidi sunucusunda "On-premises data gateway service" servisini yeniden başlatın; kısa bir bağlantı kopukluğu sonrası servisin kendini toparlamaması sık görülen bir durumdur.
3. Kimlik bilgilerini yeniden girin. Anlam modeli ayarlarında ilgili veri kaynağının kimlik bilgilerini silip yeniden girin. Hâlâ "geçersiz" diyorsa tarayıcı önbelleğini temizleyip https://app.powerbi.com?alwaysPromptForContentProviderCreds=true adresinden zorla yeniden kimlik doğrulaması yapın — bu, Microsoft'un resmi geçici çözümüdür.
4. Ağ geçidi kayıtlarını (event logs) inceleyin. Yukarıdaki hata kodunu ağ geçidi sunucusundaki olay günlüğünde arayın; genelde hedef sunucu adı/veritabanı adı uyuşmazlığı gibi tam bir ayrıntı verir.
5. Sunucu/veritabanı adı eşleşmesini doğrulayın. Power BI Desktop dosyasındaki sunucu adıyla ağ geçidinde tanımlı veri kaynağının adı birebir aynı olmalı (IP kullandıysanız ikisi de IP olmalı, FQDN kullandıysanız ikisi de FQDN olmalı).
6. Ağ/güvenlik duvarı kontrolü yapın. Ağ geçidi sunucusundan 443 portu üzerinden *.servicebus.windows.net adreslerine giden trafiğin açık olduğunu doğrulayın; bir proxy varsa ağ geçidinin proxy ayarlarını kontrol edin.
7. Model boyutunu/karmaşıklığını azaltın. Zaman aşımı veya bellek hatası alıyorsanız gereksiz sütun/satırları kaldırın, artımlı (incremental) yenilemeyi devreye alın ya da çok büyük gerçek (fact) tablolar için DirectQuery'i değerlendirin.
8. Zamanlanmış yenilemeyi yeniden etkinleştirin. 4 art arda hatadan sonra Power BI yenilemeyi otomatik kapatır; kök nedeni çözdükten sonra ayarlar sayfasından manuel olarak tekrar açmanız gerekir — kendiliğinden geri gelmez.

Adımları tek başınıza denemek yerine kurulu ortamınızı bir seferde incelettirmek isterseniz Xen'in Azure ve veri altyapısı ekibiyle 15 dakikalık teknik görüşme ayarlayabilirsiniz.

Senaryoya özel dallar

Tek rapor mu, tüm kiracı mı etkileniyor?

Yalnızca bir rapor başarısızsa sorun o modelin veri kaynağı/kimlik bilgisindedir — yukarıdaki adımlar yeterlidir. Aynı ağ geçidine bağlı tüm raporlar aynı anda başarısız oluyorsa sorun ağ geçidi sunucusunun kendisindedir (servis çökmüş, sürüm sorunu, ağ kesintisi); tek tek rapor ayarlarıyla uğraşmak zaman kaybıdır, doğrudan ağ geçidi sunucusuna gidin.

Import mu, DirectQuery mi, Premium/Fabric kapasitesi mi?

Klasik "Import" modelinde veri Power BI'a kopyalanır ve yukarıdaki tüm sınırlar (2 saat, 10 GB, 1 GB model) geçerlidir. DirectQuery modelinde veri kopyalanmaz, her görüntüleme anında kaynağa sorgu atılır — bu durumda "yenileme" kavramı farklıdır, asıl darboğaz kaynak veritabanının performansıdır. Model büyüdükçe ve zaman aşımları sıklaştıkça, Premium ya da Fabric kapasitesine geçip anlam modeli ölçeklendirmesini (scale-out) devreye almak — yenileme yükünü ayrı bir kopyaya taşıyıp raporun okuma performansını etkilememesini sağlamak — kalıcı bir çözüm olabilir.

Masaüstü (Desktop) vs. bulut (Service) farkı

Power BI Desktop'ta "yenile" dediğinizde veri doğrudan bilgisayarınızdan çekilir, ağ geçidine ihtiyaç duymaz. Sorun yalnızca Power BI hizmetinde (bulutta) zamanlanmış yenilemede çıkıyorsa, neredeyse her zaman ağ geçidi veya kimlik bilgisi meselesidir — Desktop'ta rapor sorunsuz açılması ağ geçidi tarafını temize çıkarmaz.

Türkiye'ye özel: Logo, Netsis, Mikro ile Power BI ağ geçidi tuzakları

Türkiye'deki kurumların büyük kısmında Power BI'ın beslendiği kaynak bir bulut servisi değil, şirket içi bir Logo Tiger, Netsis Fusion ya da Mikro Fly SQL Server veritabanıdır — yani ağ geçidi burada süs değil, zorunlu bir bileşendir. Sahada en sık karşılaştığımız üç ek tuzak:

• Collation (harf sıralama) uyuşmazlığı: Türkçe karakterli (ç, ğ, ı, ö, ş, ü) ERP veritabanları genelde Turkish_CI_AS gibi bir collation kullanır; ağ geçidi sunucusundaki bağlantı ayarları veya Power Query birleştirme (join) adımları farklı bir collation varsayarsa satırlar sessizce eşleşmez, yenileme hata vermez ama rapor eksik/yanlış görünür.
• ERP'nin kendi arka plan işleriyle çakışma: Logo/Netsis gece toplu iş (batch) veya yedekleme çalıştırırken Power BI'ın zamanlanmış yenilemesi aynı saate denk gelirse veritabanı kilitlenir, yenileme DM_GWPipeline_Gateway_DataSourceAccessError ile başarısız olur — yenileme saatini ERP'nin gece işlerinden en az 1 saat uzağa alın.
• Tek makinede tek ağ geçidi, tek kişinin bildiği kimlik bilgisi: Küçük/orta ölçekli firmalarda ağ geçidi genelde muhasebe sunucusuna kurulur ve tek bir kişinin (çoğu zaman işten ayrılan eski BT sorumlusunun) hesabıyla yapılandırılmıştır. O kişi ayrıldığında hesap devre dışı kalır, yenileme "kimlik bilgisi geçersiz" hatasıyla durur — kurumsal (servis) hesap ile yapılandırma ve yedek ağ geçidi (gateway cluster) burada önemli bir sigortadır.

Kaynak veritabanının kendisi de bulut göçü gündeminizdeyse SQL Server'dan Azure SQL Managed Instance'a göç rehberimiz ağ geçidi bağımlılığını tamamen ortadan kaldırmanın adımlarını anlatıyor.

Bu üç nokta aynı zamanda KVKK'nın 6698 sayılı Kanun'un 12. maddesinde aradığı "gerekli teknik tedbir" başlığıyla da örtüşüyor: finansal ve kişisel veri taşıyan bir raporlama zincirinde tek kişiye bağlı, yedeksiz bir ağ geçidi hem operasyonel hem uyumluluk riski taşır. Xen'in Purview ve kimlik yönetimi ekibiyle bu zinciri KVKK açısından da gözden geçirebilirsiniz.

Yönetici tarafı kontroller

Ağ geçidi yöneticisiyseniz (genelde BT sorumlusu ya da dış hizmet sağlayıcınız) şu üç noktayı düzenli kontrol listesine alın:

• Küme (cluster) ve yük dengeleme: Kritik raporlar için tek makineye bağımlı kalmayın; ikinci bir ağ geçidi üyesi ekleyip yük dengelemeyi açmak, bir sunucu bakımdayken raporların durmasını engeller.
• Kullanıcı listesi: Her veri kaynağının "Kullanıcılar" sekmesinde kimlerin erişimi olduğunu ayda bir gözden geçirin; işten ayrılanları çıkarın.
• Sürüm takibi: Ağ geçidini otomatik güncellemeye açık tutun ya da aylık güncelleme takvimini bir hatırlatıcıya bağlayın — Microsoft yalnızca son 6 sürümü desteklediği için geride kalmak giderek daha riskli hale gelir.

Log / destek talebi hazırlığı

Yukarıdaki adımlar sonuç vermezse Microsoft'a destek talebi açmadan önce şunları hazırlayın — talebin çözüm süresini ciddi biçimde kısaltır:

1. Etkilenen anlam modelinin bağlı olduğu ağ geçidi küme adı (gateway cluster).
2. Küme kaç üyeden oluşuyor, yük dengeleme açık mı.
3. Ağ geçidi sunucusunda ek günlük kaydı (additional logging) etkinleştirilip dışa aktarılmış gateway logs paketi.
4. Yenileme geçmişinden tam hata metni ve zaman damgası (saat/dakika hassasiyetinde).

Önleyici kontroller

Sorunu bir daha yaşamamak için önerilen yöntemler şunlar: ağ geçidini otomatik güncellemeye açık bırakın; kritik raporlar için yedekli ağ geçidi kümesi kurun; büyüyen modellerde erken davranıp artımlı (incremental) yenilemeye geçin; yenileme saatini ERP'nin gece işleriyle çakışmayacak şekilde planlayın; ve en az ayda bir, sadece hata almayı beklemek yerine Yenileme geçmişi ekranına göz atarak "sessiz" başarısızlıkları (4 kez üst üste hata sonrası otomatik kapanan yenilemeler) yakalayın.

Benzer hatalar ve farkları

Power BI'ın kullandığı ağ geçidi, Power Automate ve Power Apps'in de kullandığı aynı alt yapıdır — yani bu yazıdaki ağ geçidi/kimlik bilgisi sorunları bir onay akışının şirket içi bir SQL tablosuna yazamamasında da aynı şekilde ortaya çıkabilir; çözüm mantığı birebir aynıdır. Buna karşılık Power BI Desktop'ta manuel yenileme hatası tamamen farklı bir konudur (M script/Power Query hatası, sürücü eksikliği) ve ağ geçidiyle ilgisi yoktur — ikisini karıştırmayın. Fabric kapasitesine geçmiş kurumlarda ise hata mesajları aynı kalsa da kök neden çoğunlukla kapasite/bellek yönetimidir, ağ geçidi değil.

Saha vakası: 60 kişilik bir üretim firmasında "sessiz" yenileme hatası

Aşağıdaki vaka anonimleştirilmiştir.

Durum: Yaklaşık 60 çalışanlı bir üretim/dağıtım firması, satış ve stok verilerini Netsis'ten çeken bir Power BI panosunu genel müdür ve satış ekibiyle paylaşıyordu. Ağ geçidi, üç yıl önce kurulan ve o günden beri güncellenmemiş bir sürümde, muhasebe sunucusunda çalışıyordu.

Karar noktaları:

• Yenileme geçmişinde art arda dört DM_GWPipeline_UnknownError kaydı bulundu — Power BI zamanlanmış yenilemeyi haftalar önce sessizce kapatmıştı, kimseye bildirim gitmemişti çünkü bildirim e-postaları ayrılan bir çalışanın adresine gidiyordu.
• Ağ geçidi sürümü kontrol edildi: desteklenen son altı sürümün çok gerisindeydi.
• Netsis'in gece kapanış (batch) işlemiyle yenileme saatinin çakıştığı, bunun da ayrı bir kilitlenme riski yarattığı tespit edildi.

Sonuç: Ağ geçidi güncellendi, bildirim listesi güncel BT sorumlusuna taşındı, yenileme saati Netsis'in gece işinden sonraya alındı ve yedekli (2 üyeli) bir ağ geçidi kümesi kuruldu. Pano tekrar güncel veriyle açılmaya başladı. Xen ekibinin rolü: tanı, sürüm güncelleme, zamanlama düzeltmesi ve yedekli mimari kurulumu. Ders: bir raporun "açılıyor olması" güncel olduğu anlamına gelmez — yenileme geçmişini düzenli kontrol etmeyen hiçbir kurum bunu erken fark edemez.

Sıkça Sorulan Sorular (SSS)

Power BI yenileme hatası aldığımda ilk 5 dakikada ne yapmalıyım?

Önce ağ geçidi sürümünü kontrol edin (yönetim portalı → Bağlantıları ve ağ geçitlerini yönet), sonra yenileme geçmişinden tam hata metnini okuyun. Çoğu vaka bu iki adımda netleşir.

"Kimlik bilgileri geçersiz" hatası alıyorum ama parolayı doğru giriyorum, neden?

Ağ geçidi bağlantıyı test ederken bazı bağlayıcılarda (ör. Snowflake) isteğe bağlı gelişmiş parametreleri atlar; bu yüzden test adımı hata verse bile gerçek yenileme başarılı olabilir. Yenileme fiilen çalışıyorsa bu test hatasını görmezden gelebilirsiniz.

Zamanlanmış yenileme neden kendiliğinden durdu, kimse dokunmadı?

Power BI, art arda 4 başarısız denemeden sonra zamanlanmış yenilemeyi otomatik olarak devre dışı bırakır. Kök nedeni çözdükten sonra ayarlar sayfasından elle tekrar açmanız gerekir.

Ağ geçidini kaç günde bir güncellemeliyim?

Microsoft ayda bir güncelleme yayınlıyor ve yalnızca son 6 sürümü destekliyor. Aylık güncellemeyi bir takvim hatırlatıcısına bağlamak ya da otomatik güncellemeyi açık bırakmak pratik çözümdür.

Netsis/Logo/Mikro'dan beslenen bir Power BI raporunda en sık ne yanlış gidiyor?

Sahada en sık üç neden: eski ağ geçidi sürümü, yenileme saatinin ERP'nin gece kapanış işiyle çakışması ve Türkçe karakterli veritabanlarında collation (harf sıralama) uyuşmazlığı.

Yenileme sürekli 2 saatte zaman aşımına uğruyor, kapasiteyi mi yükseltmeliyim?

İlk önce model boyutunu küçültmeyi (gereksiz sütun/satır temizliği, artımlı yenileme) deneyin; bu genelde kapasite yükseltmekten daha ucuz ve kalıcı bir çözümdür. Model gerçekten büyükse Premium/Fabric kapasitesi süreyi 5 saate çıkarır.

Sorunu kendimiz çözemezsek ne kadar sürede destek alabiliriz?

Xen Bilişim'e ulaştığınızda gateway loglarınızı incelemek ve ilk tanıyı vermek genelde 1 iş günü içinde mümkün oluyor; kök neden net olduğunda çözüm süresi sorunun türüne göre birkaç saatten birkaç güne değişebilir.

Sonuç: Power BI yenileme hataları çoğunlukla altyapı, veri modeli değil

Power BI'da yenileme hatalarının ezici çoğunluğu rapor tasarımından değil, onu ayakta tutan sessiz altyapıdan — güncellenmeyen bir ağ geçidi, süresi dolmuş bir kimlik bilgisi, gece kapanış işiyle çakışan bir zamanlama — kaynaklanır. Bu yazıdaki hata kodu tablosunu ve adım adım çözüm sırasını takip ederseniz vakaların büyük kısmını kendi ekibinizle, destek talebi açmadan çözebilirsiniz.

Türkiye'deki kurumlarda tabloyu asıl karmaşıklaştıran, Power BI'ın çoğunlukla bir bulut servisine değil Logo, Netsis ya da Mikro gibi şirket içi bir ERP veritabanına bağlı olması. Bu da ağ geçidini "kur, unut" bir bileşen değil, ERP'nin kendisi kadar bakım gerektiren bir parça haline getiriyor — sürüm takibi, yedekli kurulum ve zamanlama planlaması olmadan er ya da geç aynı sessiz hatayla karşılaşırsınız.

Kurulumunuzu kendi ekibiniz yönetiyor ama arada bir ikinci bir göz ister misiniz, yoksa sıfırdan yedekli bir mimari mi kurulmalı — Xen'in Microsoft 365 ve veri ekibiyle bu kararı birlikte netleştirebilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Power BI ve veri raporlama altyapısını uçtan uca kuruyor, izliyor ve sorun anında hızla müdahale ediyoruz. İletişim sayfamızdan bize ulaşın.