That kind of library is exactly the moment to pick your foundation on purpose. So I sat down and looked hard at PnP Core.

And then I stayed on PnP.Framework.

What Makes PnP Core Tempting

The thing I actually want from PnP Core isn’t a feature. It’s that somebody already made a decision I keep having to make myself.

With CSOM and raw calls, every time I read something out of SharePoint I have to think about how: SharePoint REST, or Microsoft Graph? Which one has this property? Which one is faster here? PnP Core removes that question. Per the docs, the SDK “by default is configured to favor the Microsoft Graph API when you’re reading SharePoint data assuming the requested properties are available via Graph”, and it falls back to SharePoint REST when they aren’t. If you disagree, you flip GraphFirst to false on the PnPContext and it prefers REST instead.

Someone with more context than me picked the better call per operation, and I get to write the intent instead of the plumbing. Add async-first, a real domain model, and modern .NET hosting, and it’s not a close comparison on paper.

The problem is that my code doesn’t run on paper.

Blocker 1: The Provisioning Engine Isn’t There

Almost everything I build for SharePoint eventually provisions something. Lists, content types, pages, navigation. That’s ApplyProvisioningTemplate, and it lives in PnP.Framework. PnP Core has no provisioning engine.

So a migration wasn’t “rewrite my queries”. It was “rewrite my queries and keep PnP.Framework around anyway for the part that does the heavy lifting”. Two SDKs, two mental models, no win.

That’s the part I’d already made peace with, until pnpframework issue #1237 showed up in June: a roadmap for moving both the Provisioning Engine and the Modernization Engine into PnP Core as dedicated projects, with the PnP.Framework versions deprecated afterwards. Target is Q4 2026.

That single issue turns my biggest objection into a waiting game. I don’t need PnP Core to grow a provisioning engine as a favor to me. It’s on the roadmap, in the open, with a phase 2 already referenced for the wider PnP.Framework deprecation. Everything I’ve written about splitting templates into modular files for retry resilience survives that move, because it’s a property of how you structure templates, not of which SDK applies them.

Blocker 2: CAML Joins Come Back Empty

The second one I couldn’t wait out, because it’s the query pattern I lean on hardest.

SharePoint’s CAML supports joining lists and pulling fields across the join with <Joins> and <ProjectedFields>. It’s the difference between one query and four, and I’ve written a whole post on doing it with CAMLEX in CSOM because it saves resource units and spares you from merging rows in C#.

Run that same view XML through PnP Core’s LoadItemsByCamlQueryAsync and nothing breaks. No exception, no error, no warning. You get items back, the join is honored for filtering, and the projected fields simply aren’t in the result. The REST GetItems endpoint doesn’t serialize them, so they never make it into the response for the SDK to map.

A silent hole in the data is worse than a thrown exception, and it’s a hole in the one query shape I most wanted to keep.

So I filed issue #1799 and then PR #1802 with an implementation: two new methods on IList that run the query through CSOM’s List.GetItems(CamlQuery) instead of REST, because CSOM does return projected fields.

/// <summary>
/// Loads list items based up on a CAML query executed via CSOM, which also returns
/// fields projected from a joined list (CAML Joins/ProjectedFields)
/// </summary>
public Task<ICamlQueryCsomResult> LoadItemsByCamlQueryViaCsomAsync(CamlQueryOptions queryOptions);

public ICamlQueryCsomResult LoadItemsByCamlQueryViaCsom(CamlQueryOptions queryOptions);

Using it looks like any other PnP Core call. This is the shape from the integration test in the PR:

var page1 = await list.LoadItemsByCamlQueryViaCsomAsync(new CamlQueryOptions()
{
    ViewXml = viewXml,
    DatesInUtc = true
});

var firstItem = page1.Items[0];
var projected = firstItem["ProjectedText"] as IFieldLookupValue;
Console.WriteLine(projected.LookupValue);

// Next page, without hand-building a paging string
var page2 = await list.LoadItemsByCamlQueryViaCsomAsync(new CamlQueryOptions()
{
    ViewXml = viewXml,
    DatesInUtc = true,
    PagingInfo = page1.PagingInfo
});

What’s happening here?

1. LoadItemsByCamlQueryViaCsomAsync takes the exact same CamlQueryOptions as the REST-based method, so the view XML with <Joins> and <ProjectedFields> is unchanged. Only the transport differs.
2. The projected field comes back typed as an IFieldLookupValue, not as a raw string. That’s how CSOM represents it and it’s what you’d expect from a lookup coming across a join, so LookupId and LookupValue are both there.
3. The returned ICamlQueryCsomResult carries Items plus PagingInfo, taken from CSOM’s ListItemCollectionPosition. Feed PagingInfo back into the next call and you get the next page. It’s null when there are no more pages.
4. The loaded items are also merged into the list’s Items collection, the same as the existing CAML methods, so nothing about the surrounding model changes.

