Then you hit the one field, the one property, the one checkbox Graph doesn’t do. And you hit it on day three, with the feature already shaped around Graph.

Sometimes rewiring it is cheap. Sometimes it’s a rewrite. Either way you paid.

I’ve walked into that wall enough times now that I stopped calling it bad luck and started writing down which tool I reach for when. This post is that list.

The 200 That Meant Nothing

The worst one was metadata on uploaded documents. My add-in uploads a file with Graph, then applies the library’s columns to the resulting list item with a PATCH to /listItem/fields. Text columns, choice columns, dates, all good.

Then a managed metadata column.

200 OK. Empty field.

Not a 400. Not “column type not supported”. Graph accepted the payload, answered like everything was fine, and wrote nothing. The Learn page for updating a listItem shows you Color and Quantity and never mentions which column types don’t make it through.

A thrown error costs you an hour. A silent success costs you until someone notices the taxonomy column is blank on documents that were archived weeks ago, and then it costs you a data migration.

That’s the real argument for having a playbook. Not elegance. The cases where the wrong choice fails quietly.

Be careful about which columns you write off, though. I had multi-value lookups and person columns on my “Graph can’t” list for a long time, and both were wrong. They work fine, they just don’t take the shape you’d guess coming from CSOM, and that’s its own post. Managed metadata is the one that genuinely has no Graph write path.

Graph First Is a Default, Not a Plan

To be clear, “Graph first” is a good instinct. PnP Core builds it in: the SDK favours Graph when reading SharePoint data and falls back to SharePoint REST when the requested properties aren’t available there, and you can flip GraphFirst off if you disagree. I’ve written before about why I’m still on PnP.Framework, and that per-operation routing is the thing I most want from PnP Core.

Until I have it, I’m the router. So here’s how I route.

CSOM Owns List Items

Roughly 95% of my list item CRUD is CSOM, and it’s not nostalgia. Three capabilities keep it there.

Batching without a hard ceiling. CSOM queues operations until you call ExecuteQueryAsync(), and around 100 operations per batch is the reliable sweet spot. Graph’s $batch caps at 20 requests, and a failed batch needs picking apart before you retry it. When I’m updating 500 items, that difference is 5 round trips versus 25.

CAML joins. One query across lists connected by lookup columns, filtered on a field two lists away, merged server-side. There’s no Graph equivalent, and I’ve never found a way to fake it that didn’t end in merging rows in C#.

A way past the list view threshold. Query a big list and CSOM throws The attempted operation is prohibited because it exceeds the list view threshold. There’s a flag on CamlQuery that gets you through it, combined with paging and indexed columns. That one deserves its own post and it’s on my list.

The rest of my CSOM reasoning is in the CSOM performance playbook, and the join pattern has its own post.

Graph Owns Files

For files it flips completely. Uploading and downloading through Graph is fewer requests and noticeably faster in every project I’ve measured it in, and large files are the clearest case: createUploadSession gives you a resumable, chunked upload with a pre-authenticated URL, and the chunks don’t carry an Authorization header at all.

// Small files: straight PUT to the content endpoint
if (file.size <= SIMPLE_UPLOAD_LIMIT) {
  return folder.concat(`:/${filename}:/content`).put(file);
}

// Large files: a session, then sequential chunks
const session = await folder.createUploadSession({ name: filename });
for (const chunk of chunks) {
  await session.resumableUpload.upload(chunk.length, chunk, contentRange);
}

The rules that matter: chunk sizes must be a multiple of 320 KiB, they go up sequentially, and each PUT extends the session expiry. Get the multiple wrong and the upload fails at the last chunk, which is a fun way to spend an afternoon.

Downloads get the same treatment - zipping a whole folder out of SharePoint is a Graph job for me, not a CSOM one. Graph’s JSON batching maps cleanly onto “fetch these 20 files’ content”, though matching responses back to requests has its own quirks that I covered in Graph batching for file content.

SharePoint REST Is the Escape Hatch

I almost never choose SharePoint REST. I end up there when it’s the only thing that works, which turns out to be more often than the modern-API story suggests. From my current projects:

• Setting a navigation link to open in a new tab. It’s a checkbox in the UI, it’s not in the PnP provisioning schema, and it’s not on CSOM’s NavigationNode. It’s MenuState/SaveMenuState. I have a whole post coming about that one.
• Reading the sites a user follows: /_api/social.following/my/followed(types=4).
• Joining a hub site, activating site features, applying a site design, adding an available content type to a library. All _api calls in my provisioning engine.
• ValidateUpdateListItem, which is what rescues the metadata story from the top of this post.
• And /_api/web/ensureuser, because Graph has no EnsureUser and no /sites/{id}/users endpoint at all.

The pattern is consistent: the older and more SharePoint-specific the concept, the more likely REST is the only place it lives.

ValidateUpdateListItem is worth knowing by name. It takes form values in SharePoint’s own wire format - taxonomy as Label|GUID, people as a JSON array of claim keys - and it’s the same payload the classic edit form posts, which is exactly why it accepts the column types Graph won’t touch. In a C# backend it’s a method on ListItem in the client library; in a browser add-in with no CSOM available, it’s the REST endpoint. Either way, read the response: rejected fields come back with HasException: true inside an otherwise successful call, so you can recreate the silent-200 problem from the other direction if you don’t look.

The EnsureUser gap is the more interesting one, because it’s what stops person columns from being a pure Graph story. The ids in ReviewersLookupId are site-collection user ids from the User Information List. Not Entra object ids, not Graph user ids. If a user has never been referenced on that site, they simply have no id, and Graph gives you no way to create one. So you POST /_api/web/ensureuser with a logonName first, then write the item with Graph. Or you stay in CSOM and let Web.EnsureUser() plus a FieldUserValue do both in one place, which is what I usually do in a backend.

One nice asymmetry on the taxonomy side: reading the term store works fine over Graph (/sites/{id}/termStore/sets/{id}, with TermStore.Read.All). It’s only writing a term onto a list item that Graph won’t do. So my term picker is Graph and my term save is not.

Gotchas

• A 200 is not proof. This is the whole post in one bullet. Graph accepts unsupported column types and writes nothing. Assert on the value you wrote, at least once per column type, in a real library. Otherwise you find out at migration time.
• Mixing APIs means mixing tokens. A Graph token does not work against /_api. SharePoint REST wants an audience of https://<tenant>.sharepoint.com/.default, so a flow that uses both acquires two tokens and your app registration needs both sets of permissions. Plan the consent, not just the code.
• Lookups are FieldNameLookupId, not FieldName. Graph names the writable property differently from the column. Writing to the column name silently does nothing. Yes, silently.
• Switching to ValidateUpdateListItem needs the list item id. Drive item ids don’t work, so $select=sharepointIds on the Graph item first and use sharepointIds.listItemId.
• It’s logonName, not loginName. The ensureuser parameter is spelled the unintuitive way, some docs get it wrong, and the wrong spelling gets you an InvalidClientQueryException that says nothing useful.
• Chunk sizes are a multiple of 320 KiB or nothing. Graph upload sessions fail on the final commit, not on the offending chunk, so the error points at the wrong place.
• “Unsupported” is sometimes just undocumented. Multi-value lookups and person columns sat on my can’t-do list for far too long. Before you route an operation to the older API, check whether the modern one only lacks a doc page.

Wrapping Up

There’s no winner here. CSOM, SharePoint REST and Graph are three drawers in the same toolbox, and picking per operation beats picking per project.

My rule of thumb: Graph for files, CSOM for list items, SharePoint REST when nothing else can do it - and verify the write whenever you cross a boundary. The failure mode that actually hurt me wasn’t choosing the slower API. It was choosing the API that said yes and did nothing.

