3.1.1. First row
3.2.3. Field row
3.2.4. Rows after the field row
3.3. Links to lists
3.4. Set Subject property
It is possible to merge data from a list on an entity site into a Microsoft Word table. This is done by setting up one or more tables in the Word templates where this feature is wanted (one table for each list)
These tables must be supplied with “tags” which lets the system know which data to merge into the tables.
It is important that the different tags are typed in exactly as presented in the following. It is therefore also important to give special notice to capitalization, to avoid unnecessary spaces and make sure all tags are encircled by square brackets.
This feature requires a WorkPoint Server or a WorkPoint 365 solution. If you do not have this you can contact WorkPoint Sales at firstname.lastname@example.org for more information.
The following sections surrounds the configuration of this feature.
3.1. Merging of list data into Word tables
The following table describes the structure of a table for use with this feature:
3.1.1. First row
In the first row and cell of the table the name and the view of the list to be used as filter and sorting is stated. Note that these data MUST be stated in the first cell of the table. This row is removed by the system during execution of the data merging.
A view is not mandatory. If no view is used, the system will default to use the "AllItems" view.
It is important to note that if the states list and view cannot be found during execution of the data merge, the row will not be removed, and a red error message is shown.
This tag states the name of the list from which data should be fetched. In this example the list is called “Documents”. This field is mandatory.
This tag states the URL name of the view that is to be used as filter and sorting. In this example the view is the “TestView”.
3.1.2. Rows from row 2 on to the field row
Here the user can input custom static content. Typically, there will be a row with headers for the fields from the list which is merged into the table.
The header line is not mandatory, but will make a lot of sense to the reader of the completed document.
3.1.3. Field row
In this row, the field-tags which indicates where fields from the list should be placed, is inserted. In each cell in a row, one or multiple tags can be inserted. Static content is also allowed.
There may only be one field row, and field tags may only be placed in this row.
During execution of the data merge, the field tags are replaced with the actual data from the list. Any formatting of the field tags is preserved.
It is important to note that the field names which are to be stated in the field tags are the internal SharePoint names. Also be aware of differences in upper- and lower-case letters. If a field cannot be found in the list, the field tag is replaced with an error message in red color text.
For document lists, the fields “LinkfileName” and “LinkfilenameMenu” will be replaced with links to the documents.
For regular lists, the felds “LinkTitle” and “LinkTitleNoMenu” will be replaced with links to the property view of the elements.
3.1.4. Rows after the field row
In the rows after the field row the user can input custom static content.
3.2. Merging of Relations data into Word tables
It is also possible to merge relations data between entities into a word table. The way this is done is much like when merging list data into a word table as described in the previous sections. The structure of the table is as follows:
This tag states the names of the types of relations to be fetched. Multiple names are separated by commas. If one wishes to fetch all relations regardless of their types, the value can be set to *. This field is mandatory. The tag MUST be stated in the first cell.
This tag states if only active relations should be fetched. A value of 0 means that all relations will be fetched while a value of 1 excludes inactive relations. This tag MUST be stated in the first cell.
The eligible fields that can be used in the field row are:
3.4. Set Subject property
If one wishes for the subject property in Word to be filled with values from the entity (or the entity’s parent) that is being merged from, the following syntax can be inserted into the Word template’s subject property:
wpListName:Companies states the entity list, while wpFieldName:wpCity is the internal name for a field in the list. Note that the two pieces of information are separated by a comma without spaces around it.
The city [wpListName:Companies,wpFieldName:City] is a big city. Address is [wpListName:Companies,wpFieldName:wpPostalCode] [wpListName:Companies,wpFieldName:wpAddress1]