Learn 2 Salesforce
Round 2 – Saving & Automation
Outline
 What records on a field are editable
 What happens when I hit save?
 Record validation
 Automated tasks
 Record commit to database
 Rolling back records
 Event Chaining
 Remember, I’m teaching you to think like admins. You
might think some of this is useless, but trust me it’s not.
But First!
 Do you remember anything we talked about last time?
Answer the following. Raise your hand if you think you
can answer one of them.
 1) What is null?
 2) Give me an example of a table in our org
 3) What is a primary key/lookup?
 4) Are columns/fields frequently modified?
 5) Give an example of a Salesforce field data type
 6) What is the difference between a formula field and a
rollup field?
 7) All tables without exception should have an ID field.
True or false?
 8) Name the 3 inter table relationship types. (x-to-x)
Answers
 1) What is null?
 Nothing. Not 0, not a space, just nothing. A void. A hole.
 2) Give me an example of a table in our org
 Contact,Account,Respondent,Payment,Check,Project
 3) What is a primary key/lookup?
 An indication of a relationship to another table.
 4) Are columns/fields frequently modified?
 No. Generally just during setup.
 5) Give an example of a Salesforce field data type
 Date,Number,Text,AutoNumber,Currency,Email,URL
 6) What is the difference between a formula field and
a rollup field?
 Formula uses data from current object and parents, rollups
summarize data from child records.
 7) All tables without exception should have an ID
field. True or false?
 True
 8) Name the 3 inter table relationship types. (x-to-x)
 One-to-One, One-to-Many, Many-to-Many
Alright, Nice Job.
 Seriously, if you knew most of those you are doing well.
If you didn’t, well pay attention and ask any questions
you have right now.
Editing a Record
 In this case we are using the word edit to mean entering
information for a new record, or modifying an existing
one.
 Nothing is saved to the database until the system has
verified correctness of all data, and all configured
automated tasks have been executed.
 Have you ever asked how the system knows what fields
to show you, and which ones it hides? Where do those
fields even come from? How does it know if it’s a picklist
or a date field? This is all controlled by what is called
metadata.
Metadata
 Metadata is simply defined as data about data. If you
had a paper report metadata about it might be number
of words in the report, the date it was written, weight,
number of pages etc.
 Salesforce maintains metadata on all objects and fields.
This information contains all the information that
Salesforce needs to create the user interface (edit
screens, etc). All field metadata for an object is stored in
a file that has the same name as the object.
 Metadata contains the definitions of fields like type,
maximum length, and everything that is needed to
understand a field and create one. In this case the
metadata is like a schematic for building objects/fields
Metadata structure - Example

<fields>

<fullName>Peachtree_ID__c</fullName>

<caseSensitive>false</caseSensitive>

<description>What is the peachtree id of this account?</description>

<externalId>false</externalId>

<inlineHelpText>What is the peachtree id of this account?</inlineHelpText>

<label>Peachtree ID</label>

<length>16</length>

<required>false</required>

<trackFeedHistory>false</trackFeedHistory>

<type>Text</type>

<unique>true</unique>

</fields>
Creates:
So What? Why do I know about
metadata now?
 Did a little light bulb just kick on? When you tell
Salesforce you want to create a contact, it goes and
finds the metadata for the contact object, finds all the
fields defined within, loops over the content and uses
the information to create the edit screen.
 All the informaton Salesforce needs to create all the
fields is right there in that metadata. When you create
your objects and fields, you modify the database, AND
update the metadata at the same time (but you don’t
see that latter part).
Saving the edited record
 So now that the user has been presented a screen with
all the fields defined in the metadata and they filled it
out and clicked save, now what?
 That data has to get saved to the database. Right now
all that glorious information they entered only exists on
their computer. Many things happen before that data
actually makes it into the database.
Steps in Saving a Record

Required values at the layout level and field-definition level

Executes all before triggers.

Runs most system validation steps again, such as verifying that all required fields have a
non-null value, and runs any user-defined validation rules. The only system validation
that Salesforce doesn't run a second time (when the request comes from a standard UI edit
page) is the enforcement of layout-specific rules.

Saves the record to the database, but doesn't commit yet.

Executes all after triggers.

Executes assignment rules.

Executes auto-response rules.

Executes workflow rules.

If there are workflow field updates, updates the record again.

Executes escalation rules.

If the record contains a roll-up summary field or is part of a cross-object workflow, performs
calculations and updates the roll-up summary field in the parent record. Parent record goes
through save procedure.

If the parent record is updated, and a grand-parent record contains a roll-up summary field
or is part of a cross-object workflow, performs calculations and updates the roll-up summary
field in the parent record. Grand-parent record goes through save procedure.

Executes Criteria Based Sharing evaluation.

Commits all DML operations to the database.

Executes post-commit logic, such as sending email.
A Few Terms
 Apex – A programming language in Salesforce. Allows
developers to extend the functionality of Salesforce.
 Assignment Rule – logic that changes the ownership of a
record. (Every record is owned by a user)
 Required – Field must contain a non null value to be accepted.
 Trigger- An event that happens as a result of another action.
