#microsoftgraph — Public Fediverse posts

Nation-State Actors Exploit ROADtools in Cloud Attacks

Cloud attackers are now leveraging ROADtools, a publicly available toolkit, to exploit vulnerabilities in cloud tenants, allowing them to persist, discover, and evade defenses with ease. This dual-use framework's ability to speak Entra ID and Microsoft Graph makes it a red flag for defenders to take notice.

https://osintsights.com/nation-state-actors-exploit-roadtools-in-cloud-attacks?utm_source=mastodon&utm_medium=social

#CloudAttacks #NationState #Roadtools #EntraId #MicrosoftGraph

ESET uncovers the expanded arsenal of China-aligned Webworm; European governments targeted

ESET ESET Research uncovered and analyzed the latest activities and arsenal of China-aligned Webworm advanced persistent threat (APT)…
#Europe #EU #Arsenal #Discord #EricHoward #ESET #European #MicrosoftGraph #Webworm
https://www.europesays.com/europe/48253/

The SharePoint Architect’s Secret: Programmatic Deployment

2,131 words, 11 minutes read time.

If you are still clicking “New List” in a SharePoint production environment, you aren’t an architect; you’re a hobbyist playing with a high-stakes enterprise tool. You might think that manual setup is “faster” for a small SPFx project, but you are actually just leaking technical debt into your future self’s calendar.

Every manual click is a variable you didn’t account for, a point of failure that will inevitably crash your web part when a user renames a column or deletes a choice. Real developers don’t hope the environment is ready—they command it to be ready through code that is as immutable as a compiled binary.

The hard truth is that most SPFx “experts” are actually just CSS skinners who are terrified of the underlying REST API and the complexity of PnPjs. They build beautiful interfaces on top of shaky, manually-created schemas that crumble the moment the solution needs to scale or move to a different tenant.

If your deployment process involves a PDF of “Manual Setup Instructions” for an admin, you have already failed the first test of professional engineering: repeatability. Your job isn’t to make it work once; it’s to ensure it can never work incorrectly, no matter who is at the keyboard.

We are going to break down the two primary schools of thought in programmatic provisioning: the legacy XML “Old Guard” and the modern PnPjs “Fluent” approach. Both have their place in the trenches, but knowing when to use which is what separates the senior lead from the junior dev who just copies and pastes from Stack Overflow.

Consistency is the only thing that saves you when the deployment window is closing and the client is breathing down your neck. If you don’t have a script that can “Ensure” your list exists exactly as the code expects it, you are just waiting for a runtime error to ruin your weekend.

The Blueprint: Our Target “Project Contacts” List

Before we write a single line of provisioning code, we define the contract. Our SPFx web part expects a list named “ProjectContacts” with the following technical specifications:

• Title: (Standard) The person’s Full Name.
• EmailAddr: (Text) Their primary corporate email.
• MailingAddress: (Note/Multiline) The full street address.
• City: (Text) The shipping/mailing city.
• IsActive: (Boolean) A toggle to verify if this contact is still valid.
• LinkedInProfile: (URL) A link to their professional profile.

If any of these internal names are missing or mapped incorrectly, your SPFx get request will return a 400 Bad Request, and your UI will render as a broken skeleton.

Method A: The XML Schema (The “Old Guard” Precision)

Most juniors look at a block of SharePoint XML and recoil like they’ve seen a memory leak in a legacy C++ driver. They want everything to be clean JSON or fluent TypeScript because it’s easier to read, but they forget that SharePoint’s soul is still written in that rigid, unforgiving XML.

When you use createFieldAsXml, you are speaking the native language of the SharePoint engine. This bypasses the abstractions that sometimes lose detail in translation. This isn’t about being “old school”; it’s about precision. A field’s InternalName is its DNA—if you get it wrong, the entire system rejects the transplant.

I’ve seen dozens of SPFx projects fail because a developer relied on a Display Name that changed three months later, breaking every query in the solution. By using the XML method, you hard-code the StaticName and ID, ensuring that no matter what a “Site Owner” does in the UI, your code remains functional.

 // The Veteran's Choice: Precision via XML  const emailXml = `<Field Type="Text" Name="EmailAddr" StaticName="EmailAddr" DisplayName="E-Mail Address" Required="TRUE" />`;  const addressXml = `<Field Type="Note" Name="MailingAddress" StaticName="MailingAddress" DisplayName="Mailing Address" Required="FALSE" RichText="FALSE" />`;   await list.fields.createFieldAsXml(emailXml);  await list.fields.createFieldAsXml(addressXml); 

Using XML is a choice to be the master of the metadata, rather than a passenger on the SharePoint UI’s whims. It requires a level of discipline that most developers lack because you have to account for every attribute without a compiler to hold your hand. If your personal “schema” is well-defined and rigid, you can handle the pressure of any deployment. If it’s loose, you’re just waiting for a runtime crash.

Method B: The Fluent API (The Modern “Clean Code” Protocol)

If Method A is the raw assembly, Method B is your high-level compiled language. The PnPjs Fluent API is designed for the developer who values readability and speed without sacrificing the “Ensure” logic required for professional-grade software.

Instead of wrestling with strings and angle brackets, you use strongly-typed methods. This is where the modern architect lives. It reduces the “surface area” for errors. You aren’t guessing if you closed a tag; the IDE tells you if your configuration object is missing a required property. This is the “Refactored” life—eliminating the noise so you can focus on the logic.

 // The Modern Protocol: Type-Safe Fluent API  await list.fields.addText("City", {      Title: "City",      Required: false  });   await list.fields.addBoolean("IsActive", {      Title: "Is Active",      DefaultValue: "1" // True by default  });   await list.fields.addUrl("LinkedInProfile", {      Title: "LinkedIn Profile",      Required: false  }); 

