Force.com Fundamentals - Learn How the Cloud Makes Developing Apps 5x Faster

In the last chapter, we got our Recruiting app off to a quick start by defining the Position custom object, tab, and several simple fields. This simple version of our app had the same look and feel as any other page in the Force.com, and we were able to whip it together in a matter of minutes.

In this chapter, we're going to enhance the Positions tab: first by defining a few more advanced fields, then by defining a validation rule to make sure our data stays clean, and finally by moving our fields around within a page layout. These additions will help change the detail page of our Positions tab from a somewhat flat and inelegant user interface to something that users find powerful and intuitive to use. Let's get started!

Learn how the cloud makes developing faster. Get the FREE Force.com Fundamentals book. (A $39.99 value).

Adding Advanced Fields

In this section, let's revisit the custom field wizard to help us create fields with more sophisticated functionality: picklists, dependent picklists, and fields that leverage custom formulas. We'll see how the platform's user interface helps guide us through the setup of these more complicated fields.

Introducing Picklists

When viewing the preview of what we wanted our Positions page to ultimately look like, there were several fields that were specified with drop-down lists. In Force.com terms, these fields are called picklists, and they consist of several predefined options from which a user can select.

Picklists come in two flavors: a standard picklist, in which a user can select only one option, and a multi-select picklist, in which a user can select multiple options at a time. For the purposes of our Position object, we need to define standard picklists for a position's location, status, type of job, functional area, and job level.

Location Picklist Field

Try It Out: Adding Picklists

Let's walk through the creation of the Location picklist field. Then, as in the previous chapter, we'll give you the information that you need to create the others on your own.

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Custom Fields & Relationships related list, click New.
4. Select the Picklist data type and click Next.
5. In the Field Label text box, enter Location.
6. In the large text area box just below, enter the following picklist values, each on its own line:
   • San Francisco, CA
   • Austin, TX
   • Boulder, CO
   • London, England
   • New York, NY
   • Mumbai, India
   • Sydney, Australia
   • Tokyo, Japan
7. Select the Use first value as default value checkbox.

This option allows us to populate the field with a default value. If you leave it deselected, the field defaults to None on all new position records. Otherwise the field defaults to the first value that you specify in the list of possible picklist values. Because most positions at Universal Containers are based at its headquarters in San Francisco, CA, this should be the default.

1. Accept all other default settings for field-level security and page layouts.
2. Click Save & New.

Easy! Now specify the remaining picklists according to the table below:

Data Type	Field Label	Picklist Values	Sort Alphabetically?	Use First Value as Default?
Picklist	Status	New Position Pending Approval Open - Approved Closed - Filled Closed - Not Approved Closed - Canceled	No	Yes
Picklist	Type	Full Time Part Time Internship Contractor	No	No
Picklist	Functional Area	Finance Human Resources Information Technology Retail Operations Warehousing Miscellaneous	Yes	No
Picklist	Job Level	FN-100 FN-200 FN-300 FN-400 HR-100 HR-200 HR-300 HR-400 IT-100 IT-200 IT-300 IT-400 RO-100 RO-200 RO-300 RO-400 WH-100 WH-200 WH-300 WH-400 MC-100 MC-200 MC-300 MC-400

Introducing Field Dependencies

Now that we've made all those picklists, answer this question: How many times have you clicked on a drop-down list and found far too many values to choose from? For example, maybe you were selecting Uruguay from a list of countries, and every country in the world was on the list. That meant that you had to scroll all the way down to the countries that started with the letter U. What a pain!

Fortunately, the folks who built the Force.com have encountered that situation a few times themselves, and as a result, they've given us a tool to help us avoid this problem with our own picklist fields: field dependencies.

Field dependencies are filters that allow us to change the contents of a picklist based on the value of another field. For example, rather than displaying every value for Country in a single picklist, we can limit the values that are displayed based on a value for another field, like Continent. That way our users can find the appropriate country more quickly and easily.

Picklist fields can be either controlling or dependent fields. A controlling field controls the available values in one or more corresponding dependent fields. A dependent field displays values based on the value selected in its corresponding controlling field. In the previous example, the Continent picklist is the controlling field, while the Country picklist is the dependent field.

Try It Out: Creating a Dependent Picklist

