Sure you aren’t the Bridgekeeper?
The FileSystem method that you’re moving from has a rather open security scheme. Anyone who can read/write to the Part folder can also read/write to any other table. If you have sensitive information in your attachments, it’s very difficult to protect. Carrying that scheme into SharePoint will remove some of the security benefits that SharePoint provides. The classic UI model usually implements a weak security model: one user/service account has access to every file.
If people move the files in SharePoint, it might break the link in Kinetic.
SharePoint limits you to one Content Type, you can still use multiple Kinetic Document Types. Unlike ECM, you cannot have a different security scheme by Document Type.
Document revisions have to be done in SharePoint.
As mentioned earlier, one of the biggest mistakes SharePoint users make is treating a Document Library like a file share. 
Has anyone yet tried multi-library?
https://www.epiusers.help/t/function-library-working-with-sharepoint/114327/27?u=jbooker
Or this
https://www.epiusers.help/t/function-library-working-with-sharepoint/114327/37?u=jbooker
Yes, I just did. It works.
Do tell…
Sweet! So one ERP Doc Type per library?
I thought only one SPO doc type was allowed or maybe Base URL wasn’t a thing so its made available by the 2024.2 mod.
This really is a big deal that went largely unnoticed as I’m pretty sure it wasn’t a thing in early 2024.
Thanks for sharing!
Oh now I see your paths. Multi-library by virtue of multi-site. Silly they still create and require a library named companyID
But you can do subsites.
Perhaps even sub-subsites.. didn’t test lol.
Yeah it’s huge. Makes Sharepoint infinitely more usable. SPO Security, Teams Sites are now a thing for example. Just don’t like 6-digit doc libs and don’t like folders but yeah full-path Base URL is a big deal.
That’s what I was going to say @Mark_Wonsil, cause @jbooker was mentioning SPO >= ECM, and I’d have to agree that it has the capabilities, but when using the sharepoint connector method from Epicor, I feel like it severely degrades SPO’s value proposition and intended use.
Now if you went on and did a full custom API/function/whatever to utilize sharepoint in all its glory, like you were saying Mark… I see the benefit of choosing SPO over ECM.
Either way, splitting hairs.
Also @jbooker when I last looked at the sharepoint connector that was a year ago and there were document limitations as to how many documents you could store as well as security limitations like @Mark_Wonsil had pointed out. I’m out of my element to truly debate this with great depth.
@klincecum just proved much of the degraded value is old news. The ERP Doc Type Base URL was made full-path in 2024.2 which means you can have many ERP Doc Types, each pointing to separate SPO sites. Which means SPO security is now a thing.
That leaves the silly CustomerID Doc Library name and Entity folder structure as caveats but it’s hugely better. < these are true for ECM as well (in the default setup at least)
Good to know, I was just re-reading Kevin’s comments.
I’m not sure I would go that far. The bigger question is how invested are you in the M365 ecosystem. ECM is pretty good IMHO. Especially if you use APR.
Simply said: Everything else is in SPO why buy a new ECM?
While I’m annoyed Epicor spent bags on the aquisition instead of investing in the core product during huge client/cloud initiatives, each org should decide for themselves. If you’re not on M365 it could make sense.
definately the question but I’d point that back on ECM.
Even if you’re not not on M365, you can subscribe and have SPO up in 5 minutes. If you are, it’s free. Either way: No contract, no deployment delay, no onboarding EPS engagement, no user setup. Plus: MSOffice webapps & co-editing, OneDrive sync, PowerAutomate, Copilot, retention polices, MSTeams sites & M365Groups sites are SPO too! etc, etc.
We’re paying for both ECM & APR (unfortunately, for now) yet SPO still makes more sense than engaging on ECM for us.
For me, here’s the difference: the Kinetic integration to ECM is way better than than the one for SPO. It’s not that SPO isn’t a good product (we cancelled ECM and use SPO), but the way Kinetic integrates to SPO is less than optimal.
Single Document Library
In no world does an SPO admin create one document library for all files. The document library mimics the layout for the server-side
- There are limits to the number of files after which, the performance get worse.
- The document library mimics the File Server document type (folders for company/table/file). ECM looks like a single drive and relies on meta data for search but also assigns a unique ID.
- I wouldn’t use OneDrive sync every attachment in Kinetic to my desktop
- Your security scheme is restricted. You can’t give access by customer like you could with an MS Team with a separate Document Library. ECM let’s you set up a security group and then assign it at a granular level.
If you want to use directives to include related files or to save printed documents, that’s OOTB with ECM.
ECMs Work Flow engine is built around document management. You can certainly use Azure services to do the same, but you have to start from scratch.
ECM is probably less expensive to store files ($/Mb) than SPO.
SPO search is not great. I have been looking right at a file that has been in that library for weeks and SP search doesn’t find it - and indexing was turned on for the meta data. 
Separately, I think document attachment is backwards. If SPO or ECM scans in a document, it should be able to add the link to Kinetic. Why add the document management work flow in Kinetic?
Agreed except the one library and thus security is no longer a limiting factor. see above.
You’re right, I forgot about 2024.2 and the full path for different document types.
Walk me through this. What does that look like if my MS Teams architecture has one Team per customer? To respect security, would I need a document type for each customer to pick the right Document Library? If so, and I pick the wrong document type, does the document go into another customer’s team document library? If documents are shared between departments (Invoices for accounting but Customer Purchase Orders for Sales, do I need a document type for each customer/document type to get to different document libraries? Do I know who uploaded the document or does it always appear as a service account?
Many of us know about “Design for Manufacturing”. We can engineer an amazing product, but if it is impossible to make reliably or cost effectively, is it still a good product? In IT, we need to make solutions that “Design for Information”. So many of our solutions are about storing information and not being able to use it to retrieve values to make decisions, drive tasks, and inform people downstream of work coming their way.