The “Fluent” way mirrors a man who has his protocols in place. You don’t have to over-explain; the code speaks for itself. It’s clean, it’s efficient, and it’s easily maintained by the next guy on the team. But don’t let the simplicity fool you—you still need the “Check-then-Create” logic (Idempotency) to ensure your script doesn’t blow up if the list already exists.

The Idempotency Protocol: Building Scripts That Don’t Panic

In the world of high-stakes deployment, “hope” is not a strategy. You cannot assume the environment is a blank slate. Maybe a junior dev tried to “help” by creating the list manually. Maybe a previous deployment timed out halfway through the schema update. If your code just tries to add() a list that already exists, it will throw a 400 error and crash the entire initialization sequence of your SPFx web part.

Professional engineering requires Idempotency—the ability for a script to be run a thousand times and yield the same result without side effects. Your code needs to be smart enough to look at the site, recognize what is already there, and only provision the delta. This is where you separate the “script kiddies” from the architects. You aren’t just writing a “Create” script; you are writing an “Ensure” logic.

 // The Architect's Check: Verify before you Commit  try {      await sp.web.lists.getByTitle("ProjectContacts")();      console.log("Infrastructure verified. Proceeding to field check.");  } catch (e) {      console.warn("Target missing. Initializing Provisioning Protocol...");      await sp.web.lists.add("ProjectContacts", "Centralized Stakeholder Directory", 100, true);  } 

This logic mirrors the way a man should handle his own career and reputation. You don’t just “show up” and hope things work out; you audit the environment, you check for gaps in your own “schema,” and you provision the skills you’re missing before the deadline hits. If you aren’t checking your own internal “code” for errors daily, you’re eventually going to hit a runtime exception that you can’t recover from.

Stability is built in the hidden layers. Most people only care about the UI, the “pretty” part of the SPFx web part that the stakeholders see. But if your hidden provisioning logic is sloppy, the UI is just a facade on a crumbling foundation. Integrity in the hidden functions leads to integrity in the final product.

The View Layer: Controlling the Perspective

A list is a database, but a View is the interface. If you provision the fields but leave the “All Items” view in its default state, you are forcing the user to manually configure the UI—which defeats the entire purpose of programmatic deployment. You have to dictate exactly how the data is presented. This is about leadership; you don’t leave the “perspective” of your data to chance.

When we provision the ProjectContacts view, we aren’t just adding columns; we are defining the “Load-Bearing” information. We decide that the EmailAddr and IsActive status are more important than the CreatedDate. We programmatically remove the fluff and surface the metrics that matter.

 // Dictating the Perspective: View Configuration  const list = sp.web.lists.getByTitle("ProjectContacts");  const view = await list.defaultView();   const columns = ["Title", "EmailAddr", "City", "IsActive"];  for (const name of columns) {      await list.views.getById(view.Id).fields.add(name);  } 

In your own life, you have to be the architect of your own “View.” If you let the world decide what “columns” of your life are visible, they’ll focus on the trivial. You have to programmatically decide what matters—your output, your stability, and your leadership. If you don’t define the view, someone else will, and they’ll usually get it wrong.

Refactoring a messy View is the same as refactoring a messy life. It’s painful, it requires deleting things that people have grown used to, and it demands a cold, hard look at what is actually functional. But once the script runs and the View is clean, the clarity it provides is worth the effort of the build.

The Closeout: No Excuses, Just Execution

We have covered the precision of the XML “Old Guard” and the efficiency of the Fluent API. We have established that manual clicks are a form of technical failure and that idempotency is the only way to survive a production deployment.

The “Secret” to being a SharePoint Architect isn’t some hidden knowledge or a certification; it’s the discipline to never take the easy way out. It’s the refusal to ship code that requires a “Manual Step” PDF. It’s the commitment to building infrastructure that is as solid as the hardware it runs on.

If your SPFx solutions are still failing because of “missing columns” or “wrong list names,” stop blaming the platform and start looking at your deployment protocol. Refactor your scripts. Harden your schemas. Stop acting like a junior and start provisioning like an architect.

You have the blueprints. You have the methods. Now, get into the codebase and eliminate the manual debt that is dragging down your career. The system is waiting for your command.

*******

These final modules are your implementation blueprints—the raw, compiled logic of the two provisioning protocols we’ve discussed. I’ve separated them so you can see exactly how the XML Precision and Fluent API approaches look when deployed in a production-ready TypeScript environment.

One is your “Old Guard” assembly for absolute schema control, and the other is your modern, refactored protocol for speed and type-safety. Treat these as the “gold master” files for your SPFx initialization; copy them, study the differences in the dependency injection, and stop guessing how your infrastructure is built.

