Obsah ověřen k 5. listopadu 2026
Seznam požadavků roste několik let bez potíží. Pak se přestane otevírat jeden pohled, řazení zobrazí chybu a automatizace vrací podezřele málo záznamů. V nastavení přitom vidíte jen několik tisíc položek. Než začnete mazat historii, zjistěte, které omezení vás skutečně zastavilo.
SharePoint Online nemá kapacitní strop 5 000 položek na seznam. Toto číslo označuje List View Threshold, tedy ochranu náročných databázových operací. Seznam může obsahovat až 30 milionů položek, ale taková kapacita nezaručuje, že libovolný pohled, filtr nebo tok načte všechna data. Servisní limity SharePointu a popis chyby prahové hodnoty řeší odlišné vrstvy.
Tento postup je určen pro SharePoint Online a Microsoft Lists nad stejnou platformou. Nastavení farmy SharePoint Serveru do něj nepřenášejte.
Tři čísla, která je potřeba oddělit
| Vrstva | Na co se ptá | Co sledovat při diagnostice |
|---|---|---|
| Celková kapacita seznamu | Kolik záznamů smí být uložených | Počet položek; není totožný s náročností dotazu |
| List View Threshold | Jakou operaci nad daty se služba pokouší provést | Index, selektivitu filtru, řazení a další části pohledu |
| Rozsah načteného výstupu | Kolik řádků dostal uživatel nebo automatizace | Stránkování, Top Count, nastavení konektoru a kontrolu úplnosti |
Zmenšení počtu řádků na stránce řeší třetí vrstvu. Pokud si dotaz pro jejich nalezení musí nejprve poradit s příliš širokou množinou, nemusí tím chyba zmizet. Podobně samotný nákup dalšího prostoru v GB nemění způsob filtrování seznamu.
Pro úspěšnou opravu proto nestačí poznámka „seznam má 12 tisíc řádků“. Potřebujete vědět, kterou operaci se uživatel pokusil provést. Otevření výchozího pohledu, seřazení sloupce a běh Power Automate jsou tři samostatné testy.
Index potřebuje dostatečně úzký filtr
Index pomáhá najít záznamy podle sloupce bez zbytečného procházení celé množiny. Jeho existence ale neznamená, že každá hodnota ve sloupci vrací malé množství dat. Sloupec Stav může být indexovaný a přesto mít desítky tisíc položek se stejnou hodnotou.
Microsoft doporučuje zvolit jako první rozhodující filtr indexovaný sloupec, který vrací méně než prahovou hodnotu. Další podmínky mají výsledek zužovat; logika OR ho obvykle rozšiřuje. Ani indexovaný lookup sloupec není řešením překročení tohoto prahu. Pravidla filtrování pohledů jsou přesnější než obecná rada „zaindexujte všechny sloupce“.
Nejprve proto změřte rozdělení hodnot. Provozní seznam může být dobře dělitelný podle měsíce, oddělení nebo aktivní fáze procesu. Vyberte pole, které uživatel chápe a které se při zakládání položek spolehlivě vyplňuje. Prázdný nebo nekonzistentní klíč sice může být technicky indexovaný, ale provozně bude filtr nepředvídatelný.
Model: proč rok nestačí, ale stav už ano
Představme si hypotetický seznam 60 000 požadavků. Následující počty jsou vstupy našeho příkladu, nikoli měření konkrétní firmy.
| Kandidát pro první filtr | Počet odpovídajících položek | Podíl seznamu | Závěr pro návrh |
|---|---|---|---|
| Rok = 2026 | 14 000 | 23,3 % | Pro tento samostatný filtr příliš široká množina |
| Oddělení = Obchod | 8 000 | 13,3 % | Rozdělení podle oddělení samo nestačí |
| Stav = Otevřeno | 3 200 | 5,3 % | Vhodný kandidát pro provozní pohled při současném počtu |
| Období = 2026-10 | 1 400 | 2,3 % | Vhodný kandidát pro měsíční kontrolu |
Pokud uživatel hledá otevřené požadavky obchodu, je rozumný návrh začít ověřeným indexovaným filtrem Otevřeno a dále zužovat na oddělení. Z výsledné velikosti 900 řádků nelze zpětně usoudit, že by libovolné pořadí nebo podoba dotazu fungovaly stejně.
Uvedené počty také nevytvářejí univerzální záruku funkčnosti. V reálném pohledu musíte otestovat řazení, seskupování a zobrazované sloupce. Model slouží k výběru dobrého kandidáta; jeho správnost potvrzuje až skutečné chování služby.
Růst dat může znehodnotit původní filtr
Přidejme vlastní plánovací předpoklad: počet otevřených požadavků roste čistě o 250 za měsíc. Po sedmi měsících má filtr 3 200 + 7 × 250 = 4 950 položek. Po osmi měsících už 5 200. Index zůstane stejný, ale původně vhodný návrh ztratí rezervu.
Pro tento model bychom nastavili interní upozornění při 4 000 otevřených záznamech a začali připravovat další dělení. Hranice 4 000 je naše provozní rezerva, nikoli další limit Microsoftu. Skutečný termín revize odvoďte z vašeho růstu a sezónnosti. U seznamu reklamací se prosincová špička nemusí podobat ostatním měsícům.
Tím získáte užitečnější plán než pravidlo „jednou ročně seznam zarchivujeme“. Víte, který filtr se blíží problému, kdo za něj odpovídá a podle jakého signálu se návrh změní.