For a long time, slow CSOM was just annoying. Users waited, someone made coffee, life went on. Then I sat down with a client to calculate the cost of Service Prioritization in SharePoint, where every CSOM call has an actual price tag: USD $1.00 per 1,000 calls. Suddenly all those wasted calls weren’t just slow. They were an invoice.

That changed how I write CSOM. I count round trips now, the way you’d count database queries in a hot loop. Over the past year I’ve written several posts about the specific techniques that came out of that habit, and this post ties them together into one playbook.

Every ExecuteQuery Is a Road Trip

Here’s the mental model that makes all four techniques click: every ExecuteQueryAsync() is a road trip to the SharePoint server. Doesn’t matter if you’re delivering one package or a hundred, the drive takes the same time. Network latency, authentication, server processing - the overhead is per trip, not per operation.

So the whole playbook boils down to four questions:

1. Can I deliver more packages per trip? (batching)
2. Can one trip cover several destinations? (CAML joins)
3. Is this trip even necessary? (change detection)
4. Can I avoid a second trip when something goes wrong? (ExceptionHandlingScope, and the taxonomy trick)

Let’s take them one at a time.

Rule 1: Batch or Suffer

The most common sin. A loop that loads items one by one:

// ❌ 50 items = 50 round trips = 3-5 seconds
foreach (var id in itemIds)
{
    var item = list.GetItemById(id);
    context.Load(item);
    await context.ExecuteQueryAsync();
    ProcessItem(item);
}

CSOM happily queues up operations until you call ExecuteQueryAsync(). Around 100 operations per batch is the reliable sweet spot:

// ✅ 50 items = 1 round trip = ~200-500ms
var items = chunk.Select(id => {
    var item = list.GetItemById(id);
    list.Context.Load(item);
    return item;
}).ToList();

await context.ExecuteQueryAsync();

In my testing, that’s a 10x+ improvement for the price of restructuring a loop. It works for reads, writes, deletes, all of it.

Full post with the reusable ProcessInChunks helper: CSOM Performance Optimization: Why You Should Batch Your SharePoint Operations.

Rule 2: Join Lists, Don’t Query Them One by One

Related data across multiple lists is where round trips multiply quietly. Customers in one list, orders in another, order items in a third, so you write three queries and merge the results in C#. Every multi-item query costs 2 resource units toward your throttling budget, so three lists cost 6 units plus three round trips plus the merging code nobody wants to maintain.

CAML supports joins, even though the SharePoint UI never hints at it. One query, one trip, 2 resource units, and the server does the merging. I use CAMLEX instead of raw CAML XML because lambda expressions are readable and the XML it generates is not:

var query = Camlex.Query()
    .Where(x => (string)x["CustomerName"] == "Contoso") // filter on a field 2 lists away!
    .LeftJoin(x => x["OrderTaskLookUp"].ForeignList(ListGuidOrderTasks))
    .LeftJoin(x => x["OrderDetailLookUp"].PrimaryList(ListGuidOrderTasks).ForeignList(ListGuidOrders))
    .LeftJoin(x => x["CustomerLookUp"].PrimaryList(ListGuidOrders).ForeignList(ListGuidCustomers))
    .ProjectedField(x => x["CustomerName"].List(ListGuidCustomers).ShowField("CustomerName"));

var camlQuery = new CamlQuery { ViewXml = query.ToString() };
var items = ordersList.GetItems(camlQuery);

That’s 66% fewer resource units than the three-query version, and you can even filter on a value several lists away. The lists must be connected via lookup columns, and ProjectedFields only supports simple field types (text, number, date - not user, choice, or managed metadata fields).

Full post with the raw CAML comparison and the field type list: Efficient Multi-List Queries in CSOM: Using CAML Joins with CAMLEX.

Rule 3: Did Anything Actually Change?

Users are save-happy. They open a form, change nothing, and click save anyway. Automated syncs are worse. When I dug into a typical day of API logs on one project, roughly 70% of our SharePoint update calls weren’t changing anything. SharePoint accepts identical data with a smile and bills you for the privilege.

The fix is change detection before the update:

var differences = GetDifferences(listItem, newValues, treatEmptyStringAsNull: true);
if (differences.Any())
{
    foreach (var (fieldName, newValue) in differences)
    {
        listItem[fieldName] = newValue;
    }
    listItem.Update();
    clientContext.ExecuteQuery();
}
// Nothing changed? Do absolutely nothing.

The hard part is the comparison itself. SharePoint field types fight you: user fields where only LookupId matters, multi-choice fields that come back in random order, taxonomy values, dates with kind mismatches. Naive oldValue == newValue doesn’t survive contact with any of them, and JSON serialization comparison turned out 3-5x slower than a proper normalizing comparer when I benchmarked both.

Full post with the complete comparison engine: SharePoint CSOM: Prevent Unnecessary Updates and API Calls.

Rule 4: Let the Server Do the Catching

This one came straight out of that Service Prioritization cost analysis. The client’s solution made about 90,000 CSOM calls per month, and 88% of them were EnsureUser calls for users who were already on the site. The classic defensive pattern - always ensure the user before setting a user field - was two round trips per assignment, and the first one was almost always pointless.

ExceptionHandlingScope lets you ship try-catch logic to the server and resolve it in one round trip:

var scope = new ExceptionHandlingScope(clientContext);
using (scope.StartScope())
{
    using (scope.StartTry())
    {
        // Optimistic: works for users already known to the site
        listItem["AssignedTo"] = FieldUserValue.FromUser("user@company.com");
        listItem.Update();
    }
    using (scope.StartCatch())
    {
        // Fallback: only runs server-side if the try failed
        var user = clientContext.Web.EnsureUser("user@company.com");
        listItem["AssignedTo"] = FieldUserValue.FromUser("user@company.com");
    }
}
clientContext.ExecuteQuery(); // one trip

Result for that client: a 75-85% reduction in monthly calls. One honest caveat, and it’s important: the scope reduces round trips, not server requests. Each operation inside still counts toward throttling. The call reduction came from the optimistic-first logic, and ExceptionHandlingScope is what made that logic affordable.

Full post with the cost breakdown: SharePoint’s Server-Side Try-Catch: ExceptionHandlingScope.

Rule 5: Keep Taxonomy Out of Your ViewFields

Taxonomy fields are the slowest thing you can put in a CAML query. On a list where items carried 5 to 50 terms across multiple managed metadata fields, loading a few hundred items took 90-120 seconds. Users literally walked away from their computers.

The fix has two parts. First, query the list without the taxonomy fields in ViewFields, which is where most of the cost hides. Then load the taxonomy data separately through FieldValuesForEdit, where SharePoint stores it as a raw string you can parse directly:

// Raw format in FieldValuesForEdit: "Label1|GUID1;Label2|GUID2"
foreach (ListItem[] chunk in items.Cast<ListItem>().Chunk(100))
{
    foreach (var item in chunk)
    {
        clientContext.Load(item, i => i.FieldValuesForEdit);
    }
    await clientContext.ExecuteQueryAsync();
    // parse Label|GUID pairs per item
}

That took the same load from 90-120 seconds down to 25-35 seconds, a 70-75% improvement. Fair warning: this parses an internal, undocumented format. It’s been reliable for me, but test it in your environment and keep the traditional approach as a fallback.

Full post with the parser: CSOM Performance: Fast Taxonomy Loading for SharePoint List Items with Many Terms.

Which One First?

If your workload is write-heavy (forms, syncs, integrations), start with change detection. It’s the only technique that eliminates entire operations instead of making them cheaper, and it’s invisible to users.

If your workload is read-heavy, start with batching. It’s the smallest code change for the biggest win, and the chunking helper is reusable everywhere. And if those reads span related lists, add joins next: they cut resource units, not just latency, which stretches your throttling budget further.

ExceptionHandlingScope is for when a specific fallback pattern (like EnsureUser) dominates your call logs. Check your logs first - I only found the 88% figure because I went looking. And the taxonomy trick is a targeted weapon: only reach for it when managed metadata is measurably your bottleneck, because it carries the undocumented-format risk.

