Set up a Data View

What are data views?

Data Views allow authors to configure a filtered view of an underlying Case Database within an Application. This enables authors to create more than one Data View that uses the same underlying Case Database but is geared toward several stakeholders with different fields of the records displayed to them.

Authors may customize their Data View by choosing which field(s) and/or record(s) they would like to be displayed. Additionally, authors can set specific action buttons to allow for further processing in a BRYTER Module.

Why are data views useful?

Different groups of people look at the same data in very different ways, filtering out the information that may not be relevant to their role or position. This is where  Data Views come in. Data Views act as a filtration system: In other words, depending on your role within an organization you are shown different data, specifically, data that is relevant and appropriate to you.

Let us review an example use case, the administration of vacation requests:

When an employee submits a vacation request, a new entry is created in the relevant Case Database within your Application. For a variety of different reasons, it may be necessary that employees are able to access their vacation requests. However, you would generally want the employee to only see the request(s) that they have submitted. On the other hand, you would want managers to see all vacation requests submitted by any of the employees. In that case, you would simply set up two different Data Views, one is geared toward employees ("end-user dashboard"), and the other is geared toward managers ("operator dashboard").

This becomes even more significant when you allow for further processing within a Data View. E.g., an employee cannot only view their submitted vacation request but edit it to change the dates on a pending request. Or a manager can click a "Review" action button to process the vacation request in a linked BRYTER Module which 1) checks against the employee's remaining vacation days and 2) asks whether the manager would like to approve or reject the request.

The filters for a new Data View can be configured to meet the specific needs of the different groups. While an employee may be interested in seeing all of their past vacation requests, a manager who is responsible for several employees will likely only find current and pending requests important which allows easy administration of vacation requests.

How to use data views

1. You can find Data Views in the sidebar of an Application.
2. New Data View lets you configure a Data View, based on a Case Database within the same Application.
3. Save automatically publishes Test and Live versions of the Data View. (A Live Data View shows data from the underlying Live database, which is used in Live Modules.)
4. From the list of Data Views, select Test or Live to open the published version of the data view.

How to create a new data view

• General: Provide a name for your Data View by selecting the breadcrumb trail in the black navigation bar.
  
• Case Database: Select the underlying Case Database for your Data View in the Data View editor on the righthand side. Once you select the database, options for Fields will appear, along with Filter records (optional) and Actions (optional).
  

  

• Fields: Select the fields you would like to be displayed in your Data View by checking the checkboxes. Note that there are two columns. The first one (where you select the fields) displays the field's name. The second column displays the name used when referencing in the fields "Filter records" or "Actions". It is displayed in grey. If you select no checkboxes, then no fields will be displayed. Ticking Select All will display all options.
  
• Filter records (optional): You can set conditions for fields to appear when the condition is met. In our above example, one filter record could be status is Canceled, showing only canceled requests.
  
  💡 Find more detailed documentation in 🗄 How to filter in Data Views
• Actions (optional): Set up a button to allow for further processing in a BRYTER Module. In our above example, the Button label could be "Cancel" and link to the Module that simplifies canceling requests by eliminating unnecessary steps. Different URLs can be specified for Test and Live environments, e.g., the same Module published in either TEST or LIVE.
  
  💡 Find more detailed documentation in 🗄 How to use action buttons in Data Views

Use case examples, best practices, and known limitations

👍 Good use of Data Views

• Different stakeholders see only the data that is relevant: In the vacation request example, only a manager would see all requests whereas employees will only be able to see their own requests.
• Combining relevant data inputs of several databases and associated Modules for BRYTER users: While collaborators of Applications, i.e., Authors and Admins, are able to download the Stats of each Module within the Application separately, a Data View allows for pulling together and linking relevant data collected across several Modules for BRYTER users without editing rights. They can download the necessary data as a CSV file.

👎 Bad use of Data Views

• Using Data Views simply as another way of downloading Module stats for authors and admins: Module Stats provide richer data than Data Views for a single Module. They can however be used to ensure that only completed sessions are displayed

💡 Best practices

• Use human-friendly column names: Data Views will display the column names of the fields in the selected database. Consider using sentence case instead of only lower case and adding emojis such as calendars or exclamation marks to create user-friendly Data Views.
  
• Avoid displaying too much irrelevant data: If authors only want to display records with a certain status or only containing a specific manager email, they should consider using filters and refrain from also adding as a field.
  

❗ Known limitations

• Configurable sort order or column reordering
• Linking to a non-BRYTER Module: As a workaround, you can publish a Module that goes straight to a Redirect Result Node.
• Ad-hoc filtering and sorting by Data View users
• Embedding Data Views: Data Views can only be used by logged-in BRYTER users (anyone with a BRYTER account, e.g., user, author, or admin)
• Multiple action buttons or conditional actions

Keywords: dataview; dataviews; Datenansicht; Dashboard; case overview; data base; databse; Datenbank