We have ontology objects with attachment-typed properties holding .docx documents (typically rendered from templates via docxtpl). Users need to edit the .docx and persist the changes back to the same property — with the PDF mediaset rendering the updated version for in-platform viewing.
We’ve considered the obvious paths and none feels right:
- Notepad — not Word-fidelity, and the source documents originate outside Foundry.
- Workshop check-out / check-in via attachment download → local edit → upload action — works, but the round trip is friction for high-frequency editing.
- SharePoint co-edit with a URL property on the object — moves the source of truth off-platform.
- Custom Workshop widget hosting a JS .docx SaaS editor (SuperDoc, TipTap + mammoth) — external SaaS services aren’t an option, and pure-JS .docx round-trips are lossy on complex documents.
- Office Add-in calling Foundry from inside Word — viable but a real build and deployment story.
Has anyone landed a cleaner pattern? Specifically: open the .docx from a Workshop or Object Explorer surface, edit, save back to the same attachment property, no manual file shuffling.