Looking at the picklists that we've created, it's quickly obvious that our users might get frustrated with the length of our Job Level picklist. Let's make our users happy by turning Job Level into a dependent field of the Functional Area picklist. Doing this will allow users to see only the four relevant job level values when a department is selected in the Functional Area picklist:

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Custom Fields & Relationships related list, click Field Dependencies.
4. Click New.
5. For the Controlling Field drop-down list, choose Functional Area.
6. For the Dependent Field drop-down list, choose Job Level.
7. Click Continue.

A field dependency matrix displays with all the values in the controlling field across the top header row and the dependent field values listed in the columns below. For each possible value of the controlling field, we need to include the values that should be displayed in the dependent picklist when that controlling value is selected. In the field dependency matrix, yellow highlighting shows which dependent field values are included in the picklist for a particular controlling field value.

Field Dependency Matrix

To include a dependent field value, you simply double-click it. To exclude a dependent value from the list, double-click it again.

For example, let's try it out by including the values that should be displayed in the Job Level picklist whenever Finance is selected in the Functional Area picklist:

1. In the column labeled Finance, double-click FN-100, FN-200, FN-300, and FN-400.

Those four fields should now be shaded yellow in the Finance column.

Instead of double-clicking every Job Level value, we can also use SHIFT+click to select a range of values or CTRL+click to select multiple values at once. Once those values are highlighted in blue, we can click Include Values to include them, or Exclude Values to remove them. Let's try it out.

1. In the column labeled Human Resources, single-click HR-100 and then press and hold the SHIFT key while clicking HR-400.
2. Click Include Values.

Now we have values selected for both the Finance and Human Resources columns!

1. Continue highlighting the appropriate values for all of the remaining columns, as described in the following table.

Tip	To get to all of the values that you need to modify for this step, you'll need to click Previous or Next to see additional columns.

Functional Area (Controlling picklist field)	Job Level (Dependent picklist field)
Finance	FN-100 FN-200 FN-300 FN-400
Human Resources	HR-100 HR-200 HR-300 HR-400
Information Technology	IT-100 IT-200 IT-300 IT-400
Retail Operations	RO-100 RO-200 RO-300 RO-400
Warehousing	WH-100 WH-200 WH-300 WH-400
Miscellaneous	MC-100 MC-200 MC-300 MC-400

1. Click Preview to test the results in a small popup window.
2. Click Save.

Look at What We've Done

Now that we've created all those picklists, let's revisit the Positions tab to see what we have so far.

1. Go to the Positions tab.
2. Click New.
3. In the Functional Area picklist, select Finance.
4. Open the Job Level picklist.

Dependent Picklist Fields

Our Recruiting app users are going to be very happy that they no longer have to deal with a long, onerous picklist. Now let's go add a field that's even more powerful and complex than a dependent picklist: a custom formula field.

Introducing Custom Formula Fields

Up to this point, the fields that we've defined have all had one thing in common—they each require a user to give them a value. Fields like that are very helpful for storing and retrieving data, but wouldn't it be great if we could somehow define a "smart" field? That is, what if we could define a field that looked at information that was already entered into the system and then told us something new about it?

Fortunately, custom formula fields give us the ability to do just that. Just as you can use a spreadsheet program like Microsoft Excel to define calculations and metrics specific to your business, we can use custom formula fields to define calculations and metrics that are specific to our Recruiting app.

For example, on our Position object, we've already created fields for minimum pay and maximum pay. If Universal Containers gives out yearly bonuses based on salary, we could create a custom formula field that automatically calculated the average bonus that someone hired to that position might receive.

How would we perform this calculation if we were using a spreadsheet? The columns in our spreadsheet would represent the fields that we defined on our Position object, and each row of the spreadsheet would represent a different position record. To create a calculation, we'd enter a formula in a new column that averages the values of Min Pay and Max Pay in a single row and then multiplies it by a standard bonus percentage. We could then determine the average bonus for every position record row in our spreadsheet.

Custom formulas work in a very similar way. Think of a custom formula like a spreadsheet formula that can reference other values in the same data record, perform calculations on them, and return a result. However, instead of using cell references, you use merge field references. And, instead of typing characters in a box, you have a wizard to help you select fields, operators, and functions.

The net result is that anyone can quickly and easily learn to create formula fields. And, as with all platform tools, the cloud computing delivery model makes it easy to experiment. You can create a formula, view the results, and change the formula again and again, as many times as you want! Your underlying data is never affected.

Tip	When defining your own custom formula fields, leverage the work of others. You can find more than a hundred sample formulas on the Salesforce.com Community website at http://blogs.salesforce.com/features/2006/03/custom_formula_.html.

Calculating How Long a Position Has Been Open

