Think Differently about your App Data & Process

Think Differently about your App Data & Process

Rise above using repetitively low-level tables to model and store your App Data.

Think more abstract, and Model your App Data and Process as Dynamic Lifecycle-driven Objects, stored in MongoDB as Documents, with Item Lifecycle & Identity-based Access-control built-in.

Todo App Example

For instance, a simple Todo Application has a Task with a property to hold the text for the Task.

And the Task can have any additional properties you want, such as a Priority, a Difficulty, and a Target Date, for instance.

The Lifecycle for the Task might include an initial Pending Start-State, a Doing State, and a final Done End-State, for example.

In addition, Gnosis No-code Workflow can run on the Lifecycle State Transitions allowing you to do anything you want.

With Gnosis, regardless of your Front-end Tool, your application’s Back-end remains the same.

Item Type Lifecycle Models

In Gnosis, your Items, like people, places, and things, are Modeled as Item Types with Properties to define the data you want to collect and manage, such as strings, numbers, dates, etc.

Item Types are dynamic and extendable, meaning you can change them with immediately updated views with No-code.

The actual instance data, the Items, are stored as MongoDB documents allowing for dynamic changes to the Item Type.

Item Types API


Within Gnosis, Item Types Model your data with Properties such as strings, numbers, and dates to define the data you want to collect and manage.


Items are the instance data for the Item Type Models. These are the rows when you think in terms of Tables. Items are stored as MongoDB documents.

Item API

Items API

Item Relationships

Create one-to-one, one-to-many, and many-to-many relationships with Item Types. Don’t worry about Ids, Primary and Foreign keys, or anything else.

The Gnosis Relationship Type is how to Model one-to-many relationships. For instance, a Student has many Classes.

The Gnosis Link Type is how to Model many-to-many relationships. For instance, Students have many Professors, and Professors have many Students.

And because a Link Type is an Item Type Model, you can put Properties on the link, as in the case of a Bill-of-Materials. A BOM is a Part-to-Part relationship model where the relationship between the Parts includes Quantity and an Effective Date, for instance.

The Gnosis Complex Property Type is how to reference one-to-one relationships.

Item Types are Extendable

You can derive/extend an Item Type to create a new Item Type. The new Item Type Model picks up all the Properties and Relationships from the Source Type.

In addition, you can override the Properties and add additional Properties to the latest Model.

For example, a Person Item Type Model would have Properties about a person such as First and Last Name, Email, Cell Number, Address, and so forth.

Then a new Healthcare Provider Item Type could extend the Person Model adding additional Properties for Credentials and Licenses. And as another example, a new Student Item Type can extend the Person Model by adding a Major and GPA Properties.

Item Types are Polymorphic

Item Types that derive from other Item Types can be Polymorphic, meaning the Items for these Types can change between the Types that share a common Base Type.

For example, you can change a Person Item to a Student Item because the Student is a Person with more information about being a Student.


Views are how you visualize and manage Items.

Gnosis No-code auto-generates an Items View (a Grid/Table View), plus New, Update, and Read Views for each Item Type.

Gnosis Navigator provides a No-code Content Management System that allows you to instantly use the Solutions as an Application.

Auto-generated Views can be configured with No-code and are updated as Item Types are dynamically changed.

You can also create Gnosis Low-code Views to generate any result or view you want for your Items and create custom Web APIs.

A User’s ability to render or invoke a View is based on Identity Permissions, and the Item’s Lifecycle current State is optional.

View API


Item Types have a Lifecycle, which defines all the possible States the Item may be in during the Item’s life.

For example, a Page may go through the Lifecycle Staes from Draft initially to In Review, then Published, and finally Archived.

Workflows (No-code logic) are triggered to perform anything you want when an Item Transitions between the Lifecycle States.

A User’s ability to Promote an Item and perform the Transition is controlled by Identity Permissions.

Lifecycles API


Gnosis No-code Workflow can perform anything you want and is invoked when Items are Created, Updated, Promoted or Deleted. And in addition, workflows can be invoked as custom API endpoints.

Workflow API


What are Webhooks?

In general and not specific to Gnosis, a Webhook is a way to be notified and receive information about something when an event has occurred. To get the information, you would register a callback with the service, hence Webhook.

The callback is your service expecting to be called and handle the information it gets.

Gnosis Webhooks are Item Event and Lifecycle Transition No-code Workflows, so you can do anything you want, including calling any other endpoint.

Webhooks API


Solutions are like namespaces, a named collection of things that logically belong together and can be used in combination with other Solutions to create an Application.

For larger Applications, many Solutions are typically used to improve separation of concern and reusability. For instance, the CRM Solution that manages contact relationships can be shared and used with other Solutions to create various Applications that all need the same CRM capabilities.

Solutions API