Forum Discussion
Solved
Concepts for sharepoint, flow, and word documents - any help at all would be appreciated
Greetings: I am rather new to Sharepoint and Flow. I am having a difficult time with some of the concepts and getting it to all work right. I am trying to create a flow or in any way assist ...
- What is the reasoning behind using Word as your form tool?
My assumption is that you want to record specific information in answer fields for certain questions. Why not simply use a SharePoint list for that. The collumns headers your questions, the column fields can contain your answers. And you can modify the form using PowerApps forms if the out of the box forms do not meet your needs. PowerApps and Flow interact great with each other. Using the content inside of a Word-file in Flow is much harder than it is to use the content of a SharePoint-list column.Regarding content types: the easiest way to understand this is that it is a set of columns grouped together to store specific metadata for certain documents or to function as something like an entity in for example a SQL database.You can add multiple content types to the same library. It all depends on you scenario if that is the right way to go (sorry - consultant answer). If all your content types are part of the same process, the permissions for the documents made with these content types are the same and you do not expect to have hundreds of thousand documents made putting them in the same library is the way to go. Otherwise splitting it up in multiple libraries might be wise.The form templates library is part of SharePoint for a long time now. A little bit about what it is used for you can find in this article: https://support.office.com/en-us/article/Set-a-custom-template-for-a-SharePoint-library-8E0177EB-46BD-4346-9998-330C32733C25.
What is the reasoning behind using Word as your form tool?
My assumption is that you want to record specific information in answer fields for certain questions. Why not simply use a SharePoint list for that. The collumns headers your questions, the column fields can contain your answers. And you can modify the form using PowerApps forms if the out of the box forms do not meet your needs. PowerApps and Flow interact great with each other. Using the content inside of a Word-file in Flow is much harder than it is to use the content of a SharePoint-list column.
My assumption is that you want to record specific information in answer fields for certain questions. Why not simply use a SharePoint list for that. The collumns headers your questions, the column fields can contain your answers. And you can modify the form using PowerApps forms if the out of the box forms do not meet your needs. PowerApps and Flow interact great with each other. Using the content inside of a Word-file in Flow is much harder than it is to use the content of a SharePoint-list column.
Regarding content types: the easiest way to understand this is that it is a set of columns grouped together to store specific metadata for certain documents or to function as something like an entity in for example a SQL database.
You can add multiple content types to the same library. It all depends on you scenario if that is the right way to go (sorry - consultant answer). If all your content types are part of the same process, the permissions for the documents made with these content types are the same and you do not expect to have hundreds of thousand documents made putting them in the same library is the way to go. Otherwise splitting it up in multiple libraries might be wise.
The form templates library is part of SharePoint for a long time now. A little bit about what it is used for you can find in this article: https://support.office.com/en-us/article/Set-a-custom-template-for-a-SharePoint-library-8E0177EB-46BD-4346-9998-330C32733C25.
Well thank you very much for the response.
This goes in Word because it then gets sent out into the world as product. Depending on the circumstance any form generated documents will need none to extensive (dozens of hours) editing. A sharepoint list would be good for internal purposes of tracking some of the key bits, but the send-into-the-world version needs to be a document.
Overall what I ended up doing was create site level columns and (I think) content types. Then document libraries that drag in the site level columns. The template must be in .dotx for the custom columns to be part of quickparts. At that point it all works pretty gravy.
Thank you for the link re: forms.