To understand how Knowledge Views work, we must first understand what Process Director does with definition objects like eForm definitions, Process Timeline definitions, Workflow definitions, etc. The definition object contains no actual data, but merely defines what data will be stored. For example, the eForm definition describes the data fields that the user will fill out to enter data. Similarly, the Process Timeline definition describes when activities will start and end, or when a user task will become due, based on when the process begins.
Regular, non-administrative users never interact with any of the definition objects directly. Instead, when a user wants to, say, fill out an eForm, The eForm definition makes a copy of itself, called an instance, that the user will fill with data in the fields specified in the eForm definition. This instance object is what actually contains the data entered by the user. If ten different people fill out an eForm, Process Director creates an instance for each person, so that there are ten instances of the eForm, each of which contains the data filled out by one of the ten users.
By the same token, when a user submits an eForm that initiates a Process Timeline, a new instance of the Process Timeline definition is created that stores the information about that specific run of the process. The whole purpose of the definition object is to describe the instance objects that are created to interact with the user.
Let's take a closer look at an example of the Process Timeline definition and a Process Timeline instance. When the definition is created, we might define a user activity as being due three days after the activity starts. When we create the definition, we obviously don't know when the activity will start. All we know is that, whenever the activity starts, we want the activity to become due in three days. When a user submits the eForm that starts the process, Process Director creates an instance of the Process Timeline that contains the actual activity dates for that specific run of the process. So, in our example, if the activity begins on January 1st, the Process Timeline instance that is created will now set the due date for the activity as January 4th.
When we search for information in Process Director, we really don't care much about the definition objects, because they don't contain the data. While there are other, more complicated scenarios for using Knowledge Views, we are usually interested in searching through all of the existing instances of an eForm or process to find specific data. We might, for instance, want to search for all timeline activities that are due in the next week, or for all eForms that were submitted by a specific person.
Knowledge Views display information in a tabular format, much like a spreadsheet. So much so, in fact, that the Knowledge View results can be exported to CSV or Excel format.
When constructing a Knowledge View, you select the columns that you wish the Knowledge View to display. The columns can consist of any system variable, such as eForm fields, business rule results, Process Timeline values, and much more.
You can also choose to see different types of objects in the results. You can search for eForms, Process Timeline instances, business rules, documents, or any other type of Process Director object. You can select any number of object types to return, as well. The ability to return results containing any system variable from any type of Process Director object makes Knowledge Views very powerful.
Adding to that power is the filtering capability of Knowledge Views. Just as you can make a Knowledge View column out of any system variable, you can also filter every column to return only specific results.
The example in Figure 119: Knowledge View Search Filters shows the search filters for the Travel requests Search Knowledge View.