The good news is they stack. Batched updates that skip unchanged items, with server-side fallbacks, is exactly how my current projects run.

Gotchas

• 100 operations per batch is the sweet spot. CSOM reliably handles around that many. Bigger batches mean bigger payloads and less predictable behavior across environments. Ask me how I know.
• ExceptionHandlingScope doesn’t reduce throttling pressure by itself. Round trips go down, but every operation inside the scope still counts as a request. The savings come from the optimistic-first logic it enables.
• Your numbers will differ from mine. The 70%, 75-85%, and 70-75% figures are from real projects, but latency, item complexity, and tenant load all move them. Measure before and after in your own environment.
• Test under throttling before you trust any of it. Dev Proxy can simulate 429 responses locally so you find out how your batches behave under pressure before production does.
• The taxonomy trick gives you label and GUID, nothing more. If you need full term paths or custom properties, you’re back to the taxonomy API for those items.
• Joins need lookup columns and GUIDs. CAML joins only work across lists connected by lookup columns, and referencing lists by GUID instead of title saves you from “list does not exist” surprises.

If you’re also downloading files in the same solution, the round-trip mindset applies there too - I’ve covered that in downloading multiple files from SharePoint.

Wrapping Up

Count your round trips before SharePoint counts them for you. That’s the whole playbook in one sentence: fewer trips (batching), combined trips (CAML joins), no pointless trips (change detection), no second trips (ExceptionHandlingScope), and lighter trips (taxonomy loading).

Each technique stands on its own, so grab the one that matches your bottleneck:

• Batch your SharePoint operations
• Join multiple lists in one CAML query
• Prevent unnecessary updates
• Server-side try-catch with ExceptionHandlingScope
• Fast taxonomy loading

I was working on a SharePoint solution where we had a list with items containing multiple taxonomy fields. Each item could have anywhere from 5 to 50 taxonomy terms across different fields. The client needed to load hundreds of these items regularly.

The traditional CSOM approach was… well, let’s just say coffee breaks became very popular during load times.

The loading process was taking 90-120 seconds for a few hundred items. Users were literally walking away from their computers while waiting for data to load.

That’s when I realized we needed to completely rethink how we approach taxonomy loading in CSOM.

The Traditional (Slow) Way

Here’s what most developers do, and what I was doing initially:

// The traditional approach - including taxonomy fields in ViewFields
CamlQuery query = new CamlQuery();
query.Query = @"
    <View>
        <ViewFields>
            <FieldRef Name='ID'/>
            <FieldRef Name='Title'/>
            <FieldRef Name='CategoryField'/>     <!-- Taxonomy field -->
            <FieldRef Name='TagField'/>          <!-- Taxonomy field -->
            <FieldRef Name='OtherTaxField'/>     <!-- Taxonomy field -->
        </ViewFields>
    </View>";

ListItemCollection items = list.GetItems(query);
clientContext.Load(items);
await clientContext.ExecuteQueryAsync();

// Then access taxonomy fields normally
foreach (ListItem item in items)
{
    var categoryField = item["CategoryField"] as TaxonomyFieldValueCollection;
    var tagField = item["TagField"] as TaxonomyFieldValueCollection;
    // Process taxonomy values...
}

Problems with this approach:

• Including taxonomy fields in ViewFields is extremely slow
• SharePoint has to load and process all taxonomy data upfront
• Multiple expensive taxonomy service calls during the initial load
• No control over how taxonomy data is loaded

Result: Coffee break time. Lots of it.

The Optimization Journey

After digging into SharePoint’s internals and some experimentation, I discovered two key things:

1. Including taxonomy fields in ViewFields is what kills performance. SharePoint has to load and process all taxonomy data during the initial query, which is extremely slow.

2. SharePoint stores taxonomy data in a raw format that can be accessed via FieldValuesForEdit and parsed directly. This bypasses the expensive taxonomy service calls entirely.

The breakthrough: Separate regular field loading from taxonomy field loading. Load items with only the fields you need immediately, then load taxonomy fields separately using the faster FieldValuesForEdit approach.

Key Insights:

1. Exclude taxonomy fields from ViewFields - This is the biggest performance gain. Load regular fields first, taxonomy fields separately.
2. FieldValuesForEdit contains raw taxonomy data in the format: Label|GUID;Label|GUID - much faster to parse than TaxonomyFieldValue API
3. Batch loading is crucial - load all items’ FieldValuesForEdit in one call per chunk
4. Chunking prevents timeouts - process items in manageable batches
5. Dictionary lookups are fast - map terms back to items efficiently

The Optimized Solution

Here’s the approach that cut our load times by 70-75%:

Main Loading Logic

public async Task<List<MyItemDTO?>?> GetItemsByOptions(string[] options)
{
    // Step 1: Load list items WITHOUT taxonomy fields in ViewFields
    // This is much faster than including taxonomy fields in the initial query
    List list = clientContext.Web.Lists.GetByTitle("YourListName");
    
    CamlQuery query = new CamlQuery();
    query.Query = @"
        <View>
            <ViewFields>
                <FieldRef Name='ID'/>
                <FieldRef Name='Title'/>
                <FieldRef Name='OtherRegularFields'/>
                <!-- Notice: NO taxonomy fields here -->
            </ViewFields>
            <Query>
                <!-- Your where clause here -->
            </Query>
        </View>";
    
    ListItemCollection items = list.GetItems(query);
    clientContext.Load(items);
    await clientContext.ExecuteQueryAsync();

    if (items == null || items.Count == 0)
        return null;

    // Step 2: Process in chunks and load taxonomy fields separately
    List<MyItemDTO> result = new List<MyItemDTO>();
    
    foreach (ListItem[] chunk in items.Cast<ListItem>().Chunk(100))
    {
        // Load taxonomy fields separately using FieldValuesForEdit
        var categoryTerms = await LoadTaxonomyField(chunk, "CategoryField");
        var tagTerms = await LoadTaxonomyField(chunk, "TagField");

        // Step 3: Map everything together
        foreach (var item in chunk)
        {
            var dto = new MyItemDTO
            {
                Id = item.Id,
                Title = item["Title"]?.ToString(),
                // Map regular fields normally
            };

            // Add taxonomy terms from our separate loading
            if (categoryTerms.TryGetValue(item.Id.ToString(), out var terms))
                dto.CategoryTerms = terms;
                
            if (tagTerms.TryGetValue(item.Id.ToString(), out var tags))
                dto.TagTerms = tags;

            result.Add(dto);
        }
    }

    return result;
}

Batch Taxonomy Loading

private async Task<Dictionary<string, List<TaxonomyTerm>>> LoadTaxonomyField(
    IEnumerable<ListItem> items, 
    string taxonomyFieldInternalName)
{
    // Load FieldValuesForEdit for all items in one batch
    foreach (var item in items)
    {
        clientContext.Load(item, i => i.FieldValuesForEdit);
    }
    await clientContext.ExecuteQueryRetryAsync();

    // Get the field ID for internal format matching
    var list = clientContext.Web.Lists.GetById(listGuid);
    var field = list.Fields.GetFieldByInternalName(taxonomyFieldInternalName);
    clientContext.Load(field);
    await clientContext.ExecuteQueryRetryAsync();

    string fieldId = field.Id.ToString();

    // Parse taxonomy data from each item's FieldValuesForEdit
    return items.ToDictionary(
        item => item.Id.ToString(),
        item => ParseTaxonomyFromEditValues(item, fieldId)
    );
}

