Data Model Specification
This section provides the blueprint for building out the data model. As you learn to use the Schema Builder (described in the subsequent section) or an equivalent tool, refer back to this section for the details of the objects, fields, and relationships needed for Services Manager.
The first five subsections cover the objects and their fields. Although relationships are displayed alongside fields in Force.com’s user interface, they are kept intentionally separate from the fields here. Instead, they are covered in the final subsection. It is easier to create relationships when all of the objects being related to each other already exist.
Contact
In the Services Manager application, a Contact record represents a consultant, an employee of the fictional professional services company. Contacts can also store information about a client of the services company. Contacts contain basic information, such as first and last name, email address, phone number, and mailing address. This is already captured by the standard Contact object. Contacts also have information specific to services delivery, such as primary skill, number of years of experience, education, and the hourly cost rate. The full list of custom fields to add to the Contact object is shown in Table 2.3.
Project
A project is a unit of work that the customer has contracted. It has financial attributes, such as the number of hours allocated for its completion, the expected revenue, and how billing is to be handled. It also has attributes for tracking its lifecycle, such as start and end date, status, stage, and notes. Table 2.4 contains the list of fields in the Project custom object.
Assignment
Projects are staffed with resources by the creation of assignments. Assignments associate a resource with a project for a specified period. Assignments contain a status, the role the resource is performing on the project, information about the hours billed and remaining, and expected and actual revenue. All Assignment fields are listed in Table 2.5.
Skill
To ensure that projects are staffed with qualified resources, the application must store information about the skills of each resource. A skill contains a name, type, and numeric rating of the competency level of the associated resource. Table 2.6 provides the list of fields in the Skill entity.
Timecard
As resources work on projects, they keep track of their time. The hours spent each day are logged to a timecard. Each timecard represents a week of work on the project. Multiplying the number of hours worked by the internal cost of the consultant produces a cost. You can find the full list of fields in the Timecard custom object in Table 2.7.
Summary of Data Relationships
Table 2.8 lists the data relationships in the Services Manager and the Force.com relationship types corresponding to them.
Figure 2.7 shows the same relationships in a diagram format.
The two Lookup relationships in the Services Manager are between Account and Project, and Timecard and Assignment. They are Lookup relationships because they are optional. An Account does not require a Project, and a Project does not require an Account. An Assignment does not require a Timecard.
The remainder of the relationships are Master-Detail. In all of them, the child record requires a parent record. For example, Timecard records cannot exist without a corresponding Contact and Project. For mandatory relationships like this, Master-Detail is a good starting point because referential integrity is enforced. If a Project record is deleted, all child Timecard records are also deleted.
You might wonder why Contact and Skill are not a many-to-many relationship. It would be the more normalized way to go. But with the simpler, single Master-Detail relationship, the only repeated field is Skill Type. You can use a picklist field to keep users working from the same list of valid skills and a validation rule to increase data integrity. If Skill had a larger set of its own attributes and they could not be expressed as picklists, it would be a good candidate for a many-to-many relationship.
You should be aware of the following limitations of Master-Detail relationships:
Force.com supports a maximum of four levels of cascading Master-Detail relationships. So a child object in a Master-Detail relationship can be the parent of another Master-Detail relationship, and so on. The four-level limit in genealogical terms means that a child can have a great-grandparent object but not a great-great-grandparent. The canonical example of cascading Master-Detail is the purchase order: A purchase order contains one or more line items, and each line item contains one or more line item details.
A single object cannot be the child in more than two Master-Detail relationships. When an object is the child of two Master-Detail relationships, that object is referred to as a junction object. It joins two parent objects in a many-to-many relationship. In the Services Manager data model, Assignment and Timecard are junction objects.
In Force.com as in any technology, there are many ways to do the same things, some better than others. Given this first cut of the Services Manager data model, these restrictions on Master-Detail do not seem to be a problem. Incidentally, all the reasons that Master-Detail relationships were chosen can be also satisfied using Lookup fields in conjunction with other Force.com features, to be discussed in later chapters.