What are case databases?
A case database is an author-configurable data store in a BRYTER service whose primary purpose is to store (case) records. Authors can create case databases within a Service. They can configure the fields - the database schema - and use the configured database in read or write database nodes in their modules. These native case databases can replace existing external database or Excel integrations and enable case management use cases.
Why are case databases useful?
With case databases, authors can create and set up databases themselves. They enable the storing of only selected data or act as the 'glue' between several modules in the same Service. With case databases, authors can depict case management workflows or can build smaller modules that store values that can be reused or enriched with subsequent modules.
 |
In the HR Absence Management example, the Module Request Vacation is used by employees to enter their vacation requests. The entered data is stored in the Case Database Vacation Requests. The line manager uses the Module Approve/Reject to read the request data out of Vacation Requests and to either approve or reject the request. The decision of the line manager is also recorded/written into the Vacation Request. |
How to use case databases
In the following, we will use a Client Due Diligence (CDD) Assistant as an example to illustrate how a case database can be used in Services. The first module in this Service allows the user to generate a CDD report, establishes whether a client due diligence is required, and notifies the legal team or General Counsel if necessary. All captured data (all collected values) will be stored in case databases. If any red flags are uncovered, the case will be written into the red flag database. The database is used by the General Counsel to review the case and the reported red flags and to decide upon the next steps.
Configuring a case database
In your Service, select Case Databases in the side menu and click on New Case Database to add a new case database to the service.
Create a case database by providing a name for your case database. Please note that the name of your database is restricted to 50 characters and can contain upper case letters, blank spaces or even emojis.
The new database now needs to be configured by adding all the required fields and field types to the case database. Field names no longer need to start with a lowercase letter and only contain lowercase letters, numbers, or `_` instead of blank spaces, but can now contain blank spaces and uppercase letters, e.g. Client address.
Click on Configure case database to set up the configuration or schema of your case database.
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.
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.
❗Note: Fields can only be renamed but cannot be deleted or be changed to a different type after the configuration is saved! However, authors can always add new fields to a case database.
Using case database nodes in modules
Authors can find the database node in the ACTIONS dropdown menu. As a rule of thumb, position a database node that writes into a database rather low in your module, following all value, action, and input nodes. Whenever you want to read from a database node, position the node rather high in your graph - after the identifier has been entered or passed through via URL parameter to retrieve the relevant case.
Writing values into case database
Once the database is configured, the values gathered in the module can be mapped into the database fields. Insert or add the database node at a position in your graph where all required values can be mapped into the respective fields. The database node default action is READ, if you want to write into the database, select WRITE.
💡 Label your database node to reflect whether a READ or WRITE action is performed.
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.
You can choose to leave fields blank. This is often the case when several modules are used to write values into the same record of the database. If you leave the ID field empty, the case database will automatically generate an ID for this record that can be used to retrieve the values written into it. This ID can also be used to read or update the record in the case database in the same or a different module. The record ID is also provided as the only OUTPUT parameter of the WRITE database node.
In order to write into the database, you need to publish your module. The previously empty DATA VIEWER of the case database will now display the stored values according to the publishing environment of the module.
The values or data gathered in this case database can be exported as CSV (Plain or Excel).
Reading values from a case database
As soon as values have been stored in the case database, the values can be retrieved with a READ database node. All available OUTPUT parameters - the fields in the selected case database - are displayed in the sidebar. The ID is the only INPUT parameter and can be @-referenced, e.g., from an input node, a URL parameter, or a value node.
💡 If you have chosen an automatically generated ID, you will need to pass through a text value, e.g., through a text input node or a URL parameter set to the TYPE Text:
After referencing the ID in the READ database node, authors can retrieve the values stored in the database through @-referencing the fields in any node that follows.
💡 Consider adding a condition after reading out of a database whenever the ID field has been left blank to account for faulty or non-existent IDs.
Updating existing values in a case database
A READ database node is often used in combination with a WRITE database node whenever values need to be updated. In order to update fields, authors need to enter the ID and only map values onto database INPUT fields that require updating or 'overwriting'.
Limitations
Multi-select input
Multi-select values can be written into case databases as comma-separated text only. They cannot be used subsequently as
Workarounds
- Display the comma-separated Text value in the multi-select input node and ask the module user to re-select these values.
- Create a Number field for each answer option and fill it with 0 or 1, and then pre-fill each answer option based on that.
Database configuration changes
Removing fields, renaming fields, and changing the type of fields is currently not supported. Reach out to your customer success manager who can help achieve this programmatically.
Preview and 'do not save user answers'
Case databases cannot be previewed in Preview mode but need to be published to TEST or LIVE.
We recommend using the TEST environment to test the set-up of your Service and disabling 'do not save user answers'.
Use case examples and best practices
👍 Good use of case databases
- Vacation request/approval containing separate modules for vacation requests and vacation approvals that each write and read out of a database.
- Any use case that requires to store and retrieve/approve cases.
- Build smaller modules with case database: split modules into smaller pieces that are connected with a database that stores required values for subsequent modules
👎 Bad use of case databases
We advise against using case databases as a clause library across several Services. Case databases are tied to a Service and can only be accessed from Modules in the same Service and cannot store formatted text or be edited directly.
💡 Best practices
- Pay special attention to all the required values and their types (email, text, number, file, or date) when setting up the configuration of your case database and provide concise labels for all fields to ensure easy mapping of module values.
- Open the database configuration and your module in separate browser windows
- Consider using prefixes or suffixes like user email instead of email only to account for a case database with a growing number of fields and values.
Known limitations
- Technical limit of 1,500 columns
-
Field names are case sensitive and have a maximum length of 50 characters. Field names must also be unique within a case database
Keywords: data base; Datenbank; databse