Usually set up as an Apex Trigger (code that runs as a result of
some other thing).
 Sharing Rule – Logic that controls who may see a record
outside of the owner.
 Validation Rule – Custom rules created by administrators that
data must meet to be accepted into the database.
 Workflow Rule – A ‘Trigger’ that can be built by an
administrator that does not require Apex. Less powerful, but
easier to use.
The Labors of Hercules – SF Style
To understand the save process, let’s take an example (with
a fun story). A contact, named Hercules. He has just been
spawned by a user, and now wants to join his family in the
elysian fields (the database), but first, he must prove he is
worthy!
*
Yes I know Hercules was made into a god after his death and did not go to the elysian
fields, but instead Mt. Olympus. It’s a metaphor, deal with it.
Validation Rule
 In our org we only have a couple validation rules. The
one Hercules will encounter is this.
Trials of Hercules - 1
 First, step Hercules must defeat the field length, and
data format requirements, also any validation rules.
 All data is of appropriate length and meets the format
requirements. He passes the validation rule as well. He has
passed this test.
 Next, all Apex triggers that are configured to run
BEFORE save run. There is only one on the contact
object (setting the PIN on the new contact). Hercules
passes this test (no errors occur) and he continues.
Trials of Hercules - 2
 Validation Rules are run again (since the logic in the
Apex trigger could have made it invalid).
 Hercules easily defeats this trial. All his data is still good.
 Hercules is now ‘saved’ to the database. A save is NOT
the same as a commit. He has only trial access. He could
still fail and be removed. (This is to generate an ID for
the new record).
 All after update Apex triggers are run. We don’t have
any of those.
 Hercules of course passes this trial.
Trials of Hercules - 3
 Executes assignment rules. Change the owner of the
record.
 Hercules being of a household type is reassigned from the
original user as being the owner the owner to the host
account (reasoning explained in another session).
 Executes auto-response rules
 We don’t have any of these on the contact object. Hercules
breezes through this as well.
 Workflow Rules are run.
 Hercules gets an email welcoming to our company. His
information is also sent to our on premise DB. He continues
forth.
Trials of Hercules - 4
 Before and After Apex triggers fired again
 Our workflow rule did not update the record itself, so the
Apex triggers do not need to fire again. He continues
forward.
 Executes escalation rules, to assign owner to someone
else if certain conditions are met (usually used in cases)
 None of these exist on the contact. Hercules continues
toward the database. He is close now.
 Rollup fields are calculated, first rollups on this object,
then rollups that use this object.
 There are no rollups here (rollups can be subject to
validation rules as well). He continues.
 Sharing rules to make sure anyone who should see this
contact can.
 Hercules gets through this last trial and his data is shared
with the rest of the company.
Success
 Hercules has made it to the database and been granted
permanent access. In this state the record is said to have
been ‘commited’.
Whew, Intense eh?
 Who knew there was so much data had to go through to
get into the database? As you can see there are many
places it can get caught and rejected. Failing even ONE
of those trials would bar access to the database and the
data would be rejected.
 Along with just being strict, the process outlined allows
for many many points of automation. After seeing all
that think about how much of your job could be
automated and make your life easier (send emails,
update fields, update other objects, etc all
automatically).
Rollbacks
 Of course when there is so much automation it is easy to
see how one action could cause many others. Say a
record is saved AND committed to the database, but
then you want to undo that. How can you possible undo
all those changes that may have happened
automatically?
 Salesforce offers programmers a tool called rollbacks.
This allows triggers to undo the result of a save by
create a save point before a transaction, then if
something didn’t go right, you can rollback to the save
point. This feature is not commonly used, and rollbacks
are expensive and should be avoided.
Event Chaining
 You can see how it was possible to use Apex Triggers
and workflow rules to do lots of things, including editing
other records. Those records in turn could go through
the whole process and run their own triggers and
workflow rules.
 This ability for one record edit to spawn a whole chain of
events is extremely powerful, but can also lead to lots of
confusion down the road (‘Why is this getting updated?
What is this doing? WTF!?’). In general you’ll want to
make sure the conditions that trigger your workflow
rules and triggers as specific as possible to avoid
accidental triggering.
What can be automated?
 My basic rule of design is automate anything that
doesn’t take a human brain to do. If there is any process
that is repeated within a fairly tight set of rules, odds
are it can be automated. If it follows rules and doesn’t
require subjective analysis it can probably be
automated.
 You can perform almost any action a human can with
automation if you are clever. Send emails, place phone
calls, update records, move data, send text messages,
post to facebook/twitter, import data from a remote
source, it can all be automated. Think about how you
could break any process you do on a daily basis into
discrete steps. Then think about how they could be
automated.
How to automate
 Break the process into steps
 Define the edge cases (situations outside the norm)
 Flow chart the process
 Explore potential solutions for each step
 Create
 Implement
 Test
Question, Comments, Rants?
 I know that was a lot of information, and mostly fairly
abstract so feel free to ask anything. Seriously, this stuff
is kind of complicated and it’s really important to
understand it. Ask. Ask now. Do it. Nobody is going to
judge you. I’d rather you ask now than break something
later.