Copilot Studio says it cannot find the item at row 3,000

23 October 2026

Tags: Relational databasesAIDesktopCommand line

The service desk analyst’s message is short. “The asset bot says LT-03000 does not exist. It is in the list. I can see it. Who has that laptop?” The agent is a Copilot Studio agent with the IT asset register as knowledge, a SharePoint list of about 4,600 items with the asset tag in Title, a model, an Assigned To person column, a Location lookup and a warranty end date. Asked about LT-00410 a minute earlier, it gave the right person, the right model and the right warranty date. Asked about the laptop that sits at item 3,000, it says there is no such asset and suggests checking the tag.

The list has not changed since yesterday. It is healthy, the item has no unusual permissions, and the same agent answers the next question correctly. This post explains why one item is visible and another is not, gives you a test that shows which rows your own agent can reach, and shows the route that puts every row in reach.

Why does Copilot Studio say an item in my SharePoint list does not exist?

Because the agent never saw it. A SharePoint list added as knowledge is not a table the agent reads row by row. Microsoft Learn’s page on adding SharePoint as a knowledge source says the selected lists are ingested into Dataverse and indexed to improve search results. When someone asks a question, the agent searches that index, takes back the items that match best, and writes an answer from them. If LT-03000 was not among the items that came back, the model has nothing to say about it, and “no such asset” is the most natural thing for it to write.

The second reason is a hard limit. The Copilot Studio quotas and limits page, dated 6 October 2026 and checked on 23 October, says that SharePoint list queries only return data from the first 2,048 rows. An asset register of 4,600 items is well inside the 35,000 rows the knowledge page warns about, so nothing at setup time tells you more than half of it is out of reach. Learn does not say what “first” is ordered by. On a list where items were added in order, item 3,000 is a likely casualty, and the test further down shows you where the line falls on your own list.

The cheat sheet of SharePoint list limits sets the 2,048 figure beside the other numbers that get quoted as “the list limit”, and the article on why Copilot cannot count the rows in your list covers what the same limit does to totals and averages. This post is about the single item that goes missing.

Copilot Studio is not returning all items, and search decides which

Even inside the first 2,048 rows, an item only reaches the model if the search ranks it highly enough for that question. Search ranks by how well an item’s text matches the words in the question. “Who has LT-00410?” matches an item whose Title is LT-00410 almost exactly, so it ranks first. “Who has the laptop that was swapped last Tuesday?” matches nothing in particular, so the search returns whichever items share the most words with it, and the answer is built from those.

That ranking step is where most of the surprises come from. A tag stored in the Title column and typed exactly is easy to match. Typed differently in the question (“LT 3000”, “laptop 3000”, “item 3000”), it may rank below a dozen unrelated items, and Microsoft does not publish how the list index weighs one column against another. A person column reaches the index as display text, so “Priya’s laptop” can match, but “laptops assigned to people in Finance” depends on whether “Finance” appears on the item at all. A Location lookup is text on the item, with none of the Locations list’s own columns behind it.

Copilot Studio also refuses some lists outright. The quotas page says lists with more than 12 lookup columns in the default view are not supported and that you cannot pick a list view as the knowledge source, so you cannot point the agent at a filtered view of current assets to get under the limit.

Copilot Studio gives inconsistent answers about the same list

Ask “who has LT-03000?” and then “who is LT-03000 assigned to?” and you can get two different answers, because they are two different searches. Small changes in wording change which items rank highest, and the model only ever sees the top of that ranking. With generative orchestration the agent may also rewrite the question before it searches, so the search that runs is not always the one the user typed.

The list changes under the agent too. Learn describes the list connection as real-time, which is good for freshness and means the same question an hour later can retrieve a different set of items. When the analyst says the bot “answered it yesterday”, both answers can be honest reports of what the search returned at the time.

None of this is a fault you can fix with a better prompt. A search is built to find the few most relevant items, and an asset question by tag needs one exact item every time.

Why does Copilot Studio only return 10 records?

The phrase people search for is “only returns 10 records”, and the symptom is real: ask for every laptop due for replacement this quarter and the agent lists a handful, then stops or suggests exporting to Excel. We could not find a published figure on Microsoft Learn for how many list items a single knowledge search hands to the model, so do not plan around 10 or any other number. Plan around the shape of the question.

A question whose answer is one item, or a few, suits search. A question whose answer is “all the items where”, whether that is 40 laptops or 400, needs something that reads every row and filters them, and search does not do that. The count article covers the same mismatch for totals; for listing items the result is a short list that looks complete and is not.

Agent Builder and a SharePoint list of 20,000 items

Agent Builder in Microsoft 365 Copilot handles lists differently, and its limit is the other number that turns up in searches. Learn’s Agent Builder knowledge page, dated 30 September 2026, allows one SharePoint list per agent, with up to 20,000 items and 50 MB of raw text. A list over either limit is truncated, and the agent notes the truncation in its answer, which is more than Copilot Studio tells you about its 2,048 rows. The Attachments column is not indexed, and choosing a site does not bring its lists with it.

The Microsoft 365 roadmap entry for list support in Agent Builder (item 561920, released in June 2026) adds a gap the Learn page does not spell out: lookup columns and list attachments are not supported yet. On the asset register that leaves the Location lookup out of the agent’s reach. A cap of 20,000 items holds the asset register comfortably, so Agent Builder can be the better choice for a single mid-sized list. It still answers through retrieval, so the ranking behaviour above applies once the list is large.

How do you test which rows your agent can see?

