Modeling Data for Custom Applications

In the platform, an application is a collection of related data objects that provide a collection of information, enabling various people to access the information in various ways, and automated processes to make working with that data easier. In addition, the platform enables you to customize apps so they can best fit your unique or changing business objectives.

Objects within Applications

Objects are the basic building blocks you use to collect information for your application. They are often represented by tabs that you can click on to see views of the data.

Once you’ve established your business objectives, it’s time to start thinking about how the application will function. Applications are data-driven and therefore you should have a good understanding of the data and associated processes you wish to accomplish as a result.

Map Out Your Data

For data-driven applications such as those created using the platform, one of the most crucial elements is making sure you properly structure your data.

The ideal method is to start with a spreadsheet arranged in columns with sample data. You can have more than one type of data, but be sure you understand how they relate to each other. If you have ever built a list in a spreadsheet or database tables and related them, you can build the basic structure of an application. Within the platform, these objects will be represented by tabs.

For example, you might have data objects that are specific and discrete. To relate these objects with each other, an intermediary object would provide the necessary lookups across both to ensure they can be related. Once a lookup is established, the platform automatically provides the relationship.

Other Considerations

• How do field types affect your application? Do you have specific fields that have limited possible entries? (For example, an "Importance" field may include "High," "Normal," and "Low" as the only possible options). This would be the basis for choosing a Picklist field. Or perhaps you have a field that has a specific range you want to associate.
• How deep do you need information to be? For instance, in the example above, is Caterer also another object (which in the platform is a lookup field)?
• Where will information come from? Are people going to manually enter data, is it from an external customer entering data from your website, will you be pulling data in from a file (CSV for example), or do you have deeper integration needs?
• Is your data clean? Bad information going into a database is useless no matter how good the application. Before importing data into the platfrom, you will want to take this opportunity to clean your data as best you can before introducing it into the app.

Relating Objects

Relating objects is the most important concept of the platform to grasp because it is what moves you from flat two-dimensional data (spreadsheets) to deep, multi-dimensional objects. The platform provides the ability to relate one object to another using the Lookup field. This enables very complex data models for creating "one-to-many" relationships. By creating a lookup field on one object, a corresponding "Related Information" section appears on the other object.

For example, a Team can have multiple Players, but a Player can only be on one Team. In this case, the Player has the lookup field Team and the Team has a series of related records of each Player linked to that Team.

Many-to-Many Relationships

To create a "many-to-many" relationship, you will need to create another intermediary object with lookups to both objects. For example, a Parent can have multiple Children, and a Child can have multiple Parents. In this case, you would create a Relationship object with lookup fields to Child and Parent. And the Relationship object will also describe the kind of relationship (e.g. Father to Son, Mother to Daughter, Father to Daughter, etc.) The automatic Related Information about each will appear in both. This intermediary object can be hidden from your standard application views.

Using Fields

Fields provide unique attributes to define the structure and what data is contained in an object. The built-in Field Display Types enable very comprehensive definitions of what the data should look like.

Here are some best practice tips for field display types:

• Consider any repetitive information within your data. These may be strong candidates for using a Picklist or Global Picklist. For example, state abbreviations, lists of countries, military rankings, etc. This improves usability and improves database performance.
• Consider how the data will be used. For example, while a ZIP code may appear to be a number, it actually works better as a text type for display purposes.
• While it may seem like a good idea to use a Rich Text Area, you need to consider if it is truly necessary. And some fields like Rich Text Areas are not available in Web Forms.
• Formula fields can be very powerful, but also have a complexity in that values will not update unless the record itself is updated. If you need formula values to update, you may consider using a data policy to refresh data on a nightly basis.
• Adding tighter restrictions on the fields and objects will provide you with better data input and more accurate reporting. To do this, you need to consider the least common denominator of what you want your users to enter.
• Consider using data validations to restrict the values based on your required conditions.