Gotchas

• The failure mode is silence, not an error. No exception on a join query with projected fields means your code happily maps a null and moves on. If you’re evaluating PnP Core for join-heavy work, assert on the projected value in a test, don’t eyeball the item count.
• A roadmap is a plan, not a shipped release. Issue #1237 has a Q4 2026 target and it’s still open. Same for my PR: open, no reviewer assigned yet. I’m building on the current state of both SDKs, not on the version I hope exists in six months.
• No batch variant for the CSOM path, on purpose. The items are materialized immediately, so it doesn’t fit PnP Core’s batching model. If you’re used to queueing everything into a batch, this one call stands apart.
• Deprecation warnings are part of the plan. Once the engines land in PnP Core, the PnP.Framework equivalents get marked deprecated and stop taking new features. Staying put is a decision with an expiry date, which is exactly why I’d rather have the blockers resolved than keep postponing.

Wrapping Up

I’m not avoiding PnP Core because I prefer PnP.Framework. I’m on PnP.Framework because two specific things weren’t there: the provisioning engine, and CAML joins that actually return the joined data. Both now have an issue number attached, and one of them has my name on the pull request.

Rule of thumb: pick the SDK by what your workload actually needs today, then go make the gap smaller instead of waiting for someone else to. Filing #1799 took an evening. It moved my migration date more than another month of reading release notes would have.

When the provisioning engine lands in PnP Core and projected fields come back from a join, I’m switching and I’m not looking back.

The first time step seven failed, I got to watch my engine try to create a site that already existed.

That run taught me the rule this post is about: in a long provisioning flow, you don’t roll back when something fails. You checkpoint, and you resume forward.

If Durable Functions are new to you, start with my intro to what they are and what they can do - this post builds on it.

Why Rollback Is the Wrong Instinct

When provisioning fails at step seven, you have a half-built site. The textbook answer is a compensation saga: undo steps six through one in reverse order. Delete the folders, detach the template, deactivate the features, delete the site, then recreate everything from scratch on the next attempt.

I started sketching that and stopped halfway through the list, because every line was either dangerous or absurd. Deleting a site collection to work around a failed navigation tweak is using a crane to hang a picture. And some steps don’t even have an undo - you can’t meaningfully “unapply” a provisioning template that merged fields into existing lists.

Here’s the thing rollback ignores: the six completed steps aren’t damage. They’re progress. The site is fine; what’s missing is the steps that haven’t run yet. So the only recovery that makes sense is forward: figure out where the run stopped, and continue from there.

That reframes the problem completely. I don’t need compensation logic. I need to know, reliably, which steps finished.

Carry the Progress in the State

Durable Functions makes this natural, because an orchestrator already passes state to each activity and gets state back. The trick is to make “what’s done” part of that state. My orchestration state looks something like this:

public sealed record SiteSetupState(
    string CustomerId,
    string SiteUrl,
    string[] CompletedSteps
);

And the orchestrator walks its steps like this:

var state = context.GetInput<SiteSetupState>() ?? await CreateSite(context, customerId);

string[] pipeline =
[
    nameof(ActivateFeatures),
    nameof(ApplyTemplate),
    nameof(SeedFolders),
    nameof(AddMemberGroups),
    nameof(RegisterSite),
];

foreach (var step in pipeline)
{
    if (state.CompletedSteps.Contains(step))
    {
        logger.LogInformation("{Step} already completed, skipping.", step);
        continue;
    }

    await context.CallActivityAsync(step, state, retryOptions);

    state = state with { CompletedSteps = [.. state.CompletedSteps, step] };
    context.SetCustomStatus(state);
}

What’s happening here?

1. The pipeline is just an ordered list of activity names. Nothing clever, and that’s the point - the interesting machinery is around the calls, not in them.
2. Before each step, the orchestrator checks whether this step already ran. On a fresh run the array is empty and nothing is skipped. On a resumed run, this check is what fast-forwards past the finished work.
3. After each successful step, the state is copied with the step name appended. An immutable with copy, so nothing mutates in place, which keeps replays honest.
4. SetCustomStatus publishes the updated state on the orchestration instance. This is the checkpoint. It costs one line.

That last line is doing more work than it looks like. Custom status is readable from outside the orchestration - through the management API, without touching the orchestration history. So the same call gives you two things: anyone polling the instance sees live progress (“three of six steps done”), and if the run fails, the last published state is sitting right there, telling you exactly where it stopped.

Resume Is Just Input

