I currently work in healthcare and have run into situations with users where some data files are exported from software solutions in .rtf or .txt format only. To improve the user experience once these files are dropped into SharePoint, we can convert any .rtf file automatically to .doc.
When RTF files are opened in the browser, the option to “Edit in browser” is grayed out since the file type isn’t compatible with that functionality.
Okay, but why .doc and not .docx?
Unfortunately, we can’t convert from RTF to DOCX without the use of Azure functions (thanks, Pieter Veenstra for that info). But if we can at least convert it to DOC for users, they’ll get the “Edit in Browser” option which will then prompt them to convert the file to DOCX in two clicks (Convert –> Edit). Then we finally have a .docx file.
How to auto-convert .rtf to .doc using Flow
Prepping the document library
First, since we don’t want anything to happen to files that aren’t .rtf, we’ll need to create a column in our list to display “extension.” Then we’ll use SharePoint Designer to populate the extension and Title fields whenever an item is added or changed. Flow can’t use file name fields, so we’ll set title to match name.
- Library settings –> Add column –> Single line of text (name it extension and save)
- Create a SharePoint Designer workflow (2010 or 2013 – doesn’t matter for this purpose) that triggers on creation or change
- Set extension to file type, and title to name
Publish the workflow. Now when a .rtf file is dropped into the library, it will set “rtf” in the extension column and set the blank Title field to the same as “Name” so that we can use it in Flow.
Create the flow (.rtf to .doc)
Trigger and condition
- Create a new flow with the trigger “When a file is created or modified (properties only)” and select (or enter) your site and library name.
- Create a condition step that checks if “extension” is equal to rtf
“If yes” box
Now we’ll create four steps in our “if yes” box. Configure each as pictured below, careful with file paths not to include the whole URL – just the relative path beginning something like /Shared Documents/…
- Get file content using path (gets contents of the .rtf file)
- Create file (creates new .doc file using the .rtf contents)
- Get file metadata using path (gets original .rtf file)
- Delete file (deletes original .rtf file to avoid confusion)
Expand the flow (optional – delete .doc if .docx created)
If no box (optional)
Users can now easily convert .doc to .docx in two clicks. But it leaves the original file (.doc) behind which can be confusing. So we can create steps in our Flow to delete the .doc file IF a .docx by the same name is created.
In the no box, we’re going to create another condition step to check if the extension equals .docx.
If yes, use a “Get file metadata using path” step to get any file by the same name from that library (use the “Title” dynamic content from the trigger step and add a .doc). Then in your “delete file” step, simply use the ID from the get metadata step.
Now when a user converts a .doc to a .docx file in the browser, your Flow will delete the .doc that’s left behind. Note that there will be a delay.
- SharePoint Designer has to wait until you’re out of the editor to reassign the “extension” field to .docx
- Flow has to wait for SharePoint Designer to make that change so that it triggers appropriately
While this is certainly not an ideal workaround, it may be the best you’re able to do with the resources on hand. Not everyone has Azure, or developers, premium add-ins/vendors or the budgets for such things. Best of luck!
Here’s a view of the full flow, highlighting which steps I’m pulling dynamic content from. Click to enlarge.