Understanding the Data Model Paradigm in Soopio

The Soopio platform operates on a paradigm where every piece of data is generally represented as an object. This guide will help you understand the platform’s paradigm for data models, which is crucial for developing an application.

However, Soopio is only weakly model-based platform which means that for an application to exist, there does not have to be any data model at all – refer to the Avoiding a data model section for further details. Nice to have freedom of choice, right?

Object Types

In Soopio, you can define various object types that will be used within the final application. Each object type can have specific properties and settings. Object types are elaborated on at a separate place in the documentation.

Properties of Object Types

Each object type can have various properties. Here are some possible settings for each property:

• Name: The internal name of the property.
• Caption: The display name of the property.
• Data Type: The type of data the property can hold. It can be any of the common data types or any defined type within the model.
• Required: Whether the property is required or not.
• Shown: When the property is shown.
• Multiple Values: Whether the property can hold multiple values or not.
• Mask or Calculation: Whether the property has a mask or calculation defined to its value.
• Default Value: The default value of the property.
• Constraints: Any other constraints defined for the property.

There are more options which can be specified for the Property, which are elaborated further in the documentation.

Accessing the object properties

Note that all properties and their values are lazy-loaded and can be accessed in certain implementation concepts (such as Shortcodes, Automations, and Canvases) with a context resolution operator.

Personalizing Objects

Each object type can be personalized with specific actions and tabs. This allows for a more tailored user experience.

Data Views and Data Queries

When storing and presenting data, you’ll need to work with data views and data queries. These are means of retrieving and displaying data from the persistent storage in the platform.

Role Definitions

The platform allows for defining very granular and specific role definitions. Each user role can have assigned specific permissions. These permissions can be set on the level of object type and also on the level of type properties.

Custom Canvases

Custom canvases are ways to display data in a very specific way. They can be used when building custom application look and feel, and when implementing custom logic (carried out by automations).

Automations

Automations are a way to implement any interactions, workflows, and basically any operation through the platform’s native set of tools. Automations can make use of predefined actions such as manipulation with objects and altering the application’s environment. They can also use sandboxed PHP code, task scheduling, environment variables, emailing, notifications, and so on.

Avoiding a data model

Let’s say you only need the application to serve as a public form gathering data and sending them to your code system such as CRM, or webhook handler which passed some information to systems further down the road. In such cases, you can implement the functionality without wasting your precious time building a data model. As a rule of thumb, when there is no required data persistence in Soopio application, no data model is needed. In the examples above you would do just fine merely with Canvases, Custom forms, and a little bit of Automations. However, as shown in the How to’s Custom forms part, you will see that sometimes it might be a good practice to implement relevant minimalistic data model even in that case.

Understanding these concepts is crucial for developing applications in Soopio. Happy implementing!