ensureProjectContactsXML.ts

 // Filename: ensureProjectContactsXML.ts  import { SPFI } from "@pnp/sp";  import "@pnp/sp/webs";  import "@pnp/sp/lists";  import "@pnp/sp/fields";   /**   * PROVISIONING PROTOCOL: XML SCHEMA   * Use this when absolute precision of InternalNames and StaticNames is non-negotiable.   */  export const ensureProjectContactsXML = async (sp: SPFI): Promise<void> => {    const LIST_NAME = "ProjectContacts";    const LIST_DESC = "Centralized Stakeholder Directory - XML Provisioned";     try {      // 1. IDEMPOTENCY CHECK: Does the infrastructure exist?      try {        await sp.web.lists.getByTitle(LIST_NAME)();      } catch {        // 2. INITIALIZATION: Build the foundation        await sp.web.lists.add(LIST_NAME, LIST_DESC, 100, true);      }       const list = sp.web.lists.getByTitle(LIST_NAME);       // 3. SCHEMA INJECTION: Speaking the native tongue of SharePoint      const fieldsToCreate = [        `<Field Type="Text" Name="EmailAddr" StaticName="EmailAddr" DisplayName="E-Mail Address" Required="TRUE" />`,        `<Field Type="Note" Name="MailingAddress" StaticName="MailingAddress" DisplayName="Mailing Address" Required="FALSE" RichText="FALSE" />`,        `<Field Type="Text" Name="City" StaticName="City" DisplayName="City" Required="FALSE" />`      ];       for (const xml of fieldsToCreate) {        // We don't check for existence here for brevity, but a Lead would.        await list.fields.createFieldAsXml(xml);      }       console.log("XML Provisioning Protocol Complete.");    } catch (err) {      console.error("Critical Failure in XML Provisioning:", err);      throw err;    }  }; 

ensureProjectContactsFluent.ts

 // Filename: ensureProjectContactsFluent.ts  import { SPFI } from "@pnp/sp";  import "@pnp/sp/webs";  import "@pnp/sp/lists";  import "@pnp/sp/fields";   /**   * PROVISIONING PROTOCOL: FLUENT API   * Use this for high-speed, readable, and type-safe infrastructure deployment.   */  export const ensureProjectContactsFluent = async (sp: SPFI): Promise<void> => {    const LIST_NAME = "ProjectContacts";        try {      // 1. INFRASTRUCTURE AUDIT      let listExists = false;      try {        await sp.web.lists.getByTitle(LIST_NAME)();        listExists = true;      } catch {        await sp.web.lists.add(LIST_NAME, "Stakeholder Directory - Fluent Provisioned", 100, true);      }       const list = sp.web.lists.getByTitle(LIST_NAME);       // 2. LOAD-BEARING FIELDS: Strongly typed and validated      // Provisioning the Boolean 'IsActive'      await list.fields.addBoolean("IsActive", {        Title: "Is Active",        Group: "Project Metadata",        DefaultValue: "1" // True      });       // Provisioning the URL 'LinkedInProfile'      await list.fields.addUrl("LinkedInProfile", {        Title: "LinkedIn Profile",        Required: false      });       console.log("Fluent API Provisioning Protocol Complete.");    } catch (err) {      console.error("Critical Failure in Fluent Provisioning:", err);      throw err;    }  }; 

Call to Action

If this post sparked your creativity, don’t just scroll past. Join the community of makers and tinkerers—people turning ideas into reality with 3D printing. Subscribe for more 3D printing guides and projects, drop a comment sharing what you’re printing, or reach out and tell me about your latest project. Let’s build together.

D. Bryan King

Sources

• PnPjs Documentation: Working with Lists
• Microsoft Learn: SharePoint Framework (SPFx) Fundamentals
• PnPjs Documentation: Field Provisioning
• Microsoft Documentation: Field XML Schema Reference
• PnPjs Documentation: View Management
• PnPjs Concepts: Request Batching for Performance
• Microsoft Guidance: Using PnPjs in SPFx Projects
• PnPjs Documentation: Web and Site Operations
• SharePoint PnP Provisioning Framework Overview
• PnPjs GitHub Repository: Community Standard for SharePoint JS

Disclaimer:

The views and opinions expressed in this post are solely those of the author. The information provided is based on personal research, experience, and understanding of the subject matter at the time of writing. Readers should consult relevant experts or authorities for specific guidance related to their unique situations.

Related Posts

Rate this:

𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗚𝗿𝗮𝗽𝗵 𝗔𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝗟𝗼𝗴 𝗶𝘀 𝗡𝗼𝘄 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝗣𝘂𝗯𝗹𝗶𝗰 𝗣𝗿𝗲𝘃𝗶𝗲𝘄

With Microsoft Graph Activity Logs, you can now investigate the complete picture of activity in your tenant – from token request in SignIn logs, to API request activity (reads, writes, and deletes) in Microsoft Graph Activity Logs, to ultimate resource changes in Audit logs.

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-graph-activity-log-is-now-available-in-public-preview/ba-p/3848269

#microsoft #entra #entraid #azuread #graph #microsoftgraph #log #idp #identity #azure #API #soc #itdr #security #cybersecurity #siem #soc #monitoring #loganalytics #sentinel #hunting #cyberthreat #identity #identityprovider #microsoftsecurity

𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗚𝗿𝗮𝗽𝗵 𝗔𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝗟𝗼𝗴 𝗶𝘀 𝗡𝗼𝘄 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝗣𝘂𝗯𝗹𝗶𝗰 𝗣𝗿𝗲𝘃𝗶𝗲𝘄

With Microsoft Graph Activity Logs, you can now investigate the complete picture of activity in your tenant – from token request in SignIn logs, to API request activity (reads, writes, and deletes) in Microsoft Graph Activity Logs, to ultimate resource changes in Audit logs.

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-graph-activity-log-is-now-available-in-public-preview/ba-p/3848269

#microsoft #entra #entraid #azuread #graph #microsoftgraph #log #idp #identity #azure #API #soc #itdr #security #cybersecurity #siem #soc #monitoring #loganalytics #sentinel #hunting #cyberthreat #identity #identityprovider #microsoftsecurity

𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗚𝗿𝗮𝗽𝗵 𝗔𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝗟𝗼𝗴 𝗶𝘀 𝗡𝗼𝘄 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝗣𝘂𝗯𝗹𝗶𝗰 𝗣𝗿𝗲𝘃𝗶𝗲𝘄

