Plan Your Data Model

Record types allow you to unify and secure your enterprise data so you can easily build data-driven applications. But before you create your record types, you should map out the data model that accurately reflects your business logic.

In Appian, a data model represents all the data available in your application. When planning your data model, you should use by the following data modeling practices and patterns:

• Define major business concepts.
• Store lookup data in a separate record type.
• Manage lists with one-to-many relationships.
• Manage many-to-many relationships with a join record type.

Once you plan your data model, you can start creating record types. As you build your record types, ensure you're following other data fabric best practices.

Define business concepts

The most critical step in data modeling is identifying which business entities warrant their own record type. A record type should represent a distinct business concept or major process in your business workflow.

To identify your record types:

1. List the primary people, places, things, or events your application manages.

   Example: A retail application might manage:

   • Customers
   • Orders
   • Products

2. Identify the different attributes of each entity.

   Example:

   • Customers have names, addresses, and phone numbers.
   • Orders have line items and shipping information.
   • Products have names, colors, and prices.
   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

3. For each entity, assign the attributes as fields and identify if any fields should become separate entities. If a field requires a list of values, create a separate entity for that data.

   Example:

   • Customers may have multiple addresses (home, office, billing), so we'll create a Customer Addresses entity.
   • Orders can have multiple line items, so we'll create a separate Order Line entity.

4. Determine how each entity is related.

   Example:

   • Customers
     • A customer can have multiple addresses.
     • A customer can have multiple orders.
   • Orders
     • Many orders can belong to one customer.
     • One order can have multiple line items.
   • Products
     • One product can be in multiple line items.
   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

5. Create a record type for each entity you identified in the previous step. Add the fields outlined above and configure relationships between related record types.

   Example: The Order record type may look like the image below:

   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Store lookup data in a separate record type

Lookup data (or reference data) consists of static values used to categorize other data, such as "Status" (Open, In Progress, Closed) or "Priority" (High, Medium, Low). As a best practice, you should store lookup data as a separate record type so you can easily maintain static data and avoid duplicating it.

You can easily generate a new related record type for your lookup data by adding a choice list field.

To manually create a record type for lookup data:

1. Create a database table for the lookup data. Ensure it includes a primary key field and a field for the lookup value.
2. Create a record type that connects to this database table.
3. Add a many-to-one relationship from your business entity record type (like Case) to the lookup record type (like Case Status).

The diagram below illustrates this pattern. The Case record type has a many-to-one relationship with the Case Status record type. This ensures that all cases use the same status values, preventing any data inconsistencies.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Manage lists with one-to-many relationships

You will often need to associate a list of items (or an "array" of data) with a single record. For example, a single Employee can be assigned to multiple Support Cases. In Appian, you model this by creating a one-to-many relationship.

To model a list of data:

1. Create a separate record type for the items in the list. This will be the child record type.
2. Ensure the child record type contains a foreign key field pointing to the parent record type.
3. In the parent record type, add a one-to-many relationship to the child record type.

4. (Optional) In the child record type, add a many-to-one relationship to the parent record type.

   Tip:  Bi-directional relationships help both people and AI models easily find related information.

The diagram below illustrates this type of data model. Each employee can be assigned to multiple support cases. To relate an employee to its cases, the Employee record type (the parent) has a one-to-many relationship to the Support Case record type (the child).

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Manage many-to-many relationships with a join record type

A many-to-many relationship occurs when multiple records in one record type relate to multiple records in another.

While you can't implement a direct many-to-many relationship between record types, you can effectively create a many-to-many relationship by creating a third record type to connect the other two. In a database, this would be a join table.

To model a many-to-many relationship:

1. Create a database table (the join table) that contains foreign keys for both entities.
2. Create a record type and use this database table as the source.
3. Configure one-to-many relationships from both your original record types to this new join record type.

The diagram below illustrates this data model. In this example, an Employee can work on multiple Projects, and a Project involves multiple Employees.

To create a many-to-many relationship between employees and projects:

• We created a third record type called Assignments. This contains an employeeId field and a projectId field.
• The Employee and Project record types both have a one-to-many relationship to the Assignments record type.

This allows you to reference related projects from the employee record type, and vice versa.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Feedback