private List<TaxonomyTerm> ParseTaxonomyFromEditValues(ListItem item, string fieldId)
{
    // Find the correct field key (SharePoint uses shortened GUIDs)
    var fieldValues = item.FieldValuesForEdit.FieldValues
        .Where(x => x.Key.EndsWith(fieldId.Replace("-", "").Substring(4)));
    
    if (!fieldValues.Any())
        return new List<TaxonomyTerm>();

    string actualFieldKey = fieldValues.First().Key;
    
    if (!item.FieldValuesForEdit.FieldValues.ContainsKey(actualFieldKey))
        return new List<TaxonomyTerm>();

    // Parse the raw taxonomy string
    string rawTaxonomyData = item.FieldValuesForEdit[actualFieldKey];
    return ParseTaxonomyEditString(rawTaxonomyData);
}

Raw Format Parser

private List<TaxonomyTerm> ParseTaxonomyEditString(string editString)
{
    if (string.IsNullOrWhiteSpace(editString))
        return new List<TaxonomyTerm>();

    // Format: "Label1|GUID1;Label2|GUID2;Label3|GUID3"
    return editString
        .Split(new[] { ';' }, StringSplitOptions.RemoveEmptyEntries)
        .Select(entry => 
        {
            var parts = entry.Split('|');
            if (parts.Length == 2 && Guid.TryParse(parts[1], out Guid guid))
            {
                return new TaxonomyTerm 
                { 
                    Label = parts[0].Trim(), 
                    TermGuid = guid 
                };
            }
            return null;
        })
        .Where(t => t != null)
        .Select(t => t!)
        .ToList();
}

public class TaxonomyTerm
{
    public string Label { get; set; }
    public Guid TermGuid { get; set; }
}

Performance Impact

The results were dramatic:

Before optimization:

• 90-120 seconds for a few hundred items with multiple taxonomy fields
• Multiple ExecuteQueryRetryAsync() calls per item
• Heavy taxonomy service usage

After optimization:

• 25-35 seconds for the same dataset
• ~70-75% performance improvement
• Minimal API calls (2 per chunk: one for items, one for field metadata)

The exact savings depend on the number of items and terms, but the pattern held consistently across different datasets.

Should You Try This Approach?

If you’re experiencing slow loading times with taxonomy fields, this might be worth testing.

I can’t give you specific numbers for when this optimization makes sense - every environment and scenario is different. What I can tell you is that in my case, it made a dramatic difference.

My recommendation:

• If your current taxonomy loading is painfully slow, try this approach in a test environment
• Measure the before and after performance in your specific scenario
• Keep the complexity vs. benefit trade-off in mind
• Always have a fallback to the traditional approach

Remember the limitations:

• This is an undocumented approach that works with SharePoint’s internal formats
• You only get basic term information (label + GUID)
• You’ll need to test thoroughly in your environment

The traditional CSOM approach works fine for many scenarios. But if you’re hitting performance walls with taxonomy fields, this optimization might be exactly what you need.

Important Disclaimers

⚠️ This is an undocumented approach that relies on SharePoint’s internal storage format for taxonomy fields. While it has worked reliably in my experience, it’s not officially supported by Microsoft.

Key Takeaways

1. Batch operations are crucial - Load multiple items’ data in single API calls
2. Chunking prevents timeouts - Process large datasets in manageable pieces
3. Raw formats can be faster - Sometimes bypassing official APIs improves performance
4. Know when to optimize - Don’t add complexity unless you really need the performance
5. Document your risks - Be transparent about using undocumented approaches

The traditional CSOM taxonomy approach works fine for simple scenarios. But when you’re dealing with lots of items and lots of terms, sometimes you need to think outside the box.

Fast taxonomy loading is one of five techniques in The SharePoint CSOM Performance Playbook, which is where I’d start if taxonomy isn’t the only thing slowing you down.

I demoed this approach on the Microsoft 365 & Power Platform community demos call in January 2026, under the same title as this post. Those calls are worth an hour of your month if you build on this stack.

So there I was, building what I thought was a pretty straightforward API endpoint. Users fill out a form, click save, and boom—SharePoint list item gets updated. Simple, right?

Wrong.

It was during one of those routine maintenance windows when I decided to review some API logs that I noticed something odd. The numbers just didn’t add up. We were making way more SharePoint API calls than seemed necessary for the amount of actual data changes happening in the system.

Every operation was hitting SharePoint. Even when nothing had actually changed.

That’s when it hit me. Our application was treating every potential update as an actual update, regardless of whether the data was different from what SharePoint already had. Users could open a form, change nothing, click save, and we’d still fire off an API call to “update” the item with identical values.

But SharePoint doesn’t care if you’re setting a field to the exact same value it already has. It still counts that as an API call. It still hits your throttling limits. And if you’re paying for “Service Prioritization in SharePoint”? It still costs you money.

The “Why Did I Even Build This?” Moment

I spent some time digging deeper into the patterns, and the numbers were… enlightening.

This wasn’t just a user behavior issue. It was happening everywhere:

• Users frequently save forms without making actual changes
• Automated processes periodically “sync” data that’s already current
• Applications send complete object states rather than just changed fields
• Integration systems perform routine updates as part of larger workflows

When I looked at a typical day’s worth of operations, I found that roughly 70% of our SharePoint update calls weren’t actually changing anything. We were essentially paying SharePoint to accept identical data and politely say “thanks for the update!”

The more I thought about it, the more I realized this pattern was probably happening in systems everywhere. How many developers have built the same “just update everything” approach without stopping to ask whether anything actually changed?

SharePoint’s “Sure, I’ll Take Your Money” Attitude

Here’s the thing about SharePoint’s CSOM that nobody really talks about: it doesn’t care if you’re being wasteful. You want to set a field to the exact same value it already has? “No problem!” says SharePoint. “That’ll be one API call, please.”

And if you’re using Service Prioritization in SharePoint? That’s real money walking out the door.

Let me show you what I mean with some concrete numbers from a client I worked with recently:

The Head-Scratching Cases

// These should be considered equal, but .NET says "nope"
currentValue: "John Doe"
newValue: "John Doe"  // Easy case, no problem here

currentValue: null
newValue: ""  // Is empty string the same as null? Your call!

currentValue: 42
newValue: "42"  // Different types, same value. Fun times.

The SharePoint Special Cases

// User fields (oh boy...)
currentValue: FieldUserValue { LookupId = 15, LookupValue = "John Doe" }
newValue: FieldUserValue { LookupId = 15, LookupValue = "John Doe" }

// Multi-choice fields that hate you
currentValue: ["Option A", "Option C", "Option B"]
newValue: ["Option B", "Option A", "Option C"]  // Same options, different order

// Taxonomy fields (because why not make it complicated?)
currentValue: TaxonomyFieldValue { TermGuid = "abc-123", Label = "Technology" }
newValue: TaxonomyFieldValue { TermGuid = "abc-123", Label = "Technology" }

After an hour of testing different scenarios, I realized I needed something more sophisticated than oldValue == newValue.

Building the “Actually Smart” Comparison Engine

Alright, time to get serious. I needed a comparison function that could handle all of SharePoint’s quirky field types and still be fast enough to not slow down my API.

Here’s what I ended up building (and yes, it’s a bit of a beast):

internal static List<(string InternalName, object? NewValue)> GetDifferences(
    ListItem item,
    IDictionary<string, object?> newValues,
    bool treatEmptyStringAsNull)
{
    var diffs = new List<(string, object?)>();

    foreach (var kvp in newValues)
    {
        var name = kvp.Key;
        var newVal = kvp.Value;

        object? currentVal = null;
        if (item.FieldValues != null && item.FieldValues.TryGetValue(name, out var cv))
        {
            currentVal = cv;
        }

        if (!ValuesEqual(currentVal, newVal, treatEmptyStringAsNull))
        {
            diffs.Add((name, newVal));
        }
    }

    return diffs;
}