Because the checkpoint is a plain serializable record, resuming a failed run doesn’t need any special framework support. You read the failed instance’s custom status, and you start a new orchestration with that state as input:

var failed = await client.GetInstanceAsync(failedInstanceId, getInputsAndOutputs: true);
var checkpoint = failed.ReadCustomStatusAs<SiteSetupState>();

await client.ScheduleNewOrchestrationInstanceAsync(
    nameof(SiteSetupOrchestrator),
    checkpoint);

The new run enters the same loop, finds five steps in CompletedSteps, skips them in about a millisecond, and picks up at step six. No site deletion, no re-creation, no duplicate template apply. The half-built site becomes a five-sixths-built site, then a finished one.

I like how little there is to this. The “resume feature” is the skip-check in the loop plus the fact that the input type and the checkpoint type are the same type. That’s it.

The Gap That Idempotency Covers

One honest caveat. The checkpoint is written after the activity succeeds, so there’s a window: the activity finishes, the process dies before the checkpoint lands. On resume, that step’s name isn’t in CompletedSteps, and it runs again.

You can’t close that window - it’s inherent to doing the work and recording the work as two operations. What you do instead is make every activity safe to run twice: check before create, treat “already exists” as success, write with upserts. That’s a full topic on its own, but the division of labor is worth stating plainly: the checkpoint decides how often steps rerun, idempotency decides whether reruns hurt. You need both. The checkpoint alone has a crash window; idempotency alone means re-executing ten minutes of finished work on every hiccup.

And never checkpoint before the call to close the window from the other side - then a crashed step gets skipped on resume, which is far worse. A step that runs twice is a wasted minute; a step that runs zero times is a broken site that says “Completed”. Ask me how I know.

Gotchas

• Use the replay-safe logger. Orchestrator code replays from history every time the instance wakes up. context.CreateReplaySafeLogger(...) keeps your logs from repeating every completed step on each replay. A regular ILogger in an orchestrator will gaslight you.
• No clocks, no GUIDs in the orchestrator. DateTime.UtcNow, Guid.NewGuid(), and Random produce different values on replay and corrupt the history. Anything nondeterministic belongs inside an activity, including generated names and timestamps you want in the state.
• Custom status has a size limit (16 KB of JSON). A record with a customer ID, a URL, and an array of step names fits hundreds of times over, but don’t stuff a whole template or file manifest in there. Checkpoint the position, not the payload.
• Step names are a contract. The moment CompletedSteps is persisted anywhere - a failed instance you might resume next week - renaming an activity breaks the match and the step silently reruns (fine, if idempotent) or the resume misbehaves (not fine). Rename with the same care you’d give a database column.
• Report progress somewhere humans look. Custom status is great for machines; my engine also writes the current step name to a status column in the site inventory list, inside a try/catch that logs and swallows. A cosmetic status write must never kill a provisioning run.

Wrapping Up

Long provisioning flows fail in the middle, so design for resuming instead of undoing: carry a list of completed steps in the orchestration state, publish it as custom status after every step, skip completed steps on rerun, and feed the saved state back in to resume. Rollback is for databases. Provisioning goes forward.

When building automated site provisioning, every Microsoft 365 group creation triggers a welcome email to each member by default. In an automated scenario where multiple groups are created at once, that quickly turns into a flood of emails your users didn’t ask for — and they’re going to call it spam.

Microsoft documents WelcomeEmailDisabled as a supported option, but doesn’t show you how to actually set it from the Graph SDK in C#. That’s what this post is about.

The Weird Part: AdditionalData

If you look at the typed Group object in the SDK, you won’t find a ResourceBehaviorOptions property anywhere. It has to be set through AdditionalData — a catch-all dictionary for properties that exist in the Graph API but aren’t modeled as first-class typed properties in the SDK.

It works fine, but it does mean you lose IntelliSense and compile-time safety. The same pattern applies to owners@odata.bind and members@odata.bind, which let you assign owners and members at creation time without separate follow-up calls.

The Solution

Here’s the complete group creation request with welcome emails disabled, owners set, and members added — all in a single API call:

var ownerId = $"https://graph.microsoft.com/v1.0/users/{ownerObjectId}";
var groupMembers = new List<string>
{
    $"https://graph.microsoft.com/v1.0/users/{memberObjectId1}",
    $"https://graph.microsoft.com/v1.0/users/{memberObjectId2}"
};

Group requestBody = new()
{
    Description = description,
    DisplayName = displayName,
    GroupTypes = ["Unified"],
    MailEnabled = false,
    MailNickname = siteName,
    SecurityEnabled = true,
    AdditionalData = new Dictionary<string, object>
    {
        { "resourceBehaviorOptions", new List<string> { "WelcomeEmailDisabled" } },
        { "owners@odata.bind", new List<string> { ownerId } },
        { "members@odata.bind", groupMembers }
    }
};

