What are case databases?
A case database can be used as author-configurable data storage 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. For a better overview, take a look at our case databases article.
What is a unique identifier (ID)?
The identifier (ID) is a unique sequence by which a person/record/case/matter/etc. can be identified by a computer system, network, or – as in this specific BRYTER example – a case database. We use IDs frequently in our daily lives – whether in their physical form to identify ourselves to certain professional groups or – even more frequently – on the Internet, to log onto platforms to check our emails, transfer money or build modules on BRYTER.
Sometimes we do not recognize IDs right away, as they can have different names depending on the context: e.g. case number, customer number, employee number, ticket number, etc. – this already gives us an idea of potential use cases in terms of building modules.
In case databases, IDs link user entries (records) to the specific user and allow for hassle-free further processing, e.g. in other modules. For instance, by passing a record's ID to modules via URL parameters, different modules can work on the same case. This is a great feature when it comes to Hand-over processes.
How to use IDs
Every case database comes with a special ID field that uniquely identifies a record. The identifier (ID) of the case record is automatically added as a mandatory field in every case database and can be renamed by typing into the blue field below Unique identifier, e.g. client_id, technician_id, employee_id, etc.
As databases can be used to read values out of the database and/or to write values into it, there are different options when it comes to using the ID:
Writing values in a case database
You have two options when setting up an ID to write in a database, you can:
- leave the ID field empty – it will be generated for you automatically; or
- specify an ID – but you will need to ensure that it is unique for this database as existing entries with this ID would get updated and overwritten
If you write a record without providing an ID, a unique and hard-to-guess ID will be automatically generated for you, it could look something like this: 4579a71e-7053-4ee4-8c38-baf2488f3166.
This is helpful as you do not run the risk of setting up an ID (e.g. through referencing the client_name) that could be already existing or become non-unique at some point in time. For instance, when another user has the same name as an already existing one. Similarly, while emails tend to be unique, there is always the possibility that a user changes to a different email which would make the records from the database non-retrievable, deeming them potentially useless.
Whenever you want to retrieve records from a module (that is, reading values from a case database), it is advisable that you provide an ID. While some IDs like ticket numbers do not necessarily have to follow a specific pattern, others do to easily identify and reference. Think of the examples mentioned above, e.g. case numbers, client numbers, etc.
Sometimes you want existing entries to be updated or overwritten in a database, e.g. whenever you want a user to be able to update the old information that is no longer relevant. If you specify an ID in a Write database node, and an entry with that ID exists in the database, the existing entry gets updated with the new values provided. Only fields with a non-blank value get overwritten.
Reading values from a case database
By specifying an ID (as plaintext or as a variable reference) in the Read node, you can read all the values from the relevant database fields if the entry exists. 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 it 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.
Keywords: data base; databse; Datenbank