You do not have to take any of this on trust. Build a list where every item carries a value that cannot be guessed, point a test agent at it, and ask for items on both sides of row 2,048. This PnP PowerShell script creates a list of 3,500 items with a Title of “Row 0001” to “Row 3500”, a code made from a hash of the row number, and a Team choice spread evenly over four values:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/agent-test -Interactive -ClientId $env:PNP_CLIENT_ID
New-PnPList -Title "Row test" -Template GenericList
Add-PnPField -List "Row test" -DisplayName "Code" -InternalName "Code" -Type Text -AddToDefaultView
Add-PnPField -List "Row test" -DisplayName "Team" -InternalName "Team" -Type Choice -Choices "Red","Blue","Green","Amber" -AddToDefaultView

$teams = "Red","Blue","Green","Amber"
$sha = [System.Security.Cryptography.SHA256]::Create()
$batch = New-PnPBatch
foreach ($n in 1..3500) {
    $hash = $sha.ComputeHash([Text.Encoding]::UTF8.GetBytes("row-$n"))
    $code = -join ($hash[0..3] | ForEach-Object { $_.ToString("X2") })
    Add-PnPListItem -List "Row test" -Batch $batch -Values @{
        Title = "Row {0:D4}" -f $n; Code = $code; Team = $teams[$n % 4]
    }
}
Invoke-PnPBatch -Batch $batch

Before you start, open the list, show the ID column and check that Row 3000 has ID 3000. Note the codes on rows 0100, 2000, 2100 and 3000. In a new Copilot Studio agent with no other knowledge, add the list, wait for it to show as ready, and ask these six prompts in the test pane, each in a fresh conversation. Replace the placeholder in the fifth with the code you noted for Row 3000. The list holds 875 items in each team, so you know the answer to the sixth.

1  What is the code on Row 0100
2  What is the code on Row 2000
3  What is the code on Row 2100
4  What is the code on Row 3000
5  Which row has the code <code of Row 3000>
6  How many rows are in the Blue team

Check every code the agent gives you against the list. Because each code is a hash, a code the agent did not retrieve cannot be guessed from the row number, so a wrong code tells you the model made one up. Correct codes for the first two prompts next to a “not found” or a wrong code for the third and fourth show the 2,048-row line on your tenant. If question 5 finds Row 3000 while question 4 does not, retrieval can reach the item when the words match and cannot reach it by position. Question 6 shows the counting problem on a list where you know the answer. Run the same six questions against an Agent Builder agent to compare the two, then delete the test list.

Putting every row in reach with a SQL table

The test makes the gap measurable. The fix is to give the agent something it can query instead of search. Copilot Studio’s real-time knowledge connectors, in preview, include Azure SQL. Learn says Microsoft indexes only metadata such as table and column names, that each request runs at runtime against the database, and that the calls use the signed-in user’s own credentials. “Who has LT-03000?” becomes a query with a WHERE clause, and item 3,000 is as easy to find as item 1.

That needs the list in a database, kept current. SPSync replicates SharePoint lists into Azure SQL, SQL Server or PostgreSQL on a schedule, reading SharePoint and never writing to it. In the desktop app, connect the IT site, tick Assets and Locations, pick Azure SQL and check the schema preview. From the command line:

spsync export-config --output assets.yaml --pipeline-name assets --prefix it \
  --destination-kind mssql --connection-string-env ASSETS_DB_URL \
  --dataset-name assets --client-id $SPSYNC_CLIENT_ID \
  --site-url https://contoso.sharepoint.com/sites/it \
  --list Assets --list Locations --create-reporting-views
spsync run assets.yaml

After the first full load the assets schema holds it_assets with every one of the 4,600 items, each keyed by sp_item_id. Location is stored as location_id and location_value, and Assigned To as assigned_to_user_id, which joins to the shared sp_users table. Later runs read only what changed, so a short schedule keeps the table a few minutes behind the list. A full reconcile, weekly by default and configurable, checks the table against the list as a QA step. The questions that failed now have plain answers:

SELECT a.title AS asset_tag, a.model, a.location_value, u.display_name, u.email,
       a.warranty_end
FROM assets.it_assets AS a
LEFT JOIN assets.sp_users AS u ON u.id = a.assigned_to_user_id
WHERE a.title = 'LT-03000' AND a.sp_deleted_at IS NULL;

In Copilot Studio, add Azure SQL as knowledge, select the tables or a view of your own with plain column names, and describe what an asset is. The Copilot Studio grounding use case walks through the setup, and the post on four routes from Copilot Studio to a list compares this with a Power Automate flow tool and a Dataverse copy. For SQL Server in your own data centre or PostgreSQL, give a custom agent a read-only SQL tool over the same tables. SPSync ships no agent of its own; the agent and its tool are yours.

Two things need setting up in the database. The replica holds the list’s items and columns and does not carry SharePoint item permissions, so give the agent’s users a database role that can read the assets schema and nothing else, and add row-level security if different teams should see different assets. The replica also holds columns, not files, so attachment contents stay in SharePoint.

When list knowledge is still the right choice

A SharePoint list as knowledge is a good fit for a list of a few hundred items where one or two items answer each question: a contacts list, a policy register, a list of escalation routes. It trims answers to each user’s SharePoint permissions with nothing to configure, and it reads live data. If your list stays inside the 2,048-row read, the questions name the item they want and the six-question test comes back clean, keep it.

The line is the size of the list and the shape of the question. Once the list grows past the 2,048-row read, or people ask for every item that matches a condition, a search cannot promise to reach the item they mean. You can run both side by side: the list as knowledge for quick lookups on a small list, and the replica for the asset register. The same tables can feed a Power BI report or a Power App, one replication each, and licences are per installation and per destination family: see licensing.