If you try to come up with your very own design it might be easier to use Custom Data Sections for Documents as they are more flexible.
You can add columns as comma separated list (in the Risk table you need to add them in XSLT Processing field).
The syntax follows this principle format
column 1,column 2,column 3
Each column can be defined by providing information what should be inside and optionally the column header. So each column is
"column header|column definition" or just "column definition"
The column definition can be a specific keyword:
item: prints item id and title
itemv: prints item id (revision) and title
itemId: prints just the item id, no title
itemIdv: prints the item id with revision, no title
uptraces, downtraces: prints up or down traces
labels: prints set labels
labels$id1$id2: labels can have a list of label ids specified. If specified only those labels are shown
'field name': prints any fields the user wants to show
a property of the item. Properties are unformatted values
@ref: (item id, no hyper link)
@birth_customer_format: (creation date and time of revision in customer time zone)
@title: (item title)
@author: (user id of author of revision)
@birth: (creation date and time of revision as UTC time)
@depth: (depth in tree structure)
@version: (revision of the item)
The same information as above about some up or downstream items:
up/WHAT/PATH down/WHAT/PATH follows the up/downlinks of the item.
up, down: direction of traces to follow
WHAT is a definition of a property, value or field of an item (as described above)
PATH: is the path of traces to follow, e.g. if a REQ has downlinks to SPEC to TC you can report about the TC with down/WHAT/SPEC/TC.