Data Model Design Goals
At a high level, the purpose of the Services Manager sample application is to staff consultants on customer projects based on their skills, and bill the customers for the consultants’ time. This means the Force.com data model must store and manage information about the consultants, customers, projects, staffing assignments of consultants to projects, time spent on projects, and the skills of the consultants. This data model forms the foundation of the Services Manager sample application, implemented piecewise throughout this book, designed to illustrate features of the Force.com platform.
Two other, more tactical goals are described in the subsections to follow.
Optimized for Force.com Developer Edition
A guiding principle of this book is to focus on features available in the free, Developer Edition of the Force.com platform. Although it is possible to build a more realistic version of the Services Manager, one that could form the basis of a production application, it is likely to introduce dependencies on a premium version of the platform. The most notable example of a design decision that impacts licensing cost is user authentication, and it is worth discussing in depth.
In a real-world implementation, each consultant in the Services Manager would be its own user (a record in the standard object named User). This would enable that consultant to log in and view only the information he or she has access to. This granular user identity, authentication, and data access control (covered in Chapter 3) is one of the most valuable features of the Force.com platform, so naturally it is not free for unlimited use. Salesforce charges per user for its product.
Rather than using the standard User object and being subject to license restrictions, the Services Manager implementation is designed around the Contact object. There is no relevant limit on the number of free Contact records, and they are easy to create, with no passwords or activation codes required.
If you have a premium Force.com organization and would like to experiment with the User object, it is a simple migration path from the Contact object. Create a Lookup field on the User object, referring to the Contact object. That way, you can always restrict the Contact to the corresponding User who is currently logged in to Salesforce.
Leverage Standard Objects
There are many advantages to using standard objects wherever possible. They are shared by Salesforce’s CRM applications such as Service Cloud and Sales Cloud, so there are many special features built in to the platform that you can benefit from. Also, if you plan to build or install other applications in your Force.com environment, they likely also leverage these objects. It’s much simpler for applications to interoperate and coexist when they share the same core data objects.
The Services Manager tracks data about consultants and the companies that hire them. This is an excellent fit for the standard objects Contact and Account, respectively. They contain many standard fields for such things as name, addresses, phone numbers, and email address, which can be customized to meet the needs of any application. If the standard fields are not sufficient, you can also add custom fields, the same types of fields you add to custom objects.