Storing data in the model

Model initialization

The data model for the application is created when the application instance starts (see Running an application). After the model is created it can provide values for fields according to the definition of data sources. And accept values for fields stored locally.

Data storage location

Data stored in the model can be divided into two types — by storage location and by who manages them.

Data retrieved from services

If the application uses data stored and managed by organizational or external systems, it is retrieved via services. The low-code application does not own this data, cannot modify it, and does not control changes to its values.

Values are fetched from the service and are always up to date, subject to caching (see Editing the data model).

Examples

• current customer address

  • the customer submits an insurance purchase application

  • after submitting the application, and before generating the sales agreement, the customer changes the address data stored at the bank (usually via a dedicated process)

  • on the insurance sales agreement we have the updated address — it will be fetched during the process according to the data definition in the model

• account balance

  • when accepting instructions the application verifies whether the specified customer account has sufficient funds to cover service charges

  • before actually debiting the funds the application may re-verify the funds to correctly handle the account charge

Data stored in the model

When data is created and managed by the application, it is stored in the data model. The low-code application owns it, can modify it, and controls changes to its values.

Examples

• requested credit card limit

  • when applying for a credit card the customer provides the expected limit value

  • the application may change this value during process handling (e.g., reduce it)

  • on the generated agreement (and likely in communication to the customer) we have the current limit value

• customer correspondence address for process handling

  • when submitting a loan application the customer provides a correspondence address

  • by default the application shows the address stored in the bank’s systems (fetched from the service)

  • however the customer may change this address and request correspondence regarding this process be sent to a different address

  • the application preserves the values entered by the customer

Data outside the model

A low-code application does not have to store all data in the model. Some data is temporary and serves only to determine the target value or make a decision, e.g.:

• list of the customer's accounts

  • generates the account choice domain for the Select value field component

  • allows the customer to easily choose a specific account

  • in the data model we only want to have the account selected by the Customer; the entire list is not needed

• customer age

  • allows making a decision about the possibility of purchasing a product (e.g., Card <26)

  • is calculated from the PESEL number

Temporary, operational data can be stored in session variables on forms, process variables, or script variables.