We’re planning on migrating our Epicor network file attachments to Sharepoint. We can use the Sharepoint Migration tool to push the files over, and then (I hope), @mpot can change the document link with DMT to the new Sharepoint location and Document Type. (If there’s a better way, we’re all ears!)
How do we also attach the metadata to the updated files?
I can’t figure out where it’s saved in Epicor, and Sharepoint has it blank. Somehow Epicor is displaying it on my new test attachment, so it’s there somewhere.
Apologies, but my experience is from File Storage, Sharepoint, DocLink TO ECM/Docstar, not the other way. I can say with pretty much certainty that the metadata definition in Epicor is a modification to the real time query/display of the document - which is also used for the ECM attachment process. I could never find a relationship with XFileRef and XFileAttach tables that included metadata fields.
I’m not sure how to get the data out to Sharepoint - maybe it worked back in 9/10 days - wasn’t there some sort of special Sharepoint connector you had to have back then?
Link Sharepoint Attachment Metadata To Connected Tables
Epicor’s Attachment Metadata Maintenance module can only attach metadata from the parent record’s table only. This prevents Sharepoint searching site-wide for documents that are related to a customer via CustID or Name.
Ex: If we attach a customer’s signed order contract to the OrderHed table, Epicor will not push the CustID or Customer Name to the sharepoint metadata. It will only push the OrderNum.
This is a step backwards from using our old network file repositories, with folders for each CustID / Name. Sharepoint only has folders for tables, and would have Customer attachments separate from OrderHed attachments.
In SharePoint, go to your Document Library and create a new view, then Edit it.
You should see all of the columns (metadata) that are available, including the Kinetic ones. You can then display them in the grid. To display the metadata in the properties pane, I think they have to be in the content type for that library. But why not just put it in the view?
The thing about metadata and content types with Kinetic, is that there is only one Document Library and one Content Type, so every file will have all of the metadata columns no matter what Kinetic Document Type it is. This is another reason I lean toward just using the Link Attachment type for SharePoint. I can store documents in any Document Library, have one content type for that library, and make security different by library.
Our next test to add metadata to existing attachments will be to delete them with DMT, and add them back with the Sharepoint attachment type.
We do have an issue, though - The CustName metadata isn’t syncing to Sharepoint. It’s there in the F12 Devtools SPUpload BO payload, but not in Sharepoint. The column exists in Sharepoint as a Single Line of Text, and it’s in Epicor’s Metadata Maintenance as well.
EpiCare wasn’t able to help on our case (CS0005452996). They suggested we contact Professional Services
Well, it’s the way I did it in the past. I also recall that the Kinetic DocType went into the Category field. It did not create a new Content Type in SharePoint. Maybe this has changed, but that’s what I remember.
I deleted everything from Kinetic as well as SharePoint, then tested.
When I create an Attachment Metadata item from the Kinetic UI, it takes a few seconds to run, and automatically creates the column in Sharepoint. The metadata then gets added when I add a new attachment (tested on Customer Entry using CustID and Customer Name).
If I DMT an Attachment Metadata item (runs instantly), then it shows up in the Kinetic UI, but does NOT create the column in Sharepoint, and does NOT get added when I add a new attachment. Submitted on Case CS0005452996 for 2025.2.13.
Thank you for the additional information. Researching the reported issue the information I found is that DMT does not invoke the SharePoint metadata provisioning logic, so Epicor does not dynamically create SharePoint columns at upload time. This is by design, not a defect.
When you create Attachment Metadata via DMT:
DMT performs a direct DB insert only No SharePoint validation No column creation No schema refresh
Epicor later sends the value, but SharePoint has nowhere valid to store it
The suggestion is always create Attachment Metadata from the Kinetic UI, not DMT.
I hope you find this information helpful.
And here I thought DMT would invoke the same business objects and logic as doing it manually in the UI, but apparently not! I don’t understand why they’d cripple DMT, but maybe it’s just not capable of waiting for the Sharepoint response.
What stinks is the Kinetic UI doesn’t let us do a paste-insert either!
At least the Classic UI will still let me do it, but no point mentioning this to EpiCare as a parity issue. They’ll just tell me to submit an Ideas for them.
I wonder what happens when you have multiple metadata columns with the same name, but on different parent tables.
E.g. PartNum metadata would exist on Part, OrderDtl, QuoteDtl, JobHead, JobMtl, PODetail, PartMtl, and PartRev tables.
If SP has a guid for each, will I get 8 columns that each need to be shown on the views? Or will Epicor/Sharepoint be smart enough to push the partnum to each, so I can search once and find all the attachments.
If memory serves, there was only one Document Library. It mimics what the File System structure looks like: a folder for each company and within that, folders for each table. Since it’s just one Document Library, all records will have every meta data column whether it uses it or not. One would use views to restrict which columns you would see.
Kevin - Awesome!!! I just learned that our plan to DMT-delete all the attachments and then DMT-add them back to push them into sharepoint with metadata does not work. DMT does not push the metadata into SP, it just adds the file. We would have to manually add 10,000 files via the UI, instead of using DMT.
@Olga - Do you have a better way that folks should migrate the files? If you need justification, we’re doing this to get attachments onto Sharepoint to let us run Kinetic on the browser without Edge.Thanks!
Other issues we’re going to have is:
How to handle duplicate files names in the same folder (e.g. OrderHed/Pic1.jpg) - I think we’re going to append the Key1 number to it with the prefix determined by the RelatedToFile table, like Pic1_SO12345.jpg)
We may be limited to only one document type ‘Sharepoint’, since metadata is unique to the document type. We use document type to tag documents as ‘Instructions’ for instance, and then have a BPM to print them any time a part with instructions is on a Packslip or a job has drawings to include with the traveler. Datatags? Metadata columns for those? Make users check a box when adding documents of those types?
I thought we were getting close, but it seems every time we progress, there’s more things that need attention!a
Attachments are currently on local file shares saved with metadata-like folder names (e.g. Customer\1234 for CustID 12345 attachments, Part\110401, Instructions, Drawings, RMA etc.).
Want to move existing (and future) attachments to Sharepoint to let us go Kinetic-browser only without using the Edge Agent and not lose functionality.
Drank the metadata cool aid advantages of Sharepoint, and see the value in using it… We’d like to have connected table fields available for metadata, not just the parent table. E.g. OrderHed attachments would have OrderNum, CustID, and CustName metadata. OrderDtl would have that + PartNum.
Continue to print part instructions with pack slips and drawings with job travelers. They’re identified via document types currently, but Sharepoint may limit us to one document type, since metadata is linked to the document type. Or we create 10 metadata fields for every doc type and have 10 x # of DocType metadata’s in the table.
Handle duplicate file names since Sharepoint puts them all into one table (e.g. append SONum to OrderHed files). Primary key w/ table?
Revise attachments (customer contracts, part drawings, etc). Do users upload v2 as a new attachment? Or go into Sharepoint directly and revise it with open/save? Haven’t gotten to learning/testing this yet.
I think that’s it. Hope you’re thirsty!
(Man, sticking with the classic UI would be so much less work, lol! So far Kinetic isn’t making us any more productive than the classic UI, and we’ve got hundreds of hours into upgrading. Negative ROI on that, Epicor!)
But why not just put it in the view? 
No SharePoint validation