Jak opravit konkrétní pohled
Než upravíte společný výchozí pohled, vytvořte jeho pracovní kopii a zaznamenejte původní nastavení. Doporučujeme tento postup:
- Zapište přesný text chyby, název pohledu, počet položek a akci, která problém vyvolala.
- V nastavení seznamu otevřete indexované sloupce a ověřte pole, podle kterého chcete filtrovat. Pokud se index teprve vytváří, test neopírejte o předpoklad, že už je hotový.
- Vyberte konkrétní hodnotu s prokazatelně malým počtem odpovídajících záznamů a nastavte ji jako rozhodující filtr.
- Pro základní test odstraňte seskupování, součty a zbytečné řazení; ponechte jen potřebné sloupce.
- Otevřete pohled pod běžným uživatelským účtem. Další prvky vracejte po jednom a po každém kroku opakujte test.
- Zkontrolujte více hodnot filtru včetně největší skupiny. Malý tým ani nejklidnější měsíc nejsou reprezentativní zátěžový případ.
Microsoft ve správě velkých seznamů a knihoven doporučuje při chybách zjednodušit řazení, seskupování, součty a výběr sloupců. U automaticky vytvářených indexů navíc může větší seznam vyžadovat dokončení práce na pozadí.
Neměňte současně filtr, oprávnění i strukturu knihovny. Když provedete pět změn najednou, těžko později poznáte, která byla potřebná. Pracovní kopie pohledu vám dovolí doložit opravu bez ztráty původního nastavení.
Složky pomáhají jen při správném rozsahu
Složka může být praktická přístupová hranice, pokud uživatel běžně pracuje v konkrétním projektu nebo období. Pohled přes všechny položky bez složek však tuto výhodu nemusí zachovat. Dokumentace upozorňuje také na vliv položek v koši na vyhodnocení některých filtrů. Chování složek a koše proto zvažte při hledání příčiny, ne jako pokyn k okamžitému mazání.
Vybírejte strukturu podle pracovního procesu. Pokud uživatel potřebuje každé ráno vidět všechny otevřené případy napříč roky, mechanické rozdělení do ročních knihoven mu může práci zhoršit. Nejdřív popište potřebný dotaz, teprve potom rozhodujte o přesunu dat. Historii nemažte jako vedlejší efekt opravy pohledu.

