Creating an app

Customers with a workflow instance will be able to create workflow apps in Toqio Workflow Design as modellers. After they are created and ready to be used, customers can publish and deploy them.

An app must have at least one case (with an empty human task) and one page: those are the minimum requirements for an app that will be configured in SMEs and apps to be displayed. This is because the marketplace needs to detect the case and the page to create the feature for the customer. It is also possible to use an app only as a container of functions or as a library to keep process models, services, actions, and data objects.

For creating a case, select the “Add Model” button and then select the option “Create a new model for the app”. You’ll need to choose “Create a new case model” after that.

The same procedure occurs for creating a page model.

Pages are the main interfaces that will be rendered.

Models

It is critical to have a naming convention that is used for all the models in Toqio Workflow Design. This ensures consistency and makes it much easier to model.

In our low-code system, models are the building blocks for implementing functions. Each modeller will usually be working on multiple models at the same time, and the same environment will usually be used by multiple modellers/developers. Therefore, without a proper naming convention, things can get chaotic quickly. The most common models are:

• Case: Case models are based on the CMMN standard. They are flexible and the sequence is unimportant, they are intended for interaction between different users. With cases, you can orchestrate the full life-cycle of a new solution that you want to create. Some examples include:

  • Customer complaint management
  • Onboarding new users
  • A full lending flow

• Process: This model is based on BPMN standards. It is a back end process that can be called from a case, form and pages or a specific point in time. It is a structured chain of activities and can contain deviations but needs to have start and end points. Examples include:

  • Pay/deny a manual expense
  • Generate a bank statement
  • Integrate and orchestrate sources

• Decision: The decision model is based on DMM standards. Decision models are generally a table where complex rules are defined, where the order in which they should be followed is kept and available for analysis. Some examples might be:

  • A payment schema section
  • The assignment of a status to an account or transaction

• Visual part: This model houses forms and pages.

• Data object: This is the representation of data used in a process or case. It allows storing and accessing structured information and associating variables with a name and data type for use within a process model.

• Data service: The data service model interacts directly with data sources, facilitating data access, querying, and use during workflows and processes. This model can connect applications with external databases.

• Liquibase: This is a database version control tool. It is used to manage changes in the database schema, facilitating updates and ensuring that changes are consistent and reproducible.

The following table shows the naming convention that MUST be used in all Toqio low-code implementations:

The app key is usually a three-character string and prefixes all the other model keys that are created in its context. That does not mean, however, that the same model cannot be used in multiple apps.

Model keys must be unique throughout a Toqio Workflow Design instance. This is why it is recommended that they always follow the structure:
[AppKey]_[ModelAbbreviation][3DigitNumericSequence].

Example: For the PPP app, the first form model will have PPP_F001 as a key, the next form will have it as PPP_F002, and so forth.

An exception to this can be made on Liquibase (schema) models, where it is useful to add a descriptive part of the key, since it is the information displayed in Toqio Control where the updates to the database are done.

Model names should be human-friendly, so they should actually be meaningful to people who read them. It is also recommended that the key be a part of the name, so that this important identifier is always present in every possible situation within the low-code platform. The only exceptions can be situations where the name of the model can be visible (for example, a start form of an action shows the name of the action model as title).

Data

Any case or process instance has a payload, which is composed (among other things) of variables instantiated on a case, process, or form model. The data can also be stored in the database as data objects.