Just like anything else you can build, both physical and virtual, the first step towards success is creating solid foundation. While it is possible to start building your app immediately and continuously make additions on as you go, you should first step back and consider what you are trying to accomplish.
Building solutions without a defined plan is like cooking without a recipe. While you can try to figure it out as you go, you are leaving success to chance. First, try to think about the bigger picture of the overall system you are trying to create. You can start to construct your plan by creating a punch list of the different problems you aim to solve. After this, consider the different buckets of data you will encounter in these situations. What are you trying to track? Are any of these elements dependent on other elements in your system? How are these elements related to each other, and how will they work together?
By setting expectations for standard functionality, planning out what you intend to build, and architecting how the pieces will work together to meet your requirements, you can move forward feeling confident with the solutions you build. This article walks you through the process of creating this plan and highlights different tools available to build it.
The first step to creating an app is building out your data model, also known as your schema. This means figuring out what pieces will make up your application, and then architecting an abstract model that describes how to represent, access, and relate data. To get started, navigate to your administrative setup.
You can quickly start building your app by using the “Add App” wizard on the Force.com Home screen in setup. This wizard will walk you through naming your app and creating your first object within the app. Objects are what allow you to store data in your Salesforce organization and are the overall definition of what information you are storing. If you are familiar with Excel, you might think about an object as a worksheet or a table. A field is a part of an object that holds a specific piece of information, such as a text or currency value, or can link related objects together.
After naming your app and your first object, the app wizard creates a few things automatically for you: a tab to access your object's associated data, a permission set to control visibility for users of your application, and a few default reporting components. The wizard gives you the opportunity to go straight to your app, but because your app will only consist of one custom object with no fields, consider staying in the setup and building out the rest of your data model first.
The first way to architect and build out your data model is by using the custom field wizard where you go through a sequential track of options to build out individual objects and fields. Navigate to your object by going to Setup -> Create -> Objects. Once you click into an object, Force.com takes you to it's object detail setup page, where you can add custom fields, custom buttons and links, and add other customizations around this specific object.
To use the custom field wizard, look for the "Custom Fields & Relationships" related list on the object detail setup page, and click "New". The wizard walks you through a few different steps of defining what kind of data your field is, whether or not it is already displayed in your app, and if it is visibile and editable to certain users by default. This article series covers the security and visibility aspects in a little bit. For now, the key takeaway to understand is that, while the custom field wizard requires a somewhat tedious process to create a field, it lets you control everything that you need to consider in the development cycle at the field creation level.
If you would like to see how the different objects related to one another, or are building out several objects at once and would like to deal with visibility and security later, the Schema Builder is a great tool for architecting and displaying your data model. The Schema Builder eliminates the need to click from page to page to find the details of various objects, fields, and relationships in your schema. It provides a drag-and-drop interface that enables you to create objects and fields, link objects together, and view some or all of the objects in your org and relationships among them.
If you are ever working inside your app on a detail page related to your custom object and would like to add fields or other customizations, you can use the quick access menu. The quick access menu is a toolbar, hidden off screen on the right hand side, and is a representation of your object detail setup page from outside of the administrative setup. You can use it to navigate to areas of the setup related to what you are trying to customize, or quickly add elements from inside your app. This productivity feature is ideal for quick additions and modifications to your org.
Note: To see and use the quick access menu (along with the Schema Builder or custom field wizard) you must have administrative privileges setup on your profile record in setup. A subsequent article in this series explains more about using profiles for security and permissions.
Building out your objects and fields is important because it paves the way for you to start entering data, which is stored as records. A record is a single instance of a Salesforce object, like a project or a task, and is a form for viewing and editing data in fields.
When you create an object, there are a few read-only fields automatically included that are populated on the creation of every record, like CreatedBy and CreatedDate. Standard fields such as Name and Id, a 15 or 18 digit case sensitive unique identifier, are also part of every record in Force.com. Beyond this, you need to create custom fields to extend objects with all of the necessary characteristics.
When creating a field, the first thing you need to consider is its data type. The data type of a field limits what kind of data you can store in that field. Some data types, like text or number, are simple and intuitive as to what kind of data they support. Others, like master-detail and formula, are a little more complicated. To understand how to use these kinds of data types, you first need to understand relationships in Salesforce.
When two objects are related in the database, they are linked together by a relationship field. This allows you to associate related information easily between objects. All relationships maintain some form of a parent-child relationship. This can be thought of as a hierarchical structure where one object looks up to the other, and as such, you only need to create one relationship field. You create a relationship field in the child object. In order to determine the parent, you need to consider which object is dependant on the other and how many records of both objects could possibly be related to each other in your data model.
There are two main buckets for categorizing potential relationships: either a one-to-many or many-to-many relationship. Both of these describe how many children can be associated to their related parent. The two fields available for creating these kinds of relationships in the database, lookup and master-detail, have unique characteristics regarding how they handle data deletion, record ownership, security, and required fields. When deciding between these two types of relationships, you need to think about which type of field will hold the kind of functionality you are looking for.
One-to-many means there is one parent record with the potential to be related to many child records. The first way to accomplish this would be to create a lookup field. A lookup field links two objects together, but has no effect on deletion or security. This means when you define a lookup relationship, data from the child object can appear as a custom related list on page layouts for the parent object; however, you are not required to populate the lookup field on creation of a child record. Conversely, if you delete the parent record, the child record will still exist, but the field referencing the deleted record by default will be cleared. As of Summer '12, a few lookup field enhancements have been added to allow for more granular control on response actions when handling deletions.
In the example below, we can see projects and team members. Team members can be a part of a project, but are not required to be a part of one. A project can have many team members, but a team member can only be a part of one project. Therefore, this type of relationship would be a lookup relationship.
The second way to create a one-to-many relationship is with a master-detail relationship field. This is when the master (parent) object controls certain behaviors of the detail (child) object. First, when a record of the master object is deleted, its related detail records are also deleted. Secondly, the Owner field on the detail object is not available and is automatically set to the owner of its associated master record. Third, the detail record inherits the sharing and security settings of its master record. The master-detail relationship field is required on creation of all child records.
In the picture below you can see to do items are linked to team members. To do items must always be related to a team member, and if the team member were deleted, their to do items would become irrelevant. Therefore, this relationship would be a master-detail relationship.
The many-to-many relationship is a bit more complicated. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. In this case, you need to create a junction object, which will create a unique link for every instance that you relate a parent object to a child. To build out a many-to-many relationship, create a custom junction object with two master-detail relationship fields linking to the objects you want to relate.
In the example below, we still have projects and team members with related to do items, but in this case team members can be a part of multiple projects. Projects can have several team members, and team members can be a part of several projects. Conversely, both objects are not required to be related. A team member can be a lone wolf and not participate in any projects, and a project does not need to have team members. Therefore, instead of having a lookup field linking projects and team members like the one-to-many case, we must build a junction object that will create a unique record for every instance where a team member joins a project. This junction, called project team member, is illustrated in the diagram below.
In order to ensure full understanding of the system you are building, architecting a complete data model with a solid understanding of the objects involved and how they are related is key. Creating this foundation will make it easier to build business logic on top of it later and design how you would like those objects to interact with each other when automating your processes as well.
You can get started with a couple different quick tutorials around creating a simple app and adding these some fields and relationships to them by following the links below. After you have a good understanding of how to build your foundation, you can start thinking about the data you expect to see in your system, create checks and balances to ensure the data entered falls within those expectations, and begin then populating your data.