With Microsoft Graph Activity Logs, you can now investigate the complete picture of activity in your tenant – from token request in SignIn logs, to API request activity (reads, writes, and deletes) in Microsoft Graph Activity Logs, to ultimate resource changes in Audit logs.

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-graph-activity-log-is-now-available-in-public-preview/ba-p/3848269

#microsoft #entra #entraid #azuread #graph #microsoftgraph #log #idp #identity #azure #API #soc #itdr #security #cybersecurity #siem #soc #monitoring #loganalytics #sentinel #hunting #cyberthreat #identity #identityprovider #microsoftsecurity

𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗚𝗿𝗮𝗽𝗵 𝗔𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝗟𝗼𝗴 𝗶𝘀 𝗡𝗼𝘄 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝗣𝘂𝗯𝗹𝗶𝗰 𝗣𝗿𝗲𝘃𝗶𝗲𝘄

With Microsoft Graph Activity Logs, you can now investigate the complete picture of activity in your tenant – from token request in SignIn logs, to API request activity (reads, writes, and deletes) in Microsoft Graph Activity Logs, to ultimate resource changes in Audit logs.

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-graph-activity-log-is-now-available-in-public-preview/ba-p/3848269

#microsoft #entra #entraid #azuread #graph #microsoftgraph #log #idp #identity #azure #API #soc #itdr #security #cybersecurity #siem #soc #monitoring #loganalytics #sentinel #hunting #cyberthreat #identity #identityprovider #microsoftsecurity

𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗚𝗿𝗮𝗽𝗵 𝗔𝗰𝘁𝗶𝘃𝗶𝘁𝘆 𝗟𝗼𝗴 𝗶𝘀 𝗡𝗼𝘄 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗶𝗻 𝗣𝘂𝗯𝗹𝗶𝗰 𝗣𝗿𝗲𝘃𝗶𝗲𝘄

With Microsoft Graph Activity Logs, you can now investigate the complete picture of activity in your tenant – from token request in SignIn logs, to API request activity (reads, writes, and deletes) in Microsoft Graph Activity Logs, to ultimate resource changes in Audit logs.

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-graph-activity-log-is-now-available-in-public-preview/ba-p/3848269

#microsoft #entra #entraid #azuread #graph #microsoftgraph #log #idp #identity #azure #API #soc #itdr #security #cybersecurity #siem #soc #monitoring #loganalytics #sentinel #hunting #cyberthreat #identity #identityprovider #microsoftsecurity

🎤 On Stage in 5min 🎤 Track 1: @powers-hell.com Track 2: Jan-Hendrik Peters Track 3: @hcritter.bsky.social Track 4: Jonny Eskew #PowerShell #automation #Azure #DevOps #Microsoft365 #AzureAD #MSAL #MicrosoftGraph #Bicep

Are #Microsoft #Entra #AAD admins lurking around here?
I'm at a loss to why Microsoft Graph requires admin consent for OAuth, after granting admin consent, requiring admin consent, after granting admin consent, requiring admin consent, and not persisting that admin consent had already been granted.
And effectively not allowing an OAuth user to sign-in.

https://github.com/iterate-ch/cyberduck/discussions/16424

#Azure #SharePoint #ActiveDirectory #MicrosoftGraph #OneDrive #OAuth

#powershell #microsoftgraph #conditionalaccess Automating Sign-In Analysis with PowerShell and Microsoft Graph http://dlvr.it/TFZ30N via PlanetPowerShell

#MicrosoftGraph #MicrosoftIntune How to rotate BitLocker keys with Microsoft Graph PowerShell http://dlvr.it/T9t5P8 via PlanetPowerShell

#MicrosoftGraph #MicrosoftIntune How to deploy Autopilot Device Preparation Policies with PowerShell http://dlvr.it/T842ck via PlanetPowerShell

#MicrosoftGraph #MicrosoftIntune Report assigned Autopilot profiles with Microsoft Graph PowerShell http://dlvr.it/T826ms via PlanetPowerShell

The Microsoft Graph Python SDK is now available for public preview #MicrosoftGraph #PythonSDK #PublicPreview #sharegeneratedinpartwithgpt3 https://techcommunity.microsoft.com/t5/educator-developer-blog/microsoft-graph-python-sdk-public-preview/ba-p/3686110

New MiToken Graph PowerShell module for multi-tenant apps http://dlvr.it/TJkkv9 via PlanetPowerShell #MicrosoftGraph #PowerShell #MultiTenant #CloudComputing

Graph: modificare facilmente gruppi Entra via PowerShell https://gioxx.org/2025/09/10/graph-modificare-facilmente-gruppi-entra-via-powershell

#accountutente #lavoro #microsoft #microsoft365 #microsoftazure #microsoftentra #microsoftgraph #powershell #powershellpermicrosoft365

Graph: confronta una lista di membri con quelli di un gruppo Entra via PowerShell https://gioxx.org/2024/10/01/graph-confronta-una-lista-di-membri-con-quelli-di-un-gruppo-entra-via-powershell
#accountutente #lavoro #microsoft #microsoft365 #microsoftazure #microsoftentra #microsoftgraph #powershell #powershellpermicrosoft365

Graph: confronta una lista di membri con quelli di un gruppo Entra via PowerShell

https://gioxx.org/2024/10/01/graph-confronta-una-lista-di-membri-con-quelli-di-un-gruppo-entra-via-powershell/

#Lavoro #AccountUtente #Lavoro #Microsoft #Microsoft365 #MicrosoftAzure #MicrosoftEntra #MicrosoftGraph #PowerShell #PowerShellPerMicrosoft365

PowerShell 7: disattivazione di un servizio Microsoft 365 via Graph

