1 / 25

Learn 2 Salesforce

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

coty
Download Presentation

Learn 2 Salesforce

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Learn 2 Salesforce Round 2 – Saving & Automation

  2. 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.

  3. 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)

  4. 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

  5. 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.

  6. 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.

  7. 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

  8. 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:

  9. 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).

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. Validation Rule • In our org we only have a couple validation rules. The one Hercules will encounter is this.

  15. 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.

  16. 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.

  17. 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.

  18. 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.

  19. Success • Hercules has made it to the database and been granted permanent access. In this state the record is said to have been ‘commited’.

  20. 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).

  21. 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.

  22. 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.

  23. 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.

  24. 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

  25. 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.

More Related