What people actually hit
An account or a case in Dynamics 365 accumulates documents. Some are Dataverse notes and attachments; some are files in the SharePoint document location bound to that record. The associated grid on the record shows them together, and for a long time that is fine.
Then someone opens a large account and the grid stops being useful. Rows are missing. Filtering does not reach the ones that are not there. And the usual instinct — find the setting that raises the limit — comes up empty, because there is no such setting to find.
Why it exists
The cap is a consequence of how the grid retrieves. It is not a licence tier or a governor you can lift with a support ticket, which is why the search for a setting is frustrating: the thing people are looking for was never there.
The associated document grid is also a read surface first. It has no editable-grid support, so changing metadata on a file means opening the record for it, one at a time. For a team doing that a hundred times a week, the row cap is often not even the worst part.
The second problem, which is the real one
The ceiling gets the attention because it is visible. The structural problem underneath is that the platform enforces no folder convention.
A Dynamics document location gives you a folder per record. What goes inside it is whatever each person decided that day. Multiply by a few hundred records and a few years, and:
- Every user has invented their own filing scheme, and none of them agree.
- Some files are Dataverse attachments and some are in SharePoint, with no convention saying which belongs where.
- There are two places to look, so people look in one, do not find it, and upload another copy.
- Nobody is confident which copy is current — which is the failure that actually costs money, because someone eventually sends the wrong version to a client.
Raising a row limit would not fix any of that. It is worth being clear about this before spending money, because a solution aimed only at the ceiling leaves the expensive problem in place.
The four options
1. Narrow what the grid has to show — free
If a handful of records are over the cap, the cheapest fix is to stop the grid needing to return that many rows. Split documents across related records rather than piling them on the parent, archive closed matters to a different location, and use SharePoint views for the long-tail retrieval that the grid was never good at.
This is unglamorous and it works. Try it first. If your estate has three problem accounts rather than a systemic problem, you are done, and anyone who sells you something else at this point is selling you something you do not need.
2. Use SharePoint as the interface — free, but a different problem
Send users to the SharePoint library instead of the Dynamics grid. SharePoint handles the volume, has real views, metadata columns and search.
The cost is context. The user is now in a different application from the record they were working on, without the Dynamics security model expressed in a way they can see, and the "one place to look" problem gets worse rather than better — you have formalised the split instead of closing it.
3. Build a custom grid — expensive, and yours forever
A PCF control or a canvas app over the Dataverse Web API and Microsoft Graph will read past the cap and can enforce whatever convention you define.
It is also a bespoke application that your organisation now owns: it needs a developer when the APIs change, when a platform update moves something, and when the person who wrote it leaves. That is a real, recurring cost that rarely appears in the business case. Do this if document handling is genuinely differentiating for your firm. Otherwise it is a maintenance liability dressed as a project.
4. Buy a product — money, but somebody else's maintenance
The honest version of this option is that you are paying someone to own option 3 on your behalf, forever, and to keep it working as Microsoft moves underneath it.
That is what SSS DMS is: a Power Apps code app that reads Dataverse and SharePoint together in one view, is not bound by the associated grid's ceiling or its missing editable-grid support, and — the part that matters more — enforces a folder convention you define once in a model-driven app, on every record, rather than hoping people maintain it.
Two things worth knowing before you get interested. It is in development, not generally available; early access is open and there is no published release date because we would rather give you one we can keep. And it covers one SharePoint site with multiple document libraries — if your documents are spread across several sites, that is not what the product does today.
How to choose
| If… | Do this |
|---|---|
| A few records are over the cap | Option 1. Restructure. Stop reading here. |
| Volume is the only problem and users tolerate SharePoint | Option 2 |
| Document handling is a competitive differentiator for you | Option 3, deliberately, with a maintenance budget |
| Structure and "which copy is current" are the real pain | Option 4 |
The test that separates the last two from the first two is not row count. It is whether your people can answer "where does this document go?" the same way twice. If they cannot, the ceiling is a symptom.