WorkView|Case Manager is a data-centric business process solution that allows you to create custom applications to meet business needs that uses your existing OnBase database. There are 6 essential parts to WorkView. WorkView can also utilize Workflow to move a record/object just like it was a document. Records/objects can be evaluated in Workflow Rules to determine what steps in the business process the record/object needs to take.
The application is the business process you are creating in WorkView. This could be Accounts Payable, Human Resources, Support/Help Desk or even Insurance Claims. In the picture below, our Help Desk is made up of 4 different classes (Cases, Customers, HelpDeskEmployees and Notes). An application is a collection of multiple classes.
The class is “database” of the application. The class is set to describe what data is being stored. The class could be named Customer Information if the data being stored is the information related to an invoice for a customer. Each application can have one or many classes. Classes can be related and associated to each other to give a dynamic relationship in an end user’s interface. Classes can also be created to extend to external data to provide one interface for multiple data sources using an External Class. For example, an external class can setup to use data existing in an ERP system to be used within WorkView.
In the diagram below, you will see how the data between the 4 classes is related in our Help Desk example.
The Customers Class has a “one to many” relationship to the Cases Class. One customer can have many cases open.
The HelpDeskEmployees Class has a “one to many” relationship to the Cases Class. One employee can be assigned to many cases.
The Cases Class has a “one to many” relationship to the Notes Class. There can be multiple notes assigned to a particular case.
If you needed a “many to many” relationship between two classes, an association class would need to be configured.
Attributes are the “columns” of the class. Attributes are the values in a record/object in the class. For example, in the Customer Information class, you may have the following attributes: Customer Name, Address, City, State, Zip. Attributes can be displayed in a user’s interface for data entry, reporting or record look-up.
Filters allow users to have records displayed in a particular layout or with data from different classes. Filters are customizable at the administration level (WorkView Configuration) and user levels (Unity and Web Clients). Users can create custom filters to meet specific needs. Administrators can create filters to push to particular users for their job requirements. Filters can have fixed constraints that are set in WorkView Configuration or they may have user constraints that the user is prompted for when executing the filter. In the picture below, “All Open Cases” is an example of a filter.
5. Filter Bars
Filter bars are a group of filters that can be assigned specifically to a user group or even a particular user. Filter Bars allow filters to be accessed in a more user friendly grouping. Filter bars can be grouped by job function or even by the data in which the filters are retrieving. In the picture below, “All Records Bar” is an example of a Filter Bar.
A screen is the user interface of a WorkView solution. Screens provide customized views to the end user to meet a particular business need. The screens can display attributes and filters for a record/object. Screens are also the interface for data entry if the record/object can be created directly from a class. Screens can also utilize Cascading Style Sheets for their layout.
Here is an example of the Case Information Screen in our Help Desk application
WorkView allows you to customize an application that fits all of your business requirements and give you a user interface that makes sense! If you have a data-driven business process that needs revamped, WorkView is your solution!