Power Automate musí prokázat úplnost výsledku
Pohled v prohlížeči může fungovat, zatímco navazující tok vynechá část položek. Akce Get items má ve výchozím nastavení návrat 100 položek. Microsoft popisuje také případ seznamu nad 5 000, kdy filtr bez správného stránkování nevrátí záznamy ležící mimo první část dat. Nastavení Limit columns by view omezuje sloupce; nepovažujte ho za automatické převzetí filtru pohledu. Dokumentace Get items a Get files tyto volby rozlišuje.
Pro tok tedy ověřte samostatně serverový Filter Query, Top Count, stránkování a rozsah složek. Zvýšení počtu načítaných záznamů není náhrada vhodného dotazu. A zelený stav běhu neprokazuje, že tok našel všechny očekávané položky.
Pro uvedený problém Get items otevřete nastavení akce a zapněte Pagination. Požadovaný rozsah zvolte podle skutečného výsledku, který má tok zpracovat. Nepokoušejte se řešit načtení celé velké historie jen zadáním Top Count nad 5 000; dokumentace tuto hodnotu omezuje. Potom ověřte výstup kontrolními položkami.
| Kontrolní vzorek pro akceptaci | Jaký výsledek očekáváte | Jakou chybu pomůže odhalit |
|---|---|---|
| Známá starší položka splňující filtr | Je přítomná podle ID | Omezený počáteční rozsah načítání |
| Novější položka se stejnými metadaty | Je také přítomná | Závislost na stáří či pořadí |
| Položka mimo filtr | Ve výstupu není | Chybně zapsanou podmínku |
| Skupina s předem ověřeným počtem | Souhlasí počet i vybraná ID | Tichou neúplnost nebo duplicity |
Tato kontrolní sada je redakční návrh testu, nikoli zabudovaná funkce Power Automate. Očekávaný počet zjistěte nezávislým ověřeným postupem; stejný chybný tok použitý dvakrát není nezávislá kontrola. U exportu pro fakturaci nebo pravidelných upozornění si uložte i datum testu a použitý filtr.
Co neopraví zvýšení licence ani přepínač v administraci
SharePoint Online nepodporuje změnu List View Threshold zákazníkem. Rady s Central Administration, Resource Throttling a časovým oknem pro náročné operace patří do prostředí SharePoint Server. Nákup vyšší sady Microsoft 365 není běžný způsob, jak si tento online práh zvýšit.
Pokud problém doprovází hlášení o plném prostoru, řešte ho odděleně. Náš článek Plný SharePoint: jak uvolnit místo vysvětluje kapacitu a verze souborů. Počet GB, počet položek a náročnost jejich výběru se mohou měnit nezávisle.
Při rozhodování o dalším řešení si položte konkrétní otázku: potřebujete operativně upravovat malou pracovní množinu, nebo opakovaně analyzovat kompletní historii? Druhý případ může vyžadovat jiný reportingový či datový návrh. Neodvozujte však nutnost migrace jen z toho, že seznam překročil pět tisíc řádků.
Pro audit připravte původní pohled, zamýšlené dotazy, počty položek podle hlavních filtrů a jeden příklad neúplného toku. Z těchto podkladů lze určit, zda stačí opravit přístup k datům, nebo už proces potřebuje změnu struktury.
Často kladené otázky
Musím po dosažení 5 000 položek založit nový seznam?
Ne automaticky. Nejprve určete, zda selhává konkrétní dotaz nebo zobrazení. Rozdělení dat má vycházet z procesu, oprávnění a používaných pohledů, nikoli pouze z tohoto čísla.
Stačí zobrazovat jen 50 řádků na stránce?
Nemusí. Stránka může obsahovat málo řádků, zatímco jejich výběr vyžaduje příliš širokou operaci. Ověřte index a selektivitu podmínky, která je vyhledává.
Proč nepomohl index sloupce Stav?
Zkontrolujte, kolik položek má vybraná hodnota. Pokud skoro celý seznam zůstává otevřený, nebude tento filtr dobrá hranice pro pracovní množinu. Ověřte i další prvky pohledu.
Může tok skončit úspěšně a přesto vrátit málo položek?
Ano. Úspěšné provedení akce není důkaz úplnosti. Testujte známá ID z různých částí seznamu a porovnávejte očekávaný počet s výsledkem.
Má smysl žádat o zvýšení prahu v SharePoint Online?
Postup pro zvýšení prahu ve správě farmy je určen pro SharePoint Server. V Online navrhujte vhodné indexy, filtry a rozsahy; nepředpokládejte, že vyšší licence odemkne změnu limitu.








