Full Implementation

After you get the basic implementation into a working state, move on to the more challenging requirements: the complete list of skill types and data security.

To get the complete list of types, use the metadata methods to query the values of the Skill__c.Type__c picklist. Iterate over the values, checking for the presence of corresponding Skill records for the contact. Create Skill records where they are missing.

For data security, you cannot rely on built-in Force.com record-level security alone. It operates on the OwnerId field, the unique identifier of the user who has ownership rights to a record. In the Skills Matrix, ownership of a contact record does not determine who is allowed to edit or view its skills. An administrator might import contact data from a legacy system, or a user in human resources might be the owner of the contact.

The assumption is that every consultant and other user of the Services Manager application has a license to log in to Force.com as an independent user with his own credentials. Each full user license carries with it a unique record in the standard User object. This user identity can be correlated to the contact record to determine at runtime the behavior of the Skills Matrix. To create this correlation, add a lookup field to the Contact object called User, setting its parent to the standard User object. For each contact record, provide a value of the new User field. This lookup of the User from Contact can drive the decision of the controller to make a set of skills editable or not.

When you’re done with the implementation, test it against the three user scenarios: privileged user, consultant editing his or her own skills, and consultant viewing the skills of another consultant.