private static bool ValuesEqual(object? a, object? b, bool treatEmptyStringAsNull)
{
    if (ReferenceEquals(a, b))
    {
        return true;
    }

    if (a is null || b is null)
    {
        if (treatEmptyStringAsNull)
        {
            if ((a is null && IsEmptyStringLike(b)) || (b is null && IsEmptyStringLike(a)))
            {
                return true;
            }
        }
        return false;
    }

    a = Normalize(a, treatEmptyStringAsNull);
    b = Normalize(b, treatEmptyStringAsNull);

    if (a is IStructuralEquatable seA && b is IStructuralEquatable seB)
    {
        return StructuralComparisons.StructuralEqualityComparer.Equals(seA, seB);
    }

    return Equals(a, b);
}

private static bool IsEmptyStringLike(object? x)
{
    return x is string s && string.IsNullOrWhiteSpace(s);
}

private static object? Normalize(object? v, bool treatEmptyStringAsNull)
{
    if (v == null)
    {
        return null;
    }

    switch (v)
    {
        case string s:
            return (treatEmptyStringAsNull && string.IsNullOrWhiteSpace(s)) ? null : s;

        case bool b:
            return b;

        case byte or sbyte or short or ushort or int or uint or long or ulong or float or double or decimal:
            return Convert.ToDecimal(v, CultureInfo.InvariantCulture);

        case DateTime dt:
            var utc = (dt.Kind == DateTimeKind.Utc ? dt : DateTime.SpecifyKind(dt, DateTimeKind.Unspecified)).ToUniversalTime();
            return new DateTime(utc.Year, utc.Month, utc.Day, utc.Hour, utc.Minute, utc.Second, DateTimeKind.Utc);

        case FieldUserValue u:
            return u.LookupId;

        case FieldLookupValue l:
            return l.LookupId;

        case IEnumerable<FieldLookupValue> multiLookup:
            return multiLookup.Select(x => x?.LookupId ?? 0).OrderBy(x => x).ToArray();

        case TaxonomyFieldValue tx:
            return tx.TermGuid?.Trim().ToLowerInvariant();

        case TaxonomyFieldValueCollection txc:
            return txc
                .Where(x => x != null && !string.IsNullOrEmpty(x.TermGuid))
                .Select(x => x.TermGuid.Trim().ToLowerInvariant())
                .OrderBy(g => g)
                .ToArray();

        case FieldGeolocationValue geo:
            return new ValueTuple<double, double, double, double>(
                Math.Round(geo.Latitude, 6),
                Math.Round(geo.Longitude, 6),
                Math.Round(geo.Altitude, 2),
                Math.Round(geo.Measure, 2));

        case string[] ss:
            return ss
                .Select(x => treatEmptyStringAsNull && string.IsNullOrWhiteSpace(x) ? null : x)
                .OrderBy(x => x, StringComparer.Ordinal)
                .ToArray();

        case IEnumerable enumerable when v is not string:
        {
            var list = new List<object?>();
            foreach (var e in enumerable)
            {
                list.Add(Normalize(e, treatEmptyStringAsNull));
            }
            return list.ToArray();
        }

        default:
            return v;
    }
}

The Magic Behind the Scenes

1. The Normalization Dance

The Normalize method is where the real magic happens. It takes SharePoint’s various field types and converts them into something we can actually compare:

• Numbers: Everything becomes a decimal because SharePoint loves to mix integers and strings
• DateTime: Converted to UTC and truncated to seconds (because who needs millisecond precision for list items?)
• User/Lookup Fields: We only care about the LookupId, not the display text that might change
• Collections: Sorted alphabetically because SharePoint doesn’t guarantee order
• Strings: Can optionally treat empty/whitespace as null (trust me, you want this)

2. The “It’s Not You, It’s SharePoint” Handling

For arrays and complex objects, I use IStructuralEquatable to do deep comparisons. Because yes, SharePoint will absolutely give you arrays that contain the same items but in different orders.

3. The Business Logic Escape Hatch

The treatEmptyStringAsNull parameter saved my sanity. Different parts of your application might handle empty values differently, and this lets you define your own rules for what counts as “unchanged.”

But Wait, Why Not Just Use JSON Comparison?

Before you ask (because I know you’re thinking it): “Why build this elaborate comparison engine when you could just serialize both objects to JSON and compare the strings?”

Great question. I actually thought the same thing initially. How hard could it be, right? Just JsonSerializer.Serialize() both the old and new values, compare the resulting strings, and call it a day.

Here’s what the “simple” JSON approach looks like:

internal static List<(string InternalName, object? NewValue)> GetDifferencesJson(
    IDictionary<string, object?> oldValues,
    IDictionary<string, object?> newValues,
    bool treatEmptyStringAsNull)
{
    var diffs = new List<(string, object?)>();

    foreach (var kvp in newValues)
    {
        var name = kvp.Key;
        var newVal = kvp.Value;

        object? currentVal = null;
        oldValues?.TryGetValue(name, out currentVal);

        var newJson = JsonSerializer.Serialize(newVal);
        var oldJson = JsonSerializer.Serialize(currentVal);

        if (newJson != oldJson)
        {
            diffs.Add((name, newVal));
        }
    }

    return diffs;
}

Looks clean and simple, right? That’s what I thought too. So I built both approaches and put them head-to-head with BenchmarkDotNet. The results were… eye-opening.

The Performance Reality Check

Here’s what I found when comparing the performance of my custom approach versus JSON string comparison:

Single List Item Comparison:

• Custom Dictionary Approach: 749,625 operations/second (1.334 μs per operation)
• JSON String Approach: 201,109 operations/second (4.972 μs per operation)
• Performance difference: 3.7x faster with the custom approach

Batch Operations (300 items):

• Custom Dictionary Approach: 3,705 operations/second (269.91 μs per batch)
• JSON String Approach: 712 operations/second (1,404.06 μs per batch)
• Performance difference: 5.2x faster with the custom approach

Why JSON Comparison Falls Short

The numbers tell the story, but here’s what’s actually happening under the hood:

1. Serialization Overhead: Converting SharePoint field values to JSON strings requires multiple allocations and string operations
2. Memory Pressure: JSON approach allocated nearly 50% more memory (4.67KB vs 3.17KB per operation)
3. Type Conversion Issues: JSON serialization doesn’t handle SharePoint’s quirky field types the way we need
4. Garbage Collection: More allocations = more GC pressure = slower overall performance

When you’re processing hundreds or thousands of list items in batch operations, that 3-5x performance difference really adds up. Plus, the custom approach gives us complete control over how different field types are compared, which JSON comparison simply can’t provide.

Putting It All Together: The Real-World Implementation

Here’s how I actually use this in my APIs:

public async Task<bool> UpdateListItemAsync(int itemId, Dictionary<string, object?> newValues)
{
    var clientContext = GetClientContext();
    var list = clientContext.Web.Lists.GetByTitle("YourList");
    var listItem = list.GetItemById(itemId);
    
    clientContext.Load(listItem);
    clientContext.ExecuteQuery();

    // The moment of truth - what actually changed?
    var differences = GetDifferences(listItem, newValues, treatEmptyStringAsNull: true);
    
    if (!differences.Any())
    {
        // Nothing changed! Skip the update entirely
        return false; // "Thanks for playing, but you didn't actually change anything"
    }

    // Only update the fields that actually changed
    foreach (var (fieldName, newValue) in differences)
    {
        listItem[fieldName] = newValue;
    }

    listItem.Update();
    clientContext.ExecuteQuery();
    
    return true; // "Something actually happened!"
}

The Numbers Don’t Lie (And They’re Pretty Great)

After implementing this change detection across our applications, here’s what we typically see:

Before implementing change detection:

• Applications making thousands of update requests per day
• Every single one triggered a SharePoint ExecuteQuery()
• High API call volumes and occasional throttling issues

After implementing change detection:

• Same number of update requests from users/systems
• 60-80% contained no actual changes and were skipped
• Dramatically reduced SharePoint API consumption
• Much lower throttling risk

The typical impact:

