The data model refers to the terminology and structures involved in the particular problem you're solving or feature you're implementing. 

While the workflow features of WorkflowFirst will create much of the data model for you, it's worth understanding how data models are created in WorkflowFirst so you can easily go back and add fields to forms and other structures, or modify existing fields.

Let's take a simple and familiar example to demonstrate the data model, a to-do list. In this example the terminology involves tasks, due dates, priorities and state. If we were to put these into a structure we would need to define how these different categories relate to one another. In this case we would say that we have a list of tasks, and each task consist of a title, a due date, a priority and a current state. The current state would be that it's either a pending task, a task in-progress, a deferred task or a finished task.

Creating the data model is perhaps the hardest part of creating any application, which is why the workflow features are built to save you from having to design the data model yourself. 

Luckily, WorkflowFirst makes it extremely easy to enter the data model quickly and efficiently. If mistakes are made, or if the data model expands or needs to be reworked, it is a very easy process to move sections around, delete or add new sections to the data model.

What also makes WorkflowFirst different to other systems where data models are designed is that data models in WorkflowFirst are hierarchical . We should all be familiar with hierarchical relationships: families, corporate structures, or the more mundane folder structures we create on our computers all reflect how easily we can comprehend hierarchical relationships.

On a more practical level, we tend to naturally think of data structures in hierarchical terms: a team has a list of projects, a project has a list of tasks, a task contains fields. When we say 'this has a that', 'has a' relationship defines the primary (most important) relationship between the two items. There may be other ways of relating the data that is not strictly hierarchical (for example, a project may involve two or more teams), but focusing on the primary relationship, which is the hierarchical relationship, allows us to greatly simplify the design process. 

There are various terms adopted in WorkflowFirst when working with the data model, and it's important to become familiar with them before starting your application design:
 

• Field : A field refers to a category of simple data. 'Age' would be a field, 'Task Priority' would also be a field. These are categories that contain simple data, such as numbers or words. 

• Type : A type refers to a collection of fields that make up a particular entity. It is like the 'template' or 'design' for all specific instances of some data. An example of a type would be a 'Project'. This is not a simple category, it consists of multiple attributes. A project would have a number of fields: a title, a due date, a project manager, and perhaps a budget, and so on. 

• Form or Nested Type : This is a mixture of a field and a type: it's a field that is itself a type. You can think of a nested type as a subfolder. If, following on from the previous example, one had a type called a Project, there may be a field within a Project called a 'Task List'. This is a component of a project, but it is not a simple category: it is not a number or a series of words. It is a type, and because it is defined within a type we call it a form or nested-type. 

  The 'Task List' nested-type would hold fields such as a title, priority, due date, assignment, status and so on. A 'Task List' may itself have additional nested-types (a task log, for example), and that goes to show how a hierarchical data model simplifies defining the relationships used in an application.

• Data Type : When defining a field, one must specify the kind of data that the field will hold. Will it hold a number? If so, would it allow fractions? Can it hold a yes/no value, known as a Boolean? Will it hold a name? A sentence? A paragraph of text? A file attachment? These are all different data types that can be chosen when defining fields.