https://gioxx.org/2023/09/18/powershell-7-disattivazione-di-un-servizio-microsoft-365-via-graph/

#Lavoro #AccountUtente #CSV #InEvidenza #Lavoro #Microsoft #Microsoft365 #MicrosoftExchange #MicrosoftGraph #MicrosoftOffice #PowerShell #PowerShellPerMicrosoft365 #Skype

TWO long-awaited #MicrosoftGraph features now in preview:

- #SharePoint Pages API (create and modify SP pages programmatically) https://bit.ly/3XeTxSI
- #MicrosoftPlanner App Permissions (create and manage plans w/o a user account e.g. provisioning scenarios) https://bit.ly/3GtZ9ll

What a way to start the new year!

Some Graph API fun today.

The Graph API knows `applications` (https://learn.microsoft.com/en-us/graph/api/resources/application) and `servicePrincipals` (https://learn.microsoft.com/en-us/graph/api/resources/serviceprincipal).

The Azure Portal knows `App Registrations` and `Enterprise Applications`.

App Registrations (Portal) = applications (Graph API)
Enterprise Applications (Portal) = servicePrincipals (Graph API)

Applications (App Registrations) and servicePrincipals (Enterprise Applications) have a unique, individual `ObjectId` but the ones that belong together hold the same `ApplicationId` which glues them together.

Fortunately, the Graph API documentation is clear and relatively consistent on what is expected for requesting an object - either the `objectId` or the `applicationId`:

```
GET /servicePrincipals/{id}
GET /servicePrincipals(appId='{appId}')
GET /applications/{applicationObjectId}
GET /applications(appId='{appId}')
```

When searching for servicePrincipals (Enterprise Applications) in the portal, it is not that clear since the terms are mixed up a bit.

#azure #graphapi #entraid #azuread #MicrosoftGraph

Building a SharePoint File Lister with .NET 8 + Microsoft Graph Device Code Flow 💻
Secure, fast & developer-approved. Walkthrough with code + best practices.
#MicrosoftGraph #SharePoint #DotNet

https://bdking71.wordpress.com/2025/10/06/cracking-the-code/?utm_source=mastodon&utm_medium=jetpack_social

🟪 Connect Jira Cloud with Microsoft 365 Copilot
Access Jira issues and tasks from Copilot and Teams—no app switching required. 🚀

This integration uses semantic indexing so Copilot can query Jira data conversationally. Admins can add the Jira Cloud connector in the Microsoft 365 Admin Center and enable the Teams plugin.

▶︎ https://www.hubsite365.com/en-ww/pro-office-365/?id=7ac9febb-b690-f011-b4cc-7c1e52134a37&topic=9f678e9a-8cd4-ec11-a7b5-6045bd92fe52&theater=true

💡 Access Jira in Copilot & Search
🔍 Semantic indexing surfaces structured Jira data
⚖️ Respects permissions & security boundaries

Want a quick setup checklist or demo?
#MICROSOFT365COPILOT #JIRA #MICROSOFTGRAPH #COPILOT

Today is my first day on the #Azure #OpenAI team! Also I've celebrated 5 years at Microsoft not long ago.

I'm grateful to all of those who help me grow and build cool stuff for #MicrosoftGraph #APIs and more. (they know who they are :) )

https://baywet.github.io/5-years-and-new-role/

Why is #MicrosoftGraph #MicrosoftEntra so fucking obnoxious?

I can't - using the web interface - remove user permissions granted to an enterprise app?

#Microsoft

P.Gruenauer: Managing Guest Users in #PowerShell with #MicrosoftGraph API

https://sid-500.com/2025/06/02/managing-guest-users-in-powershell-with-microsoft-graph-api/

Are you tired of manually checking the Message Center in the M365 Admin Center every day? 🚀

Do you know there are alternatives to make your M365 administrator life easier?

The Microsoft Graph provides endpoints to retrieve the information you need, including messages from the Message Center 😯. The endpoint is called "Service Announcement" and the URL is /admin/serviceAnnouncement/messages.

How can you benefit from this? Well, you can create your own automations to inform you about the latest updates and send the proper warnings based on the properties of the updates. Imagine having all the latest updates delivered to you without lifting a finger!

🔗 Learn more about the endpoint here: https://learn.microsoft.com/en-us/graph/api/serviceannouncement-list-messages?view=graph-rest-1.0&tabs=http

Don't miss out on this opportunity to enhance your M365 administration experience.

#M365 #MicrosoftGraph #Automation #Productivity #MVPBuzz #M365Governance

New MiToken Graph PowerShell module for multi-tenant apps http://dlvr.it/TJpr1d via PlanetPowerShell #MiToken #PowerShell #MicrosoftGraph #CloudComputing

Also #MicrosoftGraph API: You just asked for "/me/drive/sharedItems"? Great, here is one of many entries, which we just skip the id field in.

Great, idiots.

#Microsoft #MicrosoftGraph Drive-API returns account ids in all lower or all upper case as it sees fit.
What a mess.

Create Entra ID Guest invite using PowerShell and Graph API http://dlvr.it/TJQBh5 via PlanetPowerShell #PowerShell #GraphAPI #EntraID #MicrosoftGraph

Microsoft Graph PowerShell SDK V2.26.1 Remains Flawed http://dlvr.it/TJPpwK via PlanetPowerShell #MicrosoftGraph #PowerShell #SDK #TechNews

#MicrosoftEntra #MicrosoftGraph Proof of possession, Token Protection and Graph PowerShell, what’s next? http://dlvr.it/TGRn4x via PlanetPowerShell

#MicrosoftEntra #MicrosoftGraph Report license usage rights with Microsoft Graph PowerShell http://dlvr.it/TFYc8d via PlanetPowerShell

Function cannot be created because function capacity 4096 has been exceeded for this scope http://dlvr.it/TJK8Kp via PlanetPowerShell #MicrosoftGraph #PowerShell #ErrorHandling #TechTroubleshooting

SPFx State Management: Solving State Complexity in the SharePoint Framework

2,018 words, 11 minutes read time.

The Evolution of State in the SharePoint Framework

The transition from the “Classic” SharePoint era to the modern SharePoint Framework (SPFx) represents more than just a change in tooling; it marks a fundamental shift in how developers must manage data persistence and component synchronization. In the early days of client-side customization, state was often handled implicitly through the DOM or global variables, a practice that led to fragile, difficult-to-maintain scripts. Today, as we build sophisticated, multi-layered applications using React and TypeScript, state management has become the primary determinant of application stability and performance. Within a shared environment like SharePoint Online, where a single page may host multiple independent web parts, the complexity of managing shared data—such as user profiles, list items, and configuration settings—requires a disciplined architectural approach. Failing to implement a robust state strategy often results in “jank,” data inconsistency, and a bloated memory footprint that negatively impacts the end-user experience.

When developers rely solely on localized state within individual components, they often inadvertently create “data silos.” This fragmentation becomes evident when a change in one part of the application—for example, a status update in a details pane—is not reflected in a summary dashboard elsewhere on the page. To solve this, developers must move beyond basic reactivity and toward a model of “deterministic data flow.” This means ensuring that every piece of data has a clear, single source of truth and that updates propagate through the application in a predictable manner. By treating state management as a core engineering pillar rather than a secondary concern, teams can build SPFx solutions that are resilient to the inherent volatility of the browser environment and the frequent updates of the Microsoft 365 platform.

Evaluating Local Component State vs. Centralized Architectures

The most common architectural question in SPFx development is determining when to move beyond React’s built-in useState and props in favor of a centralized store. For simple web parts with a shallow component tree, localized state is often the most performant and maintainable choice. It offers low overhead, high readability, and utilizes React’s core strengths without additional boilerplate. However, as an application grows in complexity, the limitations of this “bottom-up” approach become clear. “Prop-drilling”—the practice of passing data through multiple layers of intermediate components that do not require the data themselves—creates a rigid and fragile structure. This not only makes refactoring difficult but also complicates the debugging process, as tracing the origin of a state change requires navigating through an increasingly complex web of interfaces and callbacks.

 // Example: The complexity of Prop-Drilling in a deep component tree  // This architecture becomes difficult to maintain as the application scales.   interface IAppProps {    currentUser: ISiteUser;    items: IListItem[];    onItemUpdate: (id: number) => void;  }   const ParentComponent: React.FC<IAppProps> = (props) => {    return <IntermediateLayer {...props} />;  };   const IntermediateLayer: React.FC<IAppProps> = (props) => {    // This component doesn't use the props, but must pass them down.    return <DeepChildComponent {...props} />;  };   const DeepChildComponent: React.FC<IAppProps> = ({ items, onItemUpdate }) => {    return (      <div>        {items.map(item => (          <button onClick={() => onItemUpdate(item.Id)}>{item.Title}</button>        ))}      </div>    );  }; 

A centralized state architecture solves this by providing a dedicated layer for data management that exists outside the UI hierarchy. This decoupling allows components to remain “dumb” and focused purely on rendering, while a service layer or store handles the business logic, API calls via PnPjs, and data caching. From a performance perspective, centralized stores that utilize selectors can significantly reduce unnecessary re-renders. Unlike the React Context API, which may trigger a full-tree re-render upon any change to the provider’s value, advanced state managers allow components to subscribe to specific “slices” of data. This granular control is essential for maintaining a high frame rate and responsive UI in complex SharePoint environments where main-thread resources are at a premium.

Implementing the Singleton Service Pattern for Data Consistency

To move beyond the limitations of component-bound logic, lead developers often implement a Singleton Service pattern. This approach centralizes all interactions with the SharePoint REST API or Microsoft Graph into a single, predictable instance that manages its own internal state. By utilizing this pattern, you effectively decouple the Microsoft 365 environment from your React view layer, ensuring that your data fetching logic is not subject to the mounting or unmounting cycles of individual components. In a high-traffic SharePoint tenant, this architecture allows for aggressive caching strategies; the service can determine whether to return an existing array of list items from memory or to initiate a new asynchronous request via PnPjs. This significantly reduces the network overhead and prevents the “double-fetching” phenomenon often seen when multiple web parts or components request the same user profile or configuration data simultaneously.

 // Implementing a Singleton Data Service with PnPjs  import { spfi, SPFI, SPFx } from "@pnp/sp";  import "@pnp/sp/webs";  import "@pnp/sp/lists";  import "@pnp/sp/items";   export class SharePointDataService {    private static _instance: SharePointDataService;    private _sp: SPFI;    private _cache: Map<string, any> = new Map();     private constructor(context: any) {      this._sp = spfi().using(SPFx(context));    }     public static getInstance(context?: any): SharePointDataService {      if (!this._instance && context) {        this._instance = new SharePointDataService(context);      }      return this._instance;    }     public async getListItems(listName: string): Promise<any[]> {      if (this._cache.has(listName)) {        return this._cache.get(listName);      }      const items = await this._sp.web.lists.getByTitle(listName).items();      this._cache.set(listName, items);      return items;    }  } 

The strength of this pattern lies in its ability to maintain data integrity across the entire SPFx web part lifecycle. When a user performs a write operation—such as updating a list item—the service handles the PnPjs call and then immediately updates its internal cache. Any component subscribed to this service or re-invoking its methods will receive the updated data without needing a full page refresh. This creates a highly responsive, “app-like” feel within the SharePoint interface. Furthermore, because the state is held in a standard TypeScript class rather than a React hook, the logic remains testable in isolation. You can write unit tests for your data mutations without the overhead of rendering a DOM or simulating a React environment, which is a critical requirement for enterprise-grade software delivery.

Advanced Patterns: Integrating Redux Toolkit for Multi-Web Part Coordination

For the most complex SharePoint applications—those involving multi-step forms, real-time dashboards, or coordination across several web parts—Redux Toolkit (RTK) provides the industrial-grade infrastructure necessary to manage state at scale. RTK standardizes the “reducer” pattern, ensuring that every state mutation is performed through a dispatched action. This unidirectional flow is vital in the SharePoint Framework because it eliminates the unpredictable side effects associated with shared mutable state. By defining “slices” for different domains, such as a ProjectSlice or a UserSlice, you create a modular architecture where each part of the state is governed by specific logic. This modularity is particularly useful when managing complex asynchronous lifecycles; RTK’s createAsyncThunk allows you to track the exact status of a SharePoint API call—pending, fulfilled, or rejected—and update the UI accordingly.

 // Redux Toolkit Slice for managing SharePoint List State  import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';  import { SharePointDataService } from './SharePointDataService';   export const fetchItems = createAsyncThunk(    'list/fetchItems',    async (listName: string) => {      const service = SharePointDataService.getInstance();      return await service.getListItems(listName);    }  );   const listSlice = createSlice({    name: 'sharepointList',    initialState: { items: [], status: 'idle', error: null },    reducers: {},    extraReducers: (builder) => {      builder        .addCase(fetchItems.pending, (state) => {          state.status = 'loading';        })        .addCase(fetchItems.fulfilled, (state, action) => {          state.status = 'succeeded';          state.items = action.payload;        })        .addCase(fetchItems.rejected, (state, action) => {          state.status = 'failed';          state.error = action.error.message;        });    },  }); 

One of the primary advantages of utilizing Redux in an SPFx context is the ability to leverage the Redux DevTools browser extension. In a complex tenant where multiple scripts and web parts are competing for resources, being able to “time-travel” through your state changes allows you to see exactly when and why a piece of data changed. This transparency is invaluable for debugging race conditions that occur when multiple asynchronous SharePoint requests return out of order. Furthermore, RTK allows for the implementation of persistent state. By utilizing middleware, you can sync your Redux store to the browser’s localStorage or sessionStorage, ensuring that if a user accidentally refreshes the SharePoint page, their progress in a complex task is hydrated back into the application immediately. This level of sophistication transforms a standard SharePoint web part into a robust enterprise application.

Performance Benchmarking: Minimizing Re-renders in Large-Scale Apps

Maintaining a high-performance SPFx web part requires more than just functional state; it requires an understanding of the browser’s main thread and the cost of the React reconciliation process. In a SharePoint page, your web part is often competing with dozens of other Microsoft-native scripts and third-party extensions. If your state management strategy triggers global re-renders for minor data updates, you are effectively starving the browser of the resources needed to remain responsive. Performance benchmarking reveals that the React Context API, while convenient, is frequently the culprit behind significant “jank” in large-scale apps. Because a Context Provider notifies all consumers of a change, even a simple toggle of a UI theme can force a massive, expensive re-evaluation of a complex data grid.

To solve this, professional SPFx development necessitates the use of tactical optimizations such as memoization and selective rendering. By utilizing React.memo for functional components and useMemo or useCallback for expensive computations and event handlers, you ensure that components only re-render when their specific slice of data has changed. Furthermore, when using a centralized store like Redux or a custom Observable service, you should implement granular selectors. These selectors act as guards, preventing the UI from reacting to state changes that do not directly affect the visible output. Benchmarking these optimizations in a production tenant often shows a reduction in scripting time by 30% to 50%, which is the difference between a web part that feels native to SharePoint and one that feels like an external burden on the page.

 // Optimization: Using Selectors and Memoization to prevent over-rendering  import React, { useMemo } from 'react';  import { useSelector } from 'react-redux';   export const ExpensiveDataGrid: React.FC = () => {    // Use a selector to grab only the necessary slice of state    const items = useSelector((state: any) => state.list.items);    const status = useSelector((state: any) => state.list.status);     // Memoize expensive calculations to prevent re-computation on every render    const processedData = useMemo(() => {      return items.filter(item => item.IsActive).sort((a, b) => b.Id - a.Id);    }, [items]);     if (status === 'loading') return <div className="shimmer" />;     return (      <table>        {processedData.map(item => (          <tr key={item.Id}><td>{item.Title}</td></tr>        ))}      </table>    );  };   // Wrap in React.memo to prevent re-renders if parent state changes but props don't  export default React.memo(ExpensiveDataGrid); 

Conclusion: Establishing an Organizational Standard for State

Solving state complexity in the SharePoint Framework is not about finding a “one-size-fits-all” library, but about establishing an engineering standard that prioritizes predictability and performance. Whether your team settles on the explicit simplicity of props, the robustness of a Singleton Service, or the industrial scale of Redux Toolkit, the choice must be documented and enforced across the codebase. A standardized state architecture reduces the cognitive load on developers, accelerates the onboarding process for new team members, and ensures that the custom solutions you deliver to your organization are maintainable long after the initial deployment.

As the Microsoft 365 ecosystem continues to evolve, the web parts that survive are those built on sound architectural principles rather than short-term convenience. By decoupling your business logic from the UI and managing your data lifecycle with precision, you create applications that are not only faster and more reliable but also significantly easier to extend. In the high-stakes environment of enterprise SharePoint development, architectural discipline is the ultimate competitive advantage. It allows you to transform a collection of disparate components into a cohesive, high-performance system that meets the rigorous demands of the modern digital workplace.

Call to Action

If this post sparked your creativity, don’t just scroll past. Join the community of makers and tinkerers—people turning ideas into reality with 3D printing. Subscribe for more 3D printing guides and projects, drop a comment sharing what you’re printing, or reach out and tell me about your latest project. Let’s build together.

D. Bryan King

Sources

• Microsoft Learn: SPFx Performance Optimization
• PnPjs Official Documentation
• React Documentation: Scaling State Management
• Redux Toolkit: Official Best Practices
• Fluent UI: Performance Guidance for Large Lists
• Google Developers: Core Web Vitals and Main Thread Activity
• Microsoft: Choosing the Right Framework for SPFx
• CISA: Software Memory Safety and Architecture
• SharePoint PnP Community Web Part Samples
• TypeScript: Structural Type Systems in Large Apps
• React: Optimizing Re-renders with useMemo
• Microsoft: Enterprise Guidance for SPFx Development

Disclaimer:

The views and opinions expressed in this post are solely those of the author. The information provided is based on personal research, experience, and understanding of the subject matter at the time of writing. Readers should consult relevant experts or authorities for specific guidance related to their unique situations.

Related Posts

Rate this:

Microsoft Graph .NET SDK v5 is now generally available  - Maísa Rissi - https://devblogs.microsoft.com/microsoft365dev/microsoft-graph-net-sdk-v5-is-now-generally-available/ - Fluent API and models for retry handling, secure redirects, batching requests, large file management, and much more! #MicrosoftGraph #dotnet #Microsoft365Dev

Announcing #MicrosoftGraph Toolkit v3.0 Preview 1 - https://devblogs.microsoft.com/microsoft365dev/microsoft-graph-toolkit-v3-0-preview-1/ - Lots of cool new features such as selecting an item from a collection, light and dark mode, switch logged in accounts, and send chat messages in your app! Sébastien Levert #Microsoft365Dev

Hack Together: Microsoft Graph and .NET - Week 1 Recap https://devblogs.microsoft.com/microsoft365dev/hack-together-microsoft-graph-and-dotnet-week-1-recap/ - The hack event is off to a great start! Check here for all the details and replays of the keynote and deep dive session - @waldek #MicrosoftGraph #dotnet #Microsoft365Dev

TO DO: Check out the new capabilities available in the #MicrosoftGraph To Do APIs - Swapna Ninan - https://devblogs.microsoft.com/microsoft365dev/new-capabilities-available-in-microsoft-graph-to-do-apis/ #Microsoft365Dev

I'm speaking this week along with Jose Barreto at the #m365conf in Las Vegas. If you'll be there and are interested in learning more about what #MicrosoftGraph Data Connect can help you learn about your #SharePoint environment, please join us!

New #PowerShellPodcast! Christian Ritter talks #PSConfEU, community, blogging tips & growth. Explore #MicrosoftGraph, teaching at work & more!

🔊 Listen: https://powershellpodcast.podbean.com/e/blogging-secrets-with-christian-ritter/
📺 Watch: https://youtu.be/ocdYDOqO2aU

#powershell #automation

New #PowerShellPodcast! Christian Ritter talks #PSConfEU, community, blogging tips & growth. Explore #MicrosoftGraph, teaching at work & more!

🔊 Listen: https://powershellpodcast.podbean.com/e/blogging-secrets-with-christian-ritter/
📺 Watch: https://youtu.be/ocdYDOqO2aU

#powershell #automation

New #PowerShellPodcast! Christian Ritter talks #PSConfEU, community, blogging tips & growth. Explore #MicrosoftGraph, teaching at work & more!

🔊 Listen: https://powershellpodcast.podbean.com/e/blogging-secrets-with-christian-ritter/
📺 Watch: https://youtu.be/ocdYDOqO2aU

#powershell #automation

New #PowerShellPodcast! Christian Ritter talks #PSConfEU, community, blogging tips & growth. Explore #MicrosoftGraph, teaching at work & more!

🔊 Listen: https://powershellpodcast.podbean.com/e/blogging-secrets-with-christian-ritter/
📺 Watch: https://youtu.be/ocdYDOqO2aU

#powershell #automation

New #PowerShellPodcast! Christian Ritter talks #PSConfEU, community, blogging tips & growth. Explore #MicrosoftGraph, teaching at work & more!

🔊 Listen: https://powershellpodcast.podbean.com/e/blogging-secrets-with-christian-ritter/
📺 Watch: https://youtu.be/ocdYDOqO2aU

#powershell #automation

New #GA for my team! #go developers looking to integrate their application with #MicrosoftGraph now have an official SDK!!! From hackathon project to general availability in extremely proud of the work the team has put together. And if course all of that is powered by #kiota https://devblogs.microsoft.com/microsoft365dev/building-go-applications-with-the-microsoft-graph-go-sdk/

#dotnet is the first #microsoftGraph #sdk based off #kiota to hit general availability. Many more to come! #openapi

https://devblogs.microsoft.com/microsoft365dev/microsoft-graph-net-sdk-v5-is-now-generally-available/

Send-MgUserMail BodyParameter Explained http://dlvr.it/THG8J1 via PlanetPowerShell #PowerShell #SendMgUserMail #EmailAutomation #MicrosoftGraph