Create a Custom Content Dictionary Denylist for Titus Labelling

I am testing .docx files labelled using Titus.

I have metadata scanning enabled and can see in the Content Aware Report when my Custom Content Dictionary matches text in a document header or footer. However, I need the Denylist to match only content in the header/footer, not the main document body.

I also want to understand the distinction between the visible header/footer watermark and the Titus classification label itself. If a user manually edits or removes the visible header/footer text, is there metadata or another non-user-editable label value that I can use in the Denylist Custom Content Dictionary instead?

In short, is there a supported way to:

  • Restrict a Custom Content Dictionary match to Word headers/footers only?
  • Reliably detect the underlying Titus label, rather than relying on visible, user-editable text?

Hi @a_field,

Thanks for raising your request.

I would like to guide you toward a more reliable solution. Years ago, I worked with Titus tools, and I know that besides visual markings, such as watermarks, headers, and footers, Titus also applies metadata to the document properties, known as docprops.

You can easily check this in Office applications such as Word, Excel, or PowerPoint by opening File Info → Advanced Properties, as shown in the picture below.

Alternatively, for a more advanced check, you can take a copy of a sample file, change its extension to .zip, open it, and navigate to:

docProps/custom.xml

There, you should be able to find the required label/property details.

Then, in EPP, go to Denylist → Custom Content, add a new custom dictionary using the details from the document property label, and assign this custom dictionary to your CAP policy.

Please let me know if this addresses your needs.

BR, Krzysiek

Thank you, that’s really helpful.

I believe I found the solution. It wasn’t actually docProps/custom.xml, though. Instead there’s a customXml folder in the .zip. From there its item1.xml to the Titusmetadata property.

I’m going to do a few more tests to confirm, but this looks good so far.

Thanks again