Let's now think about another custom formula field that we could create for our Position object—a custom formula field that calculates how many days a position has been open. To do this, let's first think about the logic that we should use to define the field, and then we can go through the process of creating it in our Recruiting app.

Let's think about the data that we need to make this calculation: we need to know the current date and the date that the position was created. If we could somehow subtract these two, we'd have the number of days that the position has been open. Fortunately, it's easy to get both of these values:

• For the current date, we can simply use the platform's built-in TODAY() function. TODAY() returns today's date.
• For the date that the position was opened, we can use the Open Date field that we defined in the last chapter. Because we're using it in a custom field, we'll refer to it by its internal name, Open_Date__c.

Now that we have our two dates, we want to subtract them: TODAY() - Open_Date__c. Even if the two dates span different months or years, the platform is sophisticated enough to know how to handle all the intricacies of such a calculation behind the scenes. We just have to provide the dates, and the platform can do all the rest.

So far so good, but one problem still remains—what if the position has already closed? Our formula only works if we assume the position is still open. Once it closes, however, the value of our current formula will keep incrementing every day as TODAY() gets farther and farther away from the original Open Date. If we can, we want to use the Close Date field in the formula instead of TODAY() after a position closes. How can we do this?

Once again, all we need to do is dip into the extensive library of platform functions. The IF() function allows us to perform a test and then return different values depending on whether the result of the test is true or false. The IF() function's syntax looks like this:

IF(logical_test,
          value_if_true,
          value_if_false)

For the logical_test portion, we'll test whether the Close Date field has a value—if it does, the position obviously must be closed. We'll test for this with a third built-in function: ISNULL(). ISNULL() takes a single field and returns true if it does not contain a value and false if it does. So now our formula looks like this:

IF( ISNULL( Close_Date__c ) ,
           value_if_true,
           value_if_false)

By replacing value_if_true and value_if_false with the other formulas we talked about, we've now figured out our whole formula:

IF( ISNULL( Close_Date__c ) ,
             TODAY()  -  Open_Date__c ,
             Close_Date__c  -  Open_Date__c )

Great! Our formula calculates the number of days a position has been open, regardless of whether it's currently open or closed. Now, let's go define a field for it on our Position object.

Try It Out: Defining a "Days Open" Custom Formula Field

We'll begin building the formula field the same way we created our other custom fields.

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Custom Fields & Relationships related list, click New.
4. Select the Formula data type, and click Next.

Step 2 of the New Custom Field wizard appears.

Custom Formula Field Wizard Step 2

1. In the Field Label field, enter Days Open.
2. Select the Number formula return type.

In this case, even though we're subtracting Date fields, we want to end up with just a regular numeric value.

1. Change the Decimal Places value to 0, and click Next.

Now it's time to enter the details of our formula.

1. Click the Advanced Formula tab, as shown in the following screenshot.

Custom Formula Field Editor

We want to use the Advanced Formula tab so we can access the platform's built-in functions through the Functions list on the right side.

1. From the Functions list, double-click IF.

Our formula now looks like this:

IF(logical_test, value_if_true, value_if_false)

Let's go ahead and define the logical test:

1. Delete logical_test from the formula, but leave your cursor there.
2. From the Functions list, double-click ISNULL.
3. Delete expression from the ISNULL function you just inserted, but leave your cursor there.
4. Click the Insert Field button. Two columns appear in an overlay.
5. In the left column, select Position.
6. In the right column, select Close Date.
7. Click Insert.

Did you notice that you didn't have to remember to use the internal name of the Close Date field? The platform remembered for you when it inserted the value. Our formula now looks like this:

IF( ISNULL( Close_Date__c ) , value_if_true, value_if_false)

Now, let's specify the value if our logical test evaluates to true:

1. Delete value_if_true from the formula, but leave your cursor there.
2. Press Enter on your keyboard, and space over 10 spaces.

Adding the carriage return and spaces makes our formula more legible for others.

1. From the Functions list, double-click TODAY.
2. Click the Insert Operator button and choose Subtract.
3. Click the Insert Field button.
4. In the left column, select Position.
5. In the right column, select Open Date.
6. Click Insert.

We're getting closer—our formula now looks like this:

IF( ISNULL( Close_Date__c ) ,
          TODAY()  -  Open_Date__c , value_if_false) 

Finally, let's specify the value if our logical test evaluates to false:

1. Delete value_if_false from the formula, but leave your cursor there.
2. Press Enter on your keyboard, and space over 10 spaces.
3. Click the Insert Field button.
4. In the left column, select Position.
5. In the right column, select Close Date and click Insert.
6. Click Insert Operator and choose Subtract.
7. Click the Insert Field button.
8. In the left column, select Position.
9. In the right column, select Open Date and click Insert.

Our formula now matches our original:

IF( ISNULL( Close_Date__c ) ,
          TODAY()  -  Open_Date__c ,
          Close_Date__c  -  Open_Date__c )

Now that we've gone through those steps of the procedure, note that we could have just typed in the formula that we figured out in the last section. However, using the formula editor is a lot easier because you don't have to remember function syntax or internal names of fields and objects. Let's keep going and finish up this field:

1. Click Check Syntax to check your formula for errors.
2. In the Description text box, enter The number of days a position has been (or was) open.
3. Add an optional Help Text description if you wish.
4. Select Treat blank fields as blanks, and click Next.
5. Accept all remaining field-level security and page layout defaults.
6. Click Save.

Try It Out: Giving Fields Dynamic Default Values

We can also use custom formulas to give our fields dynamic default values. While some fields like the Travel Required checkbox or the Job Location picklist have default values that apply in every situation, there are other fields with defaults that can't be so easily defined. For example, at Universal Containers, recruiters are generally expected to fill a position within 90 days of it being opened. While we can't choose a single date that will always be 90 days after a position is opened, we can define a custom formula that takes the date the position is created and adds 90 days. The platform allows us to specify this formula as the Hire By field's default value:

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Custom Fields & Relationships related list, click Edit next to the Hire By field.
4. Next to the Default Value text box, click Show Formula Editor.

Look familiar? This is similar to the editor that we used to define our Days Open custom formula field.

1. From the Functions list, double-click TODAY.
2. Click the Insert Operator button, and choose Add.
3. Type 90.

Your default value formula should be:

TODAY() + 90

1. Click Save.

It's that easy! Now to wrap up the fields on our Positions tab, let's set the default value of the Open Date field to the day that the record is created. To do this, follow these steps again, but use TODAY() as the Default Value.

Look at What We've Done

Let's revisit the Positions tab to take a look at what we've just done.

1. Click the Positions tab.
2. Click New.

Our Days Open formula field doesn't show up on our Position edit page—that's because it's a formula field and doesn't require any user input to display. However, we can see that our Open Date and Hire By fields already have default values: Open Date should be today's date, and Hire By is 90 days later. We can change these values if we want, or we can just leave them as they are.

In order to see our Days Open field, we'll have to define our first position record. Let's do that now.

1. Enter any values you want to define a new position. At the very least, you must enter a value for the required Position Title field.
2. Click Save.

The new position is now displayed in its own record detail page. At the bottom of the page, notice our Days Open formula field, just above the Created By field. It should show 0, since we just created the position. If you want to see the value change, edit the record and set the Open Date to a week earlier. Isn't that neat?

Introducing Validation Rules

Now that we've defined all the fields that we want on our Position object, let's see if we can articulate a couple of rules about the data that should be entered into those fields. Even though the recruiters and hiring managers at Universal Containers are bright people, everyone sometimes makes mistakes when filling out a form, and a good app should catch the obvious errors.

For example, does it ever make sense for the value of the Min Pay field to be more than the value of the Max Pay field? Or should Close Date ever be unspecified if the Status field is set to Closed - Filled or Closed - Not Approved? Clearly not. We can catch these sorts of errors in our app with yet another built-in feature of the platform: validation rules.

Validation rules verify that the data a user enters in your app meets the standards that you specify. If it doesn't, the validation rule prevents the record from being saved, and the user sees an error message that you define either next to the problematic field or at the top of the edit page. Let's build a couple of validation rules now for our Recruiting app.

Note	You can find dozens of sample validation rules on the Salesforce.com Community website at http://blogs.salesforce.com/features/2006/12/data_validation.html.

Try It Out: Defining a Validation Rule for Min and Max Pay

For our first validation rule, let's start off simple: Min Pay should never be greater than Max Pay:

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Validation Rules related list, click New.

Validation Rule Edit Page

1. In the Rule Name text box, enter Min_Pay_Rule.

The name of a validation rule can't include any spaces, but if you forget, the platform helpfully changes them to underscores (_) for you.

1. Select the Active checkbox.

This checkbox specifies whether the validation rule should start working as soon as it's saved. Because this rule is pretty straightforward (and because we want to test it later!), it makes sense to turn it on right away.

