Your SharePoint Sharing Might Break in 2026
A major change is coming and it’s not getting enough attention. Microsoft is moving away from simple OTP sharing and shifting to full Entra B2B. It sounds like a security upgrade, but it completely changes how external access works. This isn’t a small tweak: Existing sharing links may stop working as expected External users will go through new authentication flows Access will rely heavily on identity and guest policies Yes, you get better control and visibility but also more friction if your setup isn’t ready. If your organization relies on quick sharing links, this could become a real issue fast. Curious how others are handling this: Are you already using Entra B2B? Seeing any access or adoption issues? How are you balancing security vs usability?
pnp-modern-search does not work in the local SharePoint workbench
Version used 4.9.0 (SPFx 1.15.0) Describe the bug The solution works correctly when deployed using the .sppkg package in SharePoint Online, but it does not work in the local SharePoint workbench. There are two related issues: When running gulp serve, the build/runtime reports an error related to BANNEDUSERNAME/sp-webpart-workbench/lib/api/, suggesting a failure in loading or resolving the local workbench API module. When adding the web part to the local workbench page, the web part fails to render with the following error: Error: Cannot find module './15.js' The second error appears to be related to a missing or incorrectly resolved chunk/module during bundle loading. The issue only occurs in the local workbench. The deployed .sppkg solution in SharePoint Online works correctly. Node.js version: 16.8.0 (compatible with SPFx 1.15.0). Dependencies installed via npm install without errors. To Reproduce Clone the repository Run npm install Run gulp serve Open the local SharePoint workbench Add the web part to the page Observe: Error during gulp serve related to BANNEDUSERNAME/sp-webpart-workbench/lib/api/ Web part fails to load with Cannot find module './15.js' Expected behavior The web part should load and render correctly in the local workbench without module resolution errors. Desktop : Browser: Chrome Node.js: 16.8.0 SPFx: 1.15.0
If list multi-select choice column contains certain value, auto-populate flag column in related list
I have a SharePoint list called List1 with columns ID (single-line text) and Type (multi-select choice): ID Type ---- ------ ID1 Apple ID2 Apple, Pear ID3 Pear, Banana, Apple ID4 Pear ID5 And a second list called List2 with columns ID (a Lookup column) and Has_Pear (yes/no). I want to automatically populate Has_Pear with "Yes" if the related row in List1 has "Pear" in the Type column. Like this: ID Has_Pear ---- ------ ID1 No ID2 Yes ID3 Yes ID4 Yes ID5 No How can I automatically populate the Has_Pear column?JSON formatting to change background color of ENTIRE column of list?
Hi, I'm trying to use JSON formatting to change the color of an entire column of a SharePoint list, and I can't figure it out. Setting the background-color style property appears to only affect the background color of the text. You can still see the default column color in between rows. I want the whole column to be one color. Is there a way to do that?SPFx webpart not displaying after insert webpart (error below)
I deployed my SPFx webpart successfully to my site, however after inserting it on a page I get the following error: Uncaught (in promise) Error: Script error for "ea2f4f01-db05-44e9-8900-22d9ef8d632f_0.0.1/SvgGhostWebPartStrings" https://requirejs.org/docs/errors.html#scripterror at makeError (eval at V (sp-pages-assembly_en-us_12745640b376ada2f337a0ad84b60ffc.js:233:13154), <anonymous>:5:1843) at HTMLScriptElement.onScriptError (eval at V (sp-pages-assembly_en-us_12745640b376ada2f337a0ad84b60ffc.js:233:13154), <anonymous>:5:17037) Below is an image of the webpart uploading successfully
Error accessing SharePoint Online & OneDrive
Hello, I'am facing an issue in my tenant with OneDrive and SharePoint. Since the renewal of my hosting (OVH) all users (admin included) on the tenant can no logner access SharePoint or OneDrive (all other services are accessible). Even the sharepoint admin center is inaccessible. It seems like the adress XXXX-my.sharepoint.com is no longer there (I also have this message "DNS_PROBE_FINISHED_NXDOMAIN"). I looked all Microsoft Support discussions and nothing seem to tack to work. Note that DNS entrees are good on my domain host (Exchange is working). I tried to contact Microsoft Support, its taking a long time. And I need the issue fixed by monday.. Best regards,SharePoint Managed Property Online Search Issue – Custom User Profile Property
I’m facing an issue with SharePoint Online search and could use some help. I created a custom User Profile Property (Text) in SharePoint and mapped it to a Managed Property for search. However, when I query the managed property, the value is always returned as null. What I’ve tried so far: - Reindexed the User Profiles using a PowerShell script. - Updated the user profile property values multiple times. - Waited for search/indexing to complete. - Verified that existing/default user profile properties are appearing in search results correctly. Interestingly, existing user profile properties work as expected in search. The issue only occurs with the newly created and mapped property. Has anyone faced a similar issue with a newly mapped User Profile Property → Managed Property? Is there any additional step required to make a newly created user profile property searchable? Any suggestions on what else I can check would be appreciated.
Hub Site association approval request fails with 403 Forbidden (previously working, regression)
Sites configured to require approval before joining our Hub Site are failing the association request with an HTTP 403 Forbidden error[browser DevTools Network tab}. This same workflow was functioning correctly as of [early August 2026]. Hub sites that do not require join approval continue to associate successfully — the failure is isolated specifically to the approval-required path. Steps to Reproduce As a site owner, go to Site Settings → Site Information (or Site Contents → hub association) on a site that is not yet associated with the hub. Attempt to associate it with [Hub Site URL], which has RequiresJoinApproval set to $true. Observe that the request fails immediately (or fails when the approver attempts to approve it — specify which point in the workflow fails). Repeat the same steps against a hub site that does not require approval — association succeeds without error. Expected Behavior The association request should be submitted and routed to the configured approver(s) for review, consistent with behavior observed as recently. Actual Behavior Request fails with HTTP 403 Forbidden. [browser DevTools Network tab - attached the HAR file for reference] Error Details HTTP Status: 403 Forbidden [browser DevTools Network tab - JoinHubSite(@v1)?@v1] Troubleshooting Already Performed Confirmed association without approval works (isolates the issue to the approval workflow specifically)
I don't want 100 different SharePoint sites. How to create private teams w/o a new site?
Guys. WTF. I've inherited a problem where a company of 50 people has 100 sharepoint sites - because users created different Teams for different projects, and Microsoft makes it incredibly opaque what this actually means. Now we have 100 SharePoint sites, many of which are unused, but all of which appear in the list of sites in 365AC. The structure we WANT is 1 Sharepoint site for our 1 org, but multiple locations within that site, and multiple groups for multiple projects. I THOUGHT what could work was converting the excess Teams into Private Channels. But I have now learned that private channels ALSO create SharePoint sites, because _______. Most confusingly, all of these sharepoint 'sites' DO exist within our main SharePoint website - they're just pages (but not 'pages') pretending to be a fresh sharepoint website. This confuses the **** out of people, the way they've redefined what a 'site' is, what a 'team' is, etc. This is genuinely hot garbage, and it's suddenly clear to me why people always push back on using SharePoint over OneDrive. Recommendations for... not having this disaster? Making a structure that is intuitive and doesn't redefine what a site and page are, and allows you to have private locations for management or projects, but DOESN'T create a 'site' within the main 'site', with it's OWN 'documents', and it's own 'Notebook' (which isn't a document) and it's own 'Conversations' (which are NOT conversations), and it's own 'pages'? I don't work with dumb people - these are very technical people. But even our main SharePoint guy is mystified by these interactions. Does it make more sense in another language? If anyone at Microsoft is reading - the english term 'site', comes from the word 'website', which generally refers to a distinct web service with a distinct domain name. These contained different webPAGES.. When websites started existing off a shared domain name, like company1.sharepoint.com and company2.sharepoint.com - this confused people, but they put up with it, because it was relatively easy to explain the tech behind this - having websites under a single site, that wasn't too hard to understand. But what SharePoint seems to do, is extend this practice into absolute hysteria, where a particular webPAGE of a webSITE is ALSO a site, but also is a TEAM, or COULD be a CHANNEL. OR it could be a PAGE - WHO knows? If it's a TEAM, that TEAM could have CONVERSATIONS, which aren't actually Team Conversations - they're EMAILS. But this is fine, because all CONVERSATIONS of a TEAM done in TEAMS are actually stored as EMAILS so really those, CONVERSATIONS should be CONVERSATIONS... So why aren't these conversations in Teams between a Team that are stored as Emails not showing in the Conversations which show emails within that Team? aefggaddadsfasd
Ongoing SharePoint Search Issue Across Multiple Tenants: Missing Managed Metadata Crawled Properties
We've been seeing Microsoft Search issues across multiple tenants where Managed Metadata fields are not appearing as crawled properties, making it impossible to map them to managed properties. A member of the PnP Modern Search community pointed us to Service Health incident SP1393483 ("Admins may have been unable to see the configuration search schema mappings in SharePoint Online"), which Microsoft reported as resolved at the end of July: https://admin.cloud.microsoft/?source=applauncher#/servicehealth/history/:/alerts/SP1393483 However, we're still seeing these issues across multiple environments. Sharing this as a heads up in case you're troubleshooting similar SharePoint Search or metadata mapping challenges. It might not just be your tenant!
