When you are tagging documents you are able to use the tag browser to find the relevant data that you want to pull into your document. The document tag browser provides your with data around the details of your document e.g. the recipient as well as data about the context of the document too.
What Is a Document Tag?
A document tag is a place holder that is added to a document template. When a document is generated from the template they system will pull in the data related to the tag. For example if you are writing to a client you may use a tag as a place holder for the name in the template and then when you generate a document in the context of a piece of actual work it will call in the actual client name instead of showing the tag.
Tags in the product show the path to get to the piece of data - for example context.roles.client.ods.name - this tells us that we are starting at the context for the document then we are looking for a participant with the role of client and then their name. You don't need to remember these tags you will be able to insert or copy them into your document from the tag browser. For a more detailed explanation on how the tags are built up and to understand how some common tags work then read this article.
Where Can I Access the Document Template Tag Browser?
You are able to access the tag browser on any individual document template (Launchpad > Open Document Admin > Document Templates). Templates are split into their different types, go into the correct section to select your template e.g. emails for an email tempalte. You should always use thetag browser from the template you are tagging to ensure that the context of the tags is correct.
What is Document Context?
The context of a document is the work it is primarily about. For example you may have configured a legal matter in the system for a property sale and you document is 'about' that matter. You may be working on an order from a customer and you wish to write them a letter - your context will be the order.
Items such as telephone calls and preparation of documents are also work items in the product. You may wish to have your template displayed on a telephone call e.g. to create a phone note however the context of that document would be the parent piece of work e.g. matter, order etc.
How Do I Find the Correct Tag in Tag Browser?
The document template tag browser is designed to take into account all the configuration you have done within the system and to expose the data you have created in a hierarchical manner. Working with the tag browser requires an understanding of how both out of the box objects in the product and your newly configured items relate to each other. Before you start to tag documents you should familiarise yourself with working in the user interface of the product as the tag browser is reflective of this structure In addition you need to be aware of the following basic concepts.
Work Types
There are many different work types in the system and this ranges from primary work types such as matters, order, contract, cases or whatever your primary use for the system is to auxiliary work types such as email, tasks, key dates etc. These work types are structured in a hierarchical familial way. For example a task may be a child of a case, or an order may be related to a contract. To work with tags effectively in your system you need to gain a basic understanding of this work type structure by looking at the work type structure in your system in [Modeller > Work Types]. You can also read more around work types here.
In the tag browser you will see parent, descendants, child, related as paths that you can explore This refers to how your current context is related to another piece of work.
For example, to query child tasks of a piece of work you would go down the child path as shown below:
ODS (Master Data Records)
The operational data store holds the master data records for entities in the system such as organisations, people, teams etc. The information held in ODS is global to the system. For example I may have a person entity of Faye Evans, she may have a correspondence address, billing address and delivery address stored against her in master data. Any or all of these addresses could be used in relation to a specific piece of work.
As different information is held on different types of entity e.g. organisation, person then if the participant roles you are querying can be held be multiple organisations e.g. an organisation or a person then the generic information will be held at the ODS level but for entity specific information you will need to drill down to either person or organisation.
A common tag found in ODS would be the person/entity name:
Participants
Participant is a use of an ODS (master data) entity in the context of a piece of work. Our person above for example could be the customer on one work type (an order) and the complainant on another (a trouble ticket). Her participation in each activity is different. We may also want to capture different date for that person depending on the role they are playing and the piece of work they are interacting with. For example in the example above we have a master data record in the system for a person which has three different addresses stored against it. If we have a work type of order then we may want to chose only one of those addresses to be the deliver address for the order. Find out more about participants here.
When you are using the tag browser for participants you will see that you can both utilise data captured at the participant level e.g. participant role, reference, contextual location (address), but you can also explore further using the ODS option into their master data record. Take case when using addresses to ensure you are taking the correct address for the context. For more information on this read this article on addresses and this article on names.
For example if I want to find the correspondence address for a defendant that is set against the matter:
Option Sets
Option sets are used to store lists of values in the system. For each value in an option set the system holds multiple values - an id, a name, a meaning code etc. When a piece of data is held as an option set you will need to drill down one further level to pick the piece of data you wish to use in your document. This is also true for some other entities in the system such as phases. Wherever you see an arrow > in the browser there is always another level you can drill down to in order to find the tag that you need. You can look here for more information on Option Sets.
See an example of navigating an option set in the browser below:
Custom Data Capture (Form Builder)
Form Builder is used in the system to create custom data capture forms. When these forms are created the tags are automatically created in the system. Forms can be added onto work types, ODS entities or parties To get the tags for these forms then navigate to the related item e.g. work item and then the name of the form should be displayed at the root level under the section within the browser labelled "Aspects". For more information on custom data capture click here.
See below example of navigating to a Form Builder:
Navigating in the Document Tag Browser
Moving around in the tag browser will take you no a journey around the data you have created in the system. The tag browser screen is designed to help you with this navigation and provide you with signposts on how to get to data.
The top section of the screen provides you with a breadcrumb to indicate where you are in the current data structure for your contextual work item. In the example below DocGenQuery represents the root level (the template), then you have chosen to go into the context work item (the other option is to query information on the document itself e.g. the recipient), then on the work item we have gone in to look at the participant roles on that contextual work item.
With the above selection the tag browser shows the following. Whenever an arrow is shown on the right hand side of the browser this means that you can drill down further to get the next level of data. For example in the example below once you have selected the role you want to query e.g. Buyer you can click on the arrow to get to the next level of information.
On some levels of the tag browser you may come across lists of things. For example in the screen shown below the buyer role on this work item can be fulfilled by multiple people e.g. Mrs A Brown and Mr T Goodwin. That means that we may have more than one buyer record. You will see below that there is a filter box on the screen with a resolve button. This will allow you to say for example you want the first customer or the second customer - clicking on resolve will give you the tags for the relevant customer e.g. context.roles.buyer!1.ods.name or context.roles.buyer!2.ods.name.
In your actual document you may actually want to list out both of the participants. To do this you can bind the list of things to a table in your document using the properties field of the table you add in.
Working with lists in the tag browser has its own topic here.