1. In the Description text box, enter Min Pay should never exceed Max Pay.

>Now it's time to define the meat of our validation rule: the error condition. If you have a sense of déjà vu when looking at the Error Condition Formula area of the page, don't be alarmed! Just like formula fields and default field values, a validation rule can leverage a number of built-in operators and functions to define a true-or-false error condition that determines whether data is valid. When this condition evaluates to true, an error message displays and the record can't be saved.

We want our error condition to be true whenever Min Pay is greater than Max Pay, so let's use our formula editor to specify that now:

1. Click the Insert Field button. Just like in the formula field editor, two columns appear in an overlay.
2. In the left columns, select Position.
3. In the right columns, select Min Pay.
4. Click Insert.
5. Click the Insert Operator button, and choose Greater Than.
6. Click the Insert Field button once again.
7. In the left column, select Position.
8. In the right column, select Max Pay.
9. Click Insert.

You should now have an error condition formula that looks like this:

Min_Pay__c  >  Max_Pay__c

Now the only thing that remains is to specify the error message when our error condition evaluates to true.

1. In the Error Message text box, enter Min Pay cannot exceed Max Pay.
2. Next to the Error Location field, select the Field radio button, and then choose Min Pay from the drop-down list.

Tip	Because our rule only requires a user to correct one field, our error message is displayed next to that field. If a rule requires a user to update multiple fields, it's more appropriate to place the error message at the top of the page.

1. Click Save.

Easy! Now that we've familiarized ourselves with a simple validation rule, let's define one that's a little trickier.

Try It Out: Defining a Validation Rule for Close Date

For our next validation rule, let's ensure that Close Date has a value whenever the Status field is set to Closed - Filled or Closed - Not Approved.

The hardest part of this validation rule is defining the error condition formula. When defining a condition like this, it's sometimes easiest to think about it in logical terms first, and then translate that logic to the functions and operators that are provided in the formula editor. In this case, our error condition is true whenever:

Close Date is Not Specified
 
AND
 
(Status is "Closed - Filled" OR
           "Closed - Not Approved")

Let's start with the first piece: "Close Date is Not Specified." To translate this into terms the formula editor understands, we'll need to use the ISNULL() function again. As you might remember from defining the Days Open custom formula field, ISNULL() takes a single field or expression and returns true if it doesn't contain a value. So, remembering that we have to use the internal field name of the Close Date field in our formula, Close Date is Not Specified translates to:

ISNULL( CloseDate__c )

Next, let's figure out how to translate "Status is 'Closed - Filled'." To test for picklist values, we'll need to use another function: ISPICKVAL(). ISPICKVAL() takes a picklist field name and value, and returns true whenever that value is selected. So "Status is 'Closed - Filled'" translates to:

ISPICKVAL( Status__c , "Closed - Filled")

Now we just have to combine these translations with the functions for AND() and OR(). Both of them take an unlimited number of expressions, and 'AND' or 'OR' them all, respectively. For example:

AND ( exp1, exp2, exp3)

returns true when exp1, exp2, and exp3 are all true. Likewise,

OR ( exp1, exp2, exp3)

returns true when any one of exp1, exp2, or exp3 are true.

Put these functions all together with our other expression translations, and we get our completed error condition formula:

AND (
    ISNULL(  CloseDate__c ),
    OR (
         ISPICKVAL(  Status__c , "Closed - Filled"),
         ISPICKVAL(  Status__c , "Closed - Not Approved"))
)

Phew! Now we can quickly define our second validation rule using this formula:

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Validation Rules related list, click New.
4. In the Rule Name text box, enter Close_Date_Rule.
5. Select the Active checkbox.
6. In the Description text box, enter Close Date must be specified when Status is set to 'Closed - Filled' or 'Closed - Not Approved.'
7. In the Error Condition Formula area, enter the following formula:

   AND (
       ISNULL(  Close_Date__c ),
       OR (
            ISPICKVAL(  Status__c , "Closed - Filled"),
            ISPICKVAL(  Status__c , "Closed - Not Approved"))
   )

8. Click Check Syntax to make sure you didn't make a mistake.
9. In the Error Message text box, enter Close Date must be specified when Status is set to 'Closed.'
10. Next to the Error Location field, select the Field radio button, and then choose Close Date from the drop-down list.
11. Click Save.

Look at What We've Done

Let's revisit the Positions tab to test the validation rules that we've just made.

1. Click the Positions tab.
2. Click New.

First let's try defining a new position with a value for Min Pay that's larger than Max Pay.

