Build Approval Processes in BRYTER with Databases

  • Updated
Follow

Authors can utilize case databases to improve workflow efficiency in their approval processes. For instance, using databases authors can establish a recurring workflow that requires storing and retrieving/approving cases. An example use case would be a vacation request/approval application containing separate modules for vacation requests and vacation approvals that each write and read out of a database.

DatabaseAction.png

A step-by-step guide to building approval processes

While setting up an approval process with databases may require some time and effort, it is a powerful and effective tool to improve workflow efficiency. Follow the steps below to build an approval process for vacation requests in BRYTER with databases.

employeemodule.png

Build your first module

  1. In your Application, select New Module. This module will capture the requested vacation days from the employees.
  2. Create an Input node, including all relevant questions like the vacation start and end date, the employee's name, the manager's name, and email addresses.
  3. Before we can finish off the module by adding a case database node, we need to create set up our database first.

database.png

Configure a case database

  1. In your Application, select Case Databases in the side menu and click on New Case Database to add a new case database to the Application.
  2. Create a case database by providing a name for your case database.
  3. The new database now needs to be configured by adding all the required fields and field types to the case database. Click on Configure case database to set up the configuration or schema of your case database.
  4. When setting up the configuration of your module, we recommend opening both the module and the configuration page in two separate browser tabs or windows. Like this, authors can ensure that they don't forget any value and that the correct type is associated with the field. The identifier (id) of the case record is automatically added and can be renamed by typing into the blue field below UNIQUE IDENTIFIER.
  5. Once all fields have been added, select Save Configuration to save the schema and all the fields. Set up later will not save the configuration but discard all changes.

Finalize your first module

Now, that we have set up our database, we can continue working on our module:

  1. Towards the end of the first module, add a case database node by selecting Insert Action.
  2. The database node default action is READ – as we want to write into the database, select WRITE.
  3. Once you selected WRITE in the node panel, you can map your INPUT values into the fields by @-referencing them. Start typing "@" into a field and all values of the same type as the field will appear in the value picker. Click to confirm the selected value.
  4. Finally, add a result node letting the user know that their request is pending approval.

managermodule.png

Build your second module

  1. In your Application, once again select New Module. This module will allow managers to approve or reject the vacation requests made by their employees.
  2. Add a URL parameter followed by a database node to access the ID and retrieve the relevant case.
  3. Insert an Input node @-referencing the employee's request, giving the manager the option to approve or reject.
  4. Insert a database node and set it to WRITE. In the field 'status' enter 'Approved'.
  5. Insert a second database node and set it to WRITE. In the field 'status' enter 'Rejected'.
  6. Set conditions for each case and finish off with result nodes.

filter_records_by_values.gif

Image: Using filters in data views

Create data views

  1. In your Application, select Data Views in the side menu and click on New Data View to add a new data view to the Application. Create two data views in total, one acting as the 'employee view' and one as the 'manager view'.
  2. In the drop-down menu select the vacation request database. Select the fields you would like to be displayed in your data view by clicking the checkboxes. You can set conditions for fields to appear when the condition is met. In our above example, one filter record could be status is Requested, showing only pending requests.
  3. You can set up a button to allow for further processing in a BRYTER module. In the 'manager view,' you would set up the button 'Review' and link it to the second module you have built. Similarly, you could even build a third module to enable employees to not only view their request(s) but also cancel a request, if necessary.

Manager2.png

Image: Manager view

💯 Advantages of databases in approval processes

There are several advantages when using databases in approval processes:

  • A recurring workflow that requires storing and retrieving/approving cases can be established. For example, a vacation request/approval application with separate modules that write and read out of a database. A manager can access the module and approve several requests quickly and in one place only.
  • Authors can identify where a process might be stuck and nudge the relevant stakeholder(s) to continue the process through, for example, an action in a data view. Having a status page data view allows showing everyone or selected stakeholders if the approval is delayed or missing.
  • If multiple people are involved sequentially or if any approval requires the confirmation or additional information from two or more stakeholders, a database and data views are better suited to capture the process.
  • Databases and data views are better suited for approval processes where several hours, days, or weeks might pass between each handover or approval. In these situations, finding the email including the handover link might be tiresome.

❌ When should you rather use Handover Nodes for approval processes?

For some use cases, Handover Nodes may be a better fit to execute approval processes. Some indicators that handover Nodes are better suited for a handover process are listed below:

  • No stored information: A case database is an author-configurable data store in a BRYTER Application whose primary purpose is to store (case) records. When you are not reliant on retrieving or approving already stored information, Handover Nodes might be the better option.
  • Simple Yes or No: When the handover is followed by a single node, requiring no more than a simple 'yes' or 'no', then a handover node is preferable to databases.
  • Immediate or timely action necessary: Handover Nodes are better suited for approval processes where immediate or timely action is necessary between each handover or approval.

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