Thanks, Andrew, for your explanation. As you were discussing the various scenarios in which SharePoint Embedded can be utilised, it reminded me of all the custom SharePoint solutions that I've built over the years. I realised that over 90% of them could've been designed much better and would've been easier for users to adopt if I had the option to utilise SharePoint Embedded back then.
@andrew_connell, I was wondering if the documents stored in SharePoint Embedded are available to Copilot. Also, will they be visible in O365/SPO classic services, e.g.: search results, recent documents, my documents, or similar functionalities?
Yup... it's _just SharePoint_ so yes they can be exposed in all the native SharePoint scenarios (search, recent docs, Office backstage, etc. But app developers can elect to NOT expose the content as well. It's not automatic. I'm not sure about Copilot at this time though.
Thank a lot Andrew! But do In undertand correctly that SP Embbedded could be used to collect documents from customers and then consumed internally? And in order to do that, for internal users we also would need to create a separate app (using SPFX for example) to consume these files uploaded by customers? In such scenario, how customers could be authenticated to use SP embedded app (react SPA)?
Let me try to answer these in the order you asked... 1. Sort of... you don't "use" SharePoint Embedded to collect documents. SharePoint Embedded is a new service offering from Microsoft. It's just SharePoint without the web UX - you create the UX. So, you can create an app that stores documents in SharePoint (via SharePoint Embedded) and yes, other users in the same M365 tenant can consume those files internally. 2. No, internal users don't need to use the internal app (not necessarily). The files are already in the same tenant, so they can be found via search, they just aren't surfaced in the SharePoint UX like document libraries (because they're in a separate storage partition. 3. The custom app you build uses Microsoft Entra for auth. It might help if you take a look at my latest video I published this week that walks you through creating one of these apps: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-GbHX4ZEe5UY.html
Hi listen to your example just to understand which are the different to using Powerapps ? Sure the path is perhaps shorter to the target. Do i get it ?
Did you mean to leave this comment on a different video, like this one? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-SnsXlFALFEY.html That video talks about PowerApps, this one doesn't mention PowerApps at all... it's about SharePoint Embedded.
Great video! When the UX is created, what stack do we use? React, Vue, Vanilla JavaScript & CSS, etc.? Is there going to be a toolchain provided like SPFx?
I haven't heard any plans about a toolchain, but frankly, I prefer if they don't do something like what they did with SPFx's heavily opinionated toolchain. I much prefer it to just be left as is since all we're really doing its calling an endpoint (Microsoft Graph). And do that point, you can use any stack you want! That's the best part - it's entirely headless (ie: no UX) and you're just calling REST endpoints. You might like my step-by-step tutorial showing where I use Node, React, Fluent UI v9 & the Microsoft Graph Toolkit to build an app: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-GbHX4ZEe5UY.html
For internal users could I create a PnP Search webparts page to surface all the documents in a container? enabling users to browse to read? They would need permission to the containers files I assume? Could they edit files if they had permission and not be metered opening via this method?
If the PnP search web parts use Microsoft Graph to execute search, then yes. You access all data within SPE Containers via Microsoft Graph. Users must have READ permission to see the content not only in the search results (due to security trimming) but also to view the files. I don't understand your last question... with the necessary permissions they can edit files as long as they have at least the WRITE permission. When you say "metered", you mean charged? If so, then it depends... For metered billing, you will only get billed for things YOU do with the APIs not for things that MSFT does. For instance, if you have a text file that you open into an editor and you save the changes via the editor, then yes, you'll get billed for that. But if you open an Excel workbook in the Excel desktop / web app and edit it, then no because it's Excel that's opening & saving the file, not your code.