1. Specify any value for the required Position Title field.
2. In the Min Pay field, enter 80,000.
3. In the Max Pay field, enter 40,000.
4. Click Save.

Did you see what happened? An error message popped up that looked exactly like any other error message in the app!

Error Message from a Validation Rule

Now let's test our other validation rule:

1. In the Min Pay field, enter 40,000.
2. In the Max Pay field, enter 80,000.
3. From the Status drop-down list, choose Closed - Not Approved.
4. Click Save.

Our second validation rule is triggered, this time because we didn't specify a value for Close Date. Once we do, the record saves normally.

The Positions tab is now fully functional, with a couple of validation rules to ensure that users don't make certain mistakes. But are the fields where we want them? Are the fields that must have values marked as required? In the next section, we'll fine-tune our Position custom object by modifying its page layout.

Introducing Page Layouts

After defining all those fields and validation rules, we now have a fully functional Position custom object. However, it doesn't look all that nice—all of the long text areas appear at the top, and it's hard to scan. Let's move some things around to make this page easier for our users. We can do that by customizing the Position object's page layout.

A page layout controls the position and organization of the fields and related lists that are visible to users when viewing a record. Page layouts also help us control the visibility and editability of the fields on a record. We can set fields as read-only or hidden, and we can also control which fields require users to enter a value and which don't.

Page layouts are powerful tools for creating a good experience for our users, but it's crucial that we remember one important rule: page layouts should never be used to restrict access to sensitive data that a user shouldn't view or edit. Although we can hide a field from a page layout, users can still access that field through other parts of the app, such as in reports or via the API. (We'll learn more about security that covers all parts of the app in Securing and Sharing Data.)

Now let's see if we can organize the fields on our Position object in a way that's more user friendly.

Becoming Familiar with the Page Layout Edit Page

First let's take a look at the Page Layout edit page:

1. Click Setup | Create | Objects.
2. Click Position.
3. In the Page Layouts related list, click Edit next to the Position Layout.

Welcome to the Page Layout edit page! As you can see, this editor is different from the ones that we've already used in other areas of the platform. That's because we're designing a user interface and need to see a representation of how our page will look as we're working. Before going any further, let's give ourselves a quick orientation to how this page is set up.

Page Layout Edit Page

On the left side of this page we can see a representation of what our page currently looks like. After an initial set of buttons, the Information section shows all of the fields we've created, plus an additional field for Owner that's in its own column. Below it is another section for System Information, then Custom Links, and finally, Related Lists.

As we scroll down to view the entire page, the boxes on the right side move with us so that they're always visible. These boxes include a legend for all of the icons we see on the left, plus a list of all of the Position fields, related lists, and other components that are available to put on our layout. Currently all of the fields in the box on the right are grayed out—that's because they've all been placed on our page layout by default. If we were to move one of the fields that's in the layout to the left back to the Position fields box on the right, that field would effectively be removed from the layout, and its name would no longer be grayed out.

Now that we know what we're looking at, let's rearrange the fields in the way a user might want to see them.

Try It Out: Grouping Fields into a New Section

If we didn't want a user to see the Min Pay field at all, we could simply drag it off the layout and onto the Position Fields box on the right side.

Warning	Don't forget our earlier warning! Page layouts should never be used to restrict access to sensitive data that a user shouldn't view or edit. That's because page layouts control only a record's edit and detail pages; they don't control access to fields in any other part of the platform.

1. Select the Required checkbox, and click OK.
2. Repeat these steps for the Max Pay field.
3. Click Save to finish customizing the page layout.

Hooray! We're all done with our Position object's page layout.

Look at What We've Done

Congratulations. We've just built ourselves a simple Recruiting app that tracks details about an organization's open positions. Let's check out what we've done by revisiting the Positions tab and clicking New. Because of the changes that we've made in our page layout, our Position edit page should now look like this:

Final Version of the Position Edit Page

We have an object with a tab, we've added custom fields, and we've arranged them in a page layout. We've finished our simple app, and now we're well on our way to creating the more complex Recruiting app that we described earlier.

Things are going to get even more interesting in the next chapter. We'll add a few more custom objects to track things like candidates, job applications, and reviews, and then we'll enhance our Recruiting app even further by defining how our objects relate to one another. Before you know it, we're going to have an incredibly powerful tool, all implemented with a few clicks in the platform.

Learn how the cloud makes developing faster. Get the FREE Force.com Fundamentals book. (A $39.99 value).