Fields and Field Types.
Databases are made of up fields. You probably have some idea of what a field is, but to be precise, a field is container of data. To illustrate, there are five fields highlighted in red below.
Fields in Salesforce are always set up to contain a certain *type* of data. For example the Birthdate field below is a “date” type field, so you can only enter dates. The Email field below only allows email addresses.
This is part of a series of posts providing a basic introduction to what Salesforce is and how it can be useful to you and your nonprofit. Click here to see all of the posts in this series.
The idea of a field being able to contain only one kind of data is different from an excel or google spreadsheet – with those you can put any type of data in any cell. At first, having field "data types" may sound limiting, but they actually help everything work much better.
I’m going to explain some of the main “data types” for fields.
Checkbox Fields
A checkbox field is just what it sounds like. It’s either marked as checked or unchecked (i.e. “Yes” or “No”).
Picklist Fields
The “Favorite Color” field is not just a regular text field. It’s a drop-down field.
Salesforce calls these “picklist” fields. There is a predetermined list of options, and you can only choose one of them.
You can see below that the options for the “Favorite Color” field are Blue, Green, Orange, Red, Violet, and Yellow (and "Violet" is chosen, hence the checkmark next to it).
Picklist fields can be set up in two different ways: (1) users MUST choose from the predetermined list or (2) users CAN choose from predetermined options, but they could also input something else entirely if they wanted.
Multi-Select Picklist Fields
The “Desired Housing Size” field is similar to a picklist field but allows for multiple selections instead of just one. That’s why it’s called a “Multi-Select Picklist”.
You can choose all or none of the predetermined options. Unlike the picklist field, however, users will NEVER be able to input something not on the predetermined list of options.
Roll Up Fields
The “Total Monthly Income” field is not just a regular number field. It’s a “Roll Up” field, which means that the value in the field is automatically calculated based on related records.
In this example, the “Total Monthly Income” field is related to “Income” related records.
Let me go into further detail here, because this field type is a bit more complicated (and also extremely useful)!
This field is automatically calculating the total sum of all Income records that are related to Liam’s Contact (in this case, there are three income records). You can see these in the screenshot below. It shows the three income records with Monthly Amounts of $625, $400, and $90 (circled in red on the right side of the page) which when added together make $1,115.00, the amount shown in the “Total Monthly Income” field ( circled in red on the left side of the page).
Roll-up fields can sum related records (such as in this income example), and it can also do a few other types of calculations. They can find a count of related records. In the income example, it would be “3” since there are three related records.
Roll-up fields can also find the greatest and least in a set of related records. In this income example, the roll-up could also be programmed to display the greatest income amount (in this case, “$625”), or the least income amount (in this case “$90”).
Roll-up fields do calculations automatically – you don’t need to do anything to make them work once you've set them up.
Roll Up fields cannot be edited manually – they’re always calculated from the pre-determined related records. You cannot manually enter in “$50” or “$150” or any amount manually into the “Total Monthly Income” field.
Formula Fields
Formula fields are also calculations. The calculations are most often based on other fields on the record itself, rather than related records with roll-ups. Formula fields can also do much more advanced types of calculations than Roll Up fields do.
For example the “Age” field (highlighted in yellow) is a formula field that’s based off the Birthdate field (highlighted in green). You would enter the client’s birthdate and then the age is automatically calculated from there. It’s May 2022 when writing this, and Liam was born November 1979, so Liam is 52 years old.
Formula fields automatically update, so in May 2032 for example, Salesforce will show Liam as being 62 years old without a Salesforce user having to do anything. Formula fields are automatic.
This particular “Age” formula looks like this below.
Don’t worry about understanding what this means – I’m showing it just to illustrate that Formula Fields can be complex. Some of them are much longer and much more complex than this one, too.
IF(
NOT(ISBLANK(Birthdate)),
IF(
DATE(2000, MONTH(Birthdate), DAY(Birthdate)) <= DATE(2000, MONTH(TODAY()), DAY(TODAY())),
YEAR(Today()) - YEAR (Birthdate),
YEAR(Today()) - YEAR (Birthdate) -1
), null
)
This is just one example of a formula field. If you can imagine a calculation you’d like to do based on one or more fields, Salesforce can almost definitely do it.
Rich Text Fields
There are also “Rich Text” fields. These can contain many paragraphs of text, as well as pictures, formatting, bullet points, links to website, and more. Here’s an example below
We just covered Fields and Field Types. Next let’s look at more ways of ensuring that Salesforce users are entering in the most accurate and comprehensive data.
Required Fields and Validations
Required Fields
You can set fields to be required, and you'd do so for straightforward reasons: it's essential to have data in that field for each record. When a field is required, a user cannot save that record until that field is filled out.
Setting a field as required comes up in two different situations.
The first situation is when you set a field as required when there aren't any records yet.
The second is when you make a field required after records have been created. This means that there are records that may NOT have the required field filled in. In this case, if a user tries to edit one of these existing records, they won’t be allowed to save their changes until all the required fields are filled in first.
You’ll get this error below – whether creating a new record or editing an existing record that doesn't have the required field filled in.
The upside of required fields is you can ensure that important fields are always completed.
The downside of required fields is that if somebody doesn’t have the information to input into the field, they’re faced with two bad options. They either have to (1) enter inaccurate information or (2) not save the record. Both of these lead to inaccuracy, or what we call in the database biz, "bad data quality".
So required fields have to be used with a lot of forethought.
Luckily, Salesforce also has the option to create “Validation Rules” which is another method to ensure that data is entered correctly, but with more flexibility.
Validation Rules - Is Data Entered?
Let’s take an example in which we want to require Salesforce users to fill out the Social Security Number (SSN) field for anyone who is 65 or older. Maybe the nonprofit has a program for folks aged 65 and older in which their SSN is required for them to receive services. It’s therefore really important that we track their SSN. BUT we also don’t want to store SSNs for folks under 65 – we don’t have a use for it, and we don’t want to store highly sensitive data we don’t need.
But we can’t just make “SSN” required, because we don’t want the SSNs for those under 65, and requiring the SSN field means requiring it for all clients.
But we can fix this with a validation rule. We can create a validation rule using the same basic logic we just named: for all those 65 and over, require that the SSN field be filled out, and for those under 65 don’t require it (it can still be entered, just not required).
Let's see we just created this validation rule.
The below screenshot shows Liam, 52, and he does not have a SSN inputted. There’s no problem saving the record.
But if we tried to save the record for Inez, who is 72, we’re going to trigger the validation rule which will require us to fill in the SSN. We get this error below (we created the customized error message in red too).
That was an example of a validation rule ensuring we entered data into a field for specific clients.
Let’s look at one more example of a Validation rule – one that requires a specific *format* of inputted data.
Validation Rules - Is Data Entered in the Correct Way?
Let’s say that we want the SSNs to be inputted in the format of ###-##-#### (i.e. 123-45-6789 or 333-22-4444). We can ensure this format using validation rules.
Data entry errors are very common. Let’s say we were entering the SSN, but we forgot to input the last digit. Without the validation rule, we’d go on our merry way without realizing our mistake. Only later, when we no longer had access to the correct SSN, would we realize we're missing the last digit, and tracking it down would be much harder than having gotten it right the first time.
Thanks to a validation rule, however, if we try to save an incorrectly formatted SSN (we forgot to include the last digit in the SSN), it gives an error. Notice how the error message under the SSN field changed – it’s NOT telling us the SSN is required anymore (like the example above). It’s now telling us that the formatting of what we’ve entered is incorrect.
We have to enter the SSN in the exact format or we’ll get an error. The one does not have the dashes in the correct place, so it gives us an error.
The example below is almost correct but uses periods instead of dashes.
It allows us to save only when we enter the data with the correct format.
Validation rules are game changers for saving time and avoiding headaches.
Encrypted Fields
We can also choose to encrypt highly sensitive data. In the example below, we’ve also chosen to make SSN an encrypted field so that not everyone can easily see the entire number. Regular users will see the SSN as shown below with the first 5 digits Xed out – even if they just entered it.
Closing
Congrats! Fields are central to databases – after all, they are what hold the actual data – and you now have a working understanding of Fields and Field types, Required Fields and Validations, and Encrypted Fields.
Ready to chat about how field types, required fields, and validation rules can be a life-saver? Click below to book a free 15 minute consultation call with me today.