Group? group = await _graphClient.Groups.PostAsync(requestBody);

resourceBehaviorOptions

resourceBehaviorOptions controls specific group behaviors at creation. WelcomeEmailDisabled simply stops Microsoft 365 from sending the welcome email to members.

You can also combine multiple options in the same list if needed:

{ "resourceBehaviorOptions", new List<string> { "WelcomeEmailDisabled", "HideGroupInOutlook" } }

Other supported values are documented here.

owners@odata.bind and members@odata.bind

The @odata.bind syntax binds users to the group by their full resource URL at creation time, so you don’t need separate POST /groups/{id}/members calls afterward. The URL format must be the full Graph v1.0 path:

https://graph.microsoft.com/v1.0/users/{objectId}

We’ve all tried creating a SharePoint list without using Content Types from the start. It seems like the quick solution, but it can lead to challenges later when restructuring the list. This post explains why using Content Types from the beginning is a smart move that can save time and hassle in the long run.

This has been a recurring issue for me 😅 – countless times I’ve started a SharePoint list without Content Types, only to realize later that I needed the list for tasks like search 🔍 or advanced filtering. And, of course, it usually happens when the list is already full of data 📊 without any associated Content Type, making it even more challenging 🛠️ to get everything to work smoothly.

⚠️ Disclaimer: This will only work if the columns in the Content Type match those already present in the list.

How Do I Fix It? 🤔

The first step is, of course, to create a content type. Once it’s created, I then export it as a template using the PnP PowerShell command Get-PnPSiteTemplate 💻. I make sure that only the content type is included in the XML file 📂.

Once the PnP template is ready, a PowerShell script I created can be used to fix this issue – though it can’t handle all scenarios. The script includes the following variables, which need to be filled out:

$siteUrl = "https://xxx.sharepoint.com/sites/xxx"
$listName = ""
$contentTypeName = ""
$columnsToMap = @("...")  # Replace with the actual column names
$userFields = @("...")  # Replace with actual user field names if needed
$templatePath = "..\ContentTypeTemplate.xml";

What the script does is fairly simple 🛠️ – I load all rows with their values into memory 🧠, remove the columns ($columnsToMap) that need to be deleted 🗑️, then invoke the PnP template containing the content type. Finally, I reload all values into the new columns. Since they have the same names as the old columns, everything loads smoothly ✅.

# Connect to SharePoint Online
Connect-PnPOnline -Url $siteUrl -Interactive

# Enable content type management on the list
Set-PnPList -Identity $listName -EnableContentTypes $true
Write-Host "Content types enabled on the list."

# Backup data from old columns
$items = Get-PnPListItem -List $listName -PageSize 2000
$backupData = @{}

foreach ($item in $items) {
    $itemData = @{}
    # Backup old column data
    foreach ($column in $columnsToMap) {
        $itemData[$column] = $item[$column]
    }
    $backupData[$item.Id] = $itemData
}

# Remove old columns
foreach ($column in $columnsToMap) {
    Remove-PnPField -List $listName -Identity $column -Force
    Write-Host "Removed old column:" $column
}

# Apply PnP Provisioning Template
Invoke-PnPSiteTemplate -Path $templatePath
Write-Host "PnP template applied to the site."

# Get the content type
$contentType = Get-PnPContentType -Identity $contentTypeName

# Add the content type to the list
Add-PnPContentTypeToList -List $listName -ContentType $contentType
Write-Host "Content type added to the list."

# Update items to the new content type and restore data to new columns
foreach ($item in $items) {
    $itemId = $item.Id
    $itemData = $backupData[$itemId]
    
    # Handle user fields
    foreach ($userField in $userFields) {
        if ($itemData[$userField]) {
            $UserDto = $itemData[$userField];
            write-host "User: " $UserDto.Email

            $itemData[$userField] = $UserDto.Email
        }
    }

    # Update item content type
    Set-PnPListItem -List $listName -Identity $itemId -Values @{"ContentTypeId" = $contentType.Id }
    
    # Restore data to new columns
    Set-PnPListItem -List $listName -Identity $itemId -Values $itemData
    Write-Host "Updated item ID:" $itemId
}

Write-Host "All items updated to the new content type and old columns removed."

# Disconnect from SharePoint Online
Disconnect-PnPOnline

As mentioned earlier, this script doesn’t solve everything. For example, any views created with the old columns will no longer work, even if the new columns have the same name. So, there’s definitely room for improvement in my script.

That said, the script has saved me quite a bit of manual work multiple times 🙌.