As of writing, keyword fields seem to only be half-heartedly supported by DocuWare.

One of the biggest issues with keyword fields is that we have a "Contains" operator that can be used in autoindexing and document relations, yet we don't have a "Contained by" operator. This means that while we can include a related document that has a keyword which contains a text field in our starting document, it is impossible to make the inverse document relation, where a starting document matches its keyword field against other documents' text fields. Document relations should let users navigate in both directions, not just one-way.

One would imagine a workaround for the above problem is to add a new index field to refer to the document that has the keyword field from the documents that the keyword field refers to. This would change the scenario from a one-to-many matching to a many-to-one matching, which is currently supported by document relations. Unfortunately, autoindex matchcodes can only be configured to match using the "is equal to" or "is not equal to" operators; keyword fields are completely unusable. This means that it is impossible to go from one-to-many to many-to-one using autoindexing.

Proposed solution:
It would be an ideal fix if keyword fields could be used in matchcodes with "is equal to" and "is not equal to" operators for comparing a keyword field to a keyword field (using set equality rules) and "contains" and "contained by" operators for comparing a keyword to a text field. This fix would also allow for a simple workaround to the document relation issue.

One-to-many relationships in documents are commonplace, so DocuWare should be able to handle these scenarios without complex workarounds.