• Significant reduction in monthly API calls
• Cost savings with Service Prioritization in SharePoint (varies by usage)
• Reduced throttling risk during busy periods
• Faster API responses because skipped operations are basically instant

But here’s what really matters: the performance improvement isn’t just about the numbers. Users notice when applications feel more responsive, and developers notice when they stop getting throttling alerts.

The Gotchas (Because There Are Always Gotchas)

When This Approach Might Not Be For You

1. Audit Requirements: If you need to log every single “save” action regardless of whether anything changed, this might not work for your use case.

2. Always Update Timestamps: Some business requirements dictate that “LastModified” should always be updated when a user clicks save, even if the content is identical.

3. Super Simple Scenarios: If you’re only updating one field and it’s a simple string comparison, the overhead of this elaborate comparison might not be worth it.

The SharePoint Field Types That Made Me Question My Life Choices

Some field types need special handling:

// Calculated fields - don't even try to update these
if (field.ReadOnlyField || field.FieldTypeKind == FieldType.Calculated)
{
    continue; // SharePoint will just ignore you anyway
}

// Attachment fields - these need completely different logic
if (field.FieldTypeKind == FieldType.Attachments)
{
    // Handle separately - attachments are their own special nightmare
    continue;
}

Wrapping Up (And Why This Matters More Than You Think)

Look, I know this might seem like over-engineering for a simple “update SharePoint item” operation. But here’s the thing: those small inefficiencies add up fast.

In my case, this one change:

• Improved user experience with faster response times
• Reduced throttling headaches during busy periods
• Made me feel like a responsible developer (this one’s important too!)

The pattern I’ve shown you isn’t just about SharePoint or just about API optimization. It’s about asking the fundamental question: “Is this operation actually necessary?”

That question has made me a better developer across all the platforms I work with, not just SharePoint.

So next time you’re building any kind of update operation—whether it’s SharePoint, a database, or that JSON file you’re definitely not using as a database—pause for a moment and ask: “Did anything actually change?”

Your future self (and your API bills) will thank you.

Pro tip: Start implementing this pattern on your highest-traffic endpoints first. That’s where you’ll see the biggest impact, and it’ll give you the confidence to roll it out everywhere else.

Now go forth and eliminate those unnecessary API calls. Your SharePoint environment will purr like a happy cat.

Change detection is one of five techniques in The SharePoint CSOM Performance Playbook. If you want the whole picture of where CSOM calls leak, start there.

Recently, I was working with a client to calculate the cost of enabling Service Prioritization in SharePoint on one of their app registrations. The pricing model is straightforward: USD $0.50 per 1,000 Graph calls and USD $1.00 per 1,000 SP REST/CSOM calls.

During the analysis, I discovered something that caught my attention: their solution was making approximately 90,000 calls per month, and 88% of all their CSOM calls were EnsureUser operations.

This was particularly interesting because the users being “ensured” were already associated with the site where the data was being created. It seemed like there should be a more efficient approach - similar to what’s possible with Graph API.

The Problem with User Field Assignment

If you’ve worked with SharePoint user fields, you’re familiar with this common pattern:

// The standard approach
var user = clientContext.Web.EnsureUser("user@company.com");
clientContext.Load(user);
clientContext.ExecuteQuery(); // Network call #1

listItem["AssignedTo"] = new FieldUserValue()
{
    LookupId = user.Id
};
listItem.Update();
clientContext.ExecuteQuery(); // Network call #2

This requires two network calls for each user assignment. Microsoft provides FieldUserValue.FromUser("user@company.com") as an alternative, but it throws an exception if the user isn’t already “known” to the site. This leads to either making two calls to be safe, or handling exceptions with additional calls.

Discovering ExceptionHandlingScope

While researching optimization approaches, I came across a section in Microsoft’s documentation for “Complete basic operations using SharePoint client library code” about ExceptionHandlingScope.

ExceptionHandlingScope allows you to implement try-catch logic that executes on the SharePoint server rather than requiring multiple round trips from your client application. Instead of this painful dance:

1. Try operation → Network call
2. Handle exception → Network call
3. Retry operation → Network call

You get this beautiful symphony:

1. Send try-catch logic to server → Network call
2. Server handles everything internally
3. Get result → You’re done

Here’s the magic in action:

var scope = new ExceptionHandlingScope(clientContext);

using (scope.StartScope())
{
    using (scope.StartTry())
    {
        // Try the optimistic approach first
        listItem["CaseResponsible"] = FieldUserValue.FromUser("user@company.com");
        listItem.Update();
    }
    
    using (scope.StartCatch())
    {
        // If that fails, ensure the user exists
        var user = clientContext.Web.EnsureUser("user@company.com");
        listItem["CaseResponsible"] = FieldUserValue.FromUser("user@company.com");
    }
}

// Execute once - the server handles all the logic
clientContext.ExecuteQuery();

One network call. That’s it.

The server receives your entire try-catch block, attempts the optimistic operation first, and only falls back to EnsureUser if needed. No round trips. No guessing. No waste.

Real-World Impact: Significant Call Reduction

Looking back at the client scenario with ExceptionHandlingScope:

• Before: ~79,200 EnsureUser calls + ~10,800 actual operations = 90,000 total calls
• After: ~10,800-21,600 operations (depending on how many users need ensuring) = substantial reduction

This represents a potential 75-85% reduction in API calls, with corresponding improvements in both performance and Service Prioritization in SharePoint costs.

The Cost Breakdown

Let’s translate this into actual Service Prioritization in SharePoint costs:

Before optimization:

• 90,000 CSOM calls per month
• At USD $1.00 per 1,000 calls
• Monthly cost: $90

After ExceptionHandlingScope optimization:

• Best case: 10,800 calls (if most users are already known) = $10.80/month
• Worst case: 21,600 calls (if many users need ensuring) = $21.60/month
• Monthly savings: $68.40 - $79.20

Annual savings: $820 - $950

These savings become even more significant at scale. For organizations with multiple solutions or higher call volumes, the cost difference can easily reach thousands of dollars annually.

More importantly, the performance improvements—reduced network latency, faster operations, and lower throttling risk—often provide value that far exceeds the direct cost savings.

Throttling: The Hidden Performance Killer

Beyond cost savings, ExceptionHandlingScope provides significant throttling benefits that are often more impactful than the financial savings.

Understanding SharePoint Throttling

SharePoint applies throttling limits to prevent abuse and ensure service stability. When you exceed these limits, you’ll encounter:

• HTTP 429 (Too Many Requests) responses
• Exponential backoff delays (sometimes minutes)
• User experience degradation as operations slow down
• Potential service interruptions during peak usage

The Throttling Math

In our client scenario:

Before ExceptionHandlingScope:

• 90,000 calls per month = ~3,000 calls per day
• During peak hours, this could easily trigger throttling
• Each throttled request requires retry with exponential backoff
• A single throttled operation can delay your entire batch

After ExceptionHandlingScope:

• 10,800-21,600 calls per month = ~360-720 calls per day
• 10x reduction in throttling risk
• Smoother operation during peak business hours
• More predictable performance for end users

Real-World Throttling Impact

Consider a typical business day where multiple users are creating items simultaneously:

• Without optimization: 88% of your throttling budget consumed by redundant EnsureUser calls
• With ExceptionHandlingScope: 88% of your throttling budget available for actual business operations

The beauty of ExceptionHandlingScope is that it doesn’t just reduce the number of calls—it makes your remaining calls more valuable and less likely to be throttled.

Important: ExceptionHandlingScope Is NOT a Magic Bullet

Critical Disclaimer: ExceptionHandlingScope itself does NOT reduce the number of requests to SharePoint. Each operation within the scope still counts as a separate request for throttling purposes.

The reduction in our scenario comes from changing the approach, not from using ExceptionHandlingScope:

What Actually Reduces Calls

• Before: Always calling EnsureUser + setting the field = 2 calls per user
• After: Using FieldUserValue.FromUser() directly, falling back to EnsureUser only when needed

What ExceptionHandlingScope Actually Does

ExceptionHandlingScope reduces network round trips, not server requests:

• Network benefit: 1 round trip instead of potentially 2-3
• Throttling impact: Each operation still counts toward throttling limits
• Performance gain: Reduced latency, not reduced server load

The Real Magic

The 75-85% reduction in our client scenario comes from this logic change:

// This approach reduces actual requests
// Most users are already known to the site
// So most operations only need 1 request instead of 2
using (scope.StartTry())
{
    // This succeeds for ~80% of users (1 request)
    listItem["Field"] = FieldUserValue.FromUser("user@company.com");
}
using (scope.StartCatch())
{
    // This only runs for ~20% of users (1 request)
    var user = clientContext.Web.EnsureUser("user@company.com");
    listItem["Field"] = FieldUserValue.FromUser("user@company.com");
}

ExceptionHandlingScope simply makes this pattern efficient by handling the try-catch logic server-side instead of requiring multiple network round trips to determine which approach to use.

Bottom line: ExceptionHandlingScope optimizes network efficiency, but the request reduction comes from smarter business logic, not from the scope itself.

The Broader Lesson

This experience highlighted an important principle: before optimizing an existing approach, it’s worth questioning whether there’s a fundamentally different way to solve the problem. In this case, server-side exception handling provided a cleaner solution than client-side optimization or caching strategies.

ExceptionHandlingScope has been available since SharePoint 2013, but it’s not widely discussed in the SharePoint development community. It’s a good reminder to periodically review Microsoft’s documentation for features that might address current challenges in new ways.

Your Next Steps

Before you write your next SharePoint operation that involves potential exceptions:

1. Pause and calculate: How many network calls will your approach generate?
2. Question the pattern: Could server-side logic handle the complexity?
3. Explore ExceptionHandlingScope: Can your try-catch logic run on the server?
4. Measure the impact: Compare network calls before and after implementation

Sometimes the most powerful optimizations come from using the tools that were there all along. ExceptionHandlingScope isn’t just a performance optimization—it’s a reminder that the platform often provides solutions we didn’t know we were looking for.

Next time you’re facing a SharePoint performance challenge, remember: the answer might not be in the latest framework or cutting-edge technique. Sometimes, it’s hiding in plain sight in the documentation you scrolled past.

ExceptionHandlingScope is one of five techniques in The SharePoint CSOM Performance Playbook, alongside batching, CAML joins, change detection and fast taxonomy loading.

Following up on my previous post about DevProxy and throttling testing, there’s another critical performance issue I see regularly in SharePoint CSOM code: executing operations one by one instead of batching them.

Consider this common pattern that I see everywhere:

// ❌ This approach is slow and inefficient
foreach (var id in itemIds)
{
    var item = list.GetItemById(id);
    context.Load(item);
    await context.ExecuteQueryAsync(); // Executing for EACH item!
    
    // Process the item
    ProcessItem(item);
}

This code makes a server round-trip for every single item. If you’re processing 50 items, that’s 50 separate calls to SharePoint. Each call has network latency and server processing time.

The Solution: Batch Operations

SharePoint CSOM reliably handles batches of around 100 operations before calling ExecuteQueryAsync(). This means you can dramatically reduce the number of server round-trips.

Microsoft’s official documentation also emphasizes this pattern in their performance guidelines, showing how grouping data retrieval operations significantly improves performance.

Here’s the pattern I use in most of my SharePoint projects:

The Helper Methods

public static async Task<List<T>> GetItemsByIds<T>(this List list, IEnumerable<int> ids) 
    where T : new()
{
    if (ids == null || !ids.Any())
    {
        return new List<T>();
    }

    var listItems = await CSOMHelpers.ProcessInChunks(ids.ToList(), 100, async chunk => {
        var items = chunk.Select(id => {
            var item = list.GetItemById(id);
            list.Context.Load(item);
            return item;
        }).ToList();

        await ExecuteQuery(list.Context, () => { /* Load calls already done above */ });
        
        return items;
    });

    return listItems.ToList();
}

internal static async Task<List<TOut>> ProcessInChunks<TIn, TOut>(List<TIn> source, int chunkSize, Func<List<TIn>, Task<List<TOut>>> action)
{
    var result = new List<TOut>();
    foreach (var chunk in source.Chunk(chunkSize))
    {
        result.AddRange(await action(chunk.ToList()));
    }
    return result;
}

Performance Impact: The Numbers

Let me show you the difference with a real-world example. Loading 50 SharePoint list items:

Before (One-by-One)

• 50 server calls
• Network latency: 50ms × 50 = 2.5 seconds
• Actual total time is usually higher due to server-side processing, hence: ~3-5 seconds

After (Batched)

• 1 server call (all 50 items in one batch)
• Network latency: 50ms × 1 = 50ms
• Total time: ~200-500ms

⚠️ Performance Disclaimer

The numbers shown above are from a specific example scenario and are meant to illustrate the concept of batching benefits. Your actual performance gains will vary significantly based on:

• Network latency and bandwidth
• SharePoint server load and location
• Item complexity and field count
• Query complexity and filtering
• Authentication overhead
• Time of day and concurrent users

While batching almost always improves performance, the exact improvement factor can range from marginal gains to dramatic improvements. The key takeaway is the pattern and approach, not the specific numbers.

Applying the Pattern to CRUD Operations

This pattern works for all CSOM operations, not just reading, but for all the CRUD operations.

Why 100 Items?

SharePoint has practical limits on how many operations you can batch:

• CSOM limit: Around 100 operations per batch
• REST API limit: Different limits depending on operation type
• Network payload: Larger batches mean bigger HTTP requests

I’ve found 100 items to be the sweet spot that:

• Maximizes performance gains
• Stays well within SharePoint limits
• Keeps HTTP payloads manageable
• Works reliably across different SharePoint environments

Combining with Throttling Protection

When you combine this batching approach with the throttling protection patterns from my DevProxy post, you get robust, high-performance SharePoint applications.

Best Practices

1. Batch whenever you can - even for small numbers of items, batching usually helps.
2. Use 100 as your chunk size for most scenarios
3. Combine with retry logic for production resilience
4. Test with DevProxy to ensure your batching works under throttling conditions
5. Monitor performance before and after implementing batching

The Bottom Line

Batching CSOM operations is one of the easiest wins for SharePoint performance optimization. The code pattern is straightforward to implement and reuse, but the performance impact is dramatic.

Stop executing SharePoint operations one by one. Your users (and SharePoint servers) will thank you.

Batching is the first of five techniques I use to keep CSOM cheap. The rest, and the order I reach for them in, are in The SharePoint CSOM Performance Playbook.

Resources

• SharePoint CSOM Best Practices
• DevProxy for Testing Throttling
• SharePoint Performance Guidelines

When working with related data across multiple SharePoint lists, developers often fall into the trap of making multiple individual queries:

// ❌ Bad approach - Multiple API calls
var customers = context.Web.Lists.GetByTitle("Customers");
var orders = context.Web.Lists.GetByTitle("Orders");
var orderItems = context.Web.Lists.GetByTitle("OrderItems");

// Each query consumes 2 resource units
var customerItems = customers.GetItems(camlQuery1);  // 2 units
var orderItems = orders.GetItems(camlQuery2);        // 2 units  
var itemDetails = orderItems.GetItems(camlQuery3);   // 2 units
// Total: 6 resource units + processing overhead

This approach has several issues:

• Higher resource consumption: Each query consumes 2 resource units per multi-item request
• Increased throttling risk: More API calls mean hitting limits faster
• Network overhead: Multiple round trips to SharePoint
• Complex data merging: Manual joining of results in C#

How to fix it?

I have worked alot with MSSQL where it is pretty easy to just join a table on a table on a table. But I did not know it was possible in CSOM. Eg. in the UI of SharePoint you can only expand one table - NOT multiple. But one day I deep dived into CAML and joins, and found out it was possible!

Resource Unit Comparison:

Let’s break down the actual cost difference. According to Microsoft’s throttling documentation, each multi-item query consumes 2 resource units.

Multiple separate queries (❌ Bad approach):

// Query 1: Get order items from main list
var orderItems = ordersList.GetItems(query1);        // 2 resource units

// Query 2: Get customer details  
var customers = customersList.GetItems(query2);      // 2 resource units

// Query 3: Get order details
var orderDetails = orderDetailsList.GetItems(query3); // 2 resource units

// Total: 6 resource units + network overhead + manual C# joining

Single join query (✅ Good approach):

// One query with joins gets ALL the data
var items = ordersList.GetItems(joinQuery);          // 2 resource units total

The math:

• Multiple queries: 2 units × 3 lists = 6 units
• Single join query: 2 units total
• Savings: 66% fewer resource units!

This becomes even more significant when you consider that SharePoint throttling limits are measured in resource units per time window. With joins, you can query 3x more data within the same throttling limits.

The Solution: CAML Joins

CAML actually supports joining multiple lists in a single query! This means you can get data from related lists without multiple API calls.

First, install CAMLEX via NuGet:

Install-Package Camlex.Client.dll

Then build your join query:

var list = context.Web.Lists.GetByTitle("YourMainList");

CamlexNET.Interfaces.IQuery query = Camlex.Query();

query = query
.LeftJoin(x => x["OrderTaskLookUp"].ForeignList(ListGuidOrderTasks))
.LeftJoin(x => x["OrderDetailLookUp"].PrimaryList(ListGuidOrderTasks).ForeignList(ListGuidOrders))
.LeftJoin(x => x["CustomerLookUp"].PrimaryList(ListGuidOrders).ForeignList(ListGuidCustomers))
.ProjectedField(x => x["CustomerNo"].List(ListGuidCustomers).ShowField("CustomerNo"))
.ProjectedField(x => x["CustomerName"].List(ListGuidCustomers).ShowField("CustomerName"));

var camlQuery = new CamlQuery();
camlQuery.ViewXml = query.ToString();

var items = list.GetItems(camlQuery);
context.Load(items);
context.ExecuteQuery();

Important: Your lists need to be connected via lookup columns for joins to work!

Why CAMLEX Instead of Raw CAML?

I don’t write raw CAML myself - it’s verbose and error-prone. Instead, I use CAMLEX because:

• Cleaner syntax: C# lambda expressions instead of XML
• IntelliSense support: Catch errors at compile time
• Easier for the next developer: Self-documenting code
• Less mistakes: No more XML typos or missing tags

What else?

One thing is to join multiple lists, but to filter on a value 4 lists away - That is neat!

For example, filtering orders by the customer’s name, which is 2 lists away:

CamlexNET.Interfaces.IQuery query = Camlex.Query();

query = query
.Where(x => (string)x["CustomerName"] == "Contoso") // <---- Filtering on join field
.LeftJoin(x => x["OrderTaskLookUp"].ForeignList(ListGuidOrderTasks))
.LeftJoin(x => x["OrderDetailLookUp"].PrimaryList(ListGuidOrderTasks).ForeignList(ListGuidOrders))
.LeftJoin(x => x["CustomerLookUp"].PrimaryList(ListGuidOrders).ForeignList(ListGuidCustomers))
.ProjectedField(x => x["CustomerNo"].List(ListGuidCustomers).ShowField("CustomerNo"))
.ProjectedField(x => x["CustomerName"].List(ListGuidCustomers).ShowField("CustomerName"));

var camlQuery = new CamlQuery();
camlQuery.ViewXml = query.ToString();
var items = ordersList.GetItems(camlQuery);

This CAMLEX query automatically generates the following CAML XML - notice how complex the raw XML is compared to the clean C# syntax above:

<View>
  <Query>
    <Where>
      <Geq>
        <FieldRef Name="customerName" />
        <Value Type="Text">Contoso</Value>
      </Geq>
    </Where>
  </Query>
  <ViewFields>
    <FieldRef Name="Id" />
    <FieldRef Name="customerNo" />
    <FieldRef Name="customerName" />
  </ViewFields>
  <Joins>
    <Join Type="LEFT" ListAlias="0f0cfc71-1c6e-4fd4-b6f2-279d0e3862f4">
      <Eq>
        <FieldRef Name="OrderTaskLookUp" RefType="Id" />
        <FieldRef List="0f0cfc71-1c6e-4fd4-b6f2-279d0e3862f4" Name="Id" />
      </Eq>
    </Join>
    <Join Type="LEFT" ListAlias="ce57b9a2-5052-482c-a8c8-150c7d59ced3">
      <Eq>
        <FieldRef List="0f0cfc71-1c6e-4fd4-b6f2-279d0e3862f4" Name="OrderDetailLookUp" RefType="Id" />
        <FieldRef List="ce57b9a2-5052-482c-a8c8-150c7d59ced3" Name="Id" />
      </Eq>
    </Join>
    <Join Type="LEFT" ListAlias="e204ed0f-7c25-432f-9228-3eb438c527e2">
      <Eq>
        <FieldRef List="ce57b9a2-5052-482c-a8c8-150c7d59ced3" Name="CustomerLookUp" RefType="Id" />
        <FieldRef List="e204ed0f-7c25-432f-9228-3eb438c527e2" Name="Id" />
      </Eq>
    </Join>
  </Joins>
  <ProjectedFields>
    <Field 
      Name="customerNo" 
      Type="Lookup" 
      List="e204ed0f-7c25-432f-9228-3eb438c527e2" 
      ShowField="customerNo" 
    />
    <Field 
      Name="customerName" 
      Type="Lookup" 
      List="e204ed0f-7c25-432f-9228-3eb438c527e2" 
      ShowField="customerName"
    />
  </ProjectedFields>
</View>

Imagine having to write and maintain that XML manually! This is exactly why CAMLEX is so valuable - you get all the power of CAML joins with readable C# syntax.

Performance Benefits

Before (Multiple queries):

• 🔴 6+ resource units
• 🔴 Multiple network calls
• 🔴 Complex C# merging logic

After (Single join):

• ✅ 2 resource units only
• ✅ One network call
• ✅ Server-side joining

Key Takeaways

• Use joins instead of multiple queries to reduce resource consumption
• CAMLEX makes CAML readable for you and the next developer
• You can filter on joined data even multiple lists away
• SharePoint UI limitations ≠ API limitations - joins work even if the UI doesn’t show it

Common Issues & Solutions

❌ “List does not exist” error

// Use list GUIDs instead of names for reliability
.ForeignList(new Guid("12345678-1234-1234-1234-123456789012"))

❌ “Field not found” error

// Use internal field names, not display names
.ShowField("Title")        // ✅ Internal name
.ShowField("Customer Name") // ❌ Display name

❌ Join returns no data

• Verify lookup columns exist and are properly configured
• Check that you’re joining on the correct fields
• Ensure the lookup field contains valid IDs

❌ “Cannot project this field type” error

Only specific field types can be included in ProjectedFields:

✅ Supported ProjectedFields types:

• Calculated (treated as plain text)
• ContentTypeId
• Counter
• Currency
• DateTime
• Guid
• Integer
• Note (one-line only)
• Number
• Text

❌ NOT supported in ProjectedFields:

• Multi-line text fields
• Rich text fields
• Choice fields
• Lookup fields (use joins instead)
• User/Person fields
• Managed metadata fields

💡 Pro tip: If you need data from unsupported field types, query them separately after getting your joined results.

CAML joins are one of five techniques in The SharePoint CSOM Performance Playbook, which covers when a join is the right answer and when batching or change detection would serve you better.