Salesforce Certified Platform App Builder – 5 – Business Logic and Process Automation Part 8

26. Ownership Re-Assignment and Alerts via Escalation Rules

So now we’re going to discuss escalation rules. And so I’m going to search for the term escalation in the setup menu. And you see we’ve got two options here, the Escalation rules under Cases and then under Monitor we have Case escalations which we’ll get into later in this lecture. You’ll notice as well I’m in Salesforce Classic and that’s because when I was attempting to record this in Lighting Experience, I wasn’t able to edit the escalation rules for some reason in Lighting Experience. So I popped over to Classic to record this. So in my free developer account here, I have the one active standard case escalation rule so I can click on that and get to the different rule entries that are evaluated in order based on this order sequence numbers, which I can change these by changing the numbers here and clicking Reorder and the screen refreshes accordingly.

And then as well to edit one of these rule entries you can click Edit and that brings you to the detail screen for this rule entry and it gives more details on the criteria here, the order number, et cetera, which I could edit this and make changes here if I wanted to. And then as well, the thing I really would like to highlight are these escalation actions. Now escalation actions only happen on cases and this has to do with the changing of ownership either to a different user or to a queue. And the use case behind this is that if a case isn’t resolved in a timely fashion, you may want to alert a manager or do some sort of action. And so this existing escalation action that’s tied to this particular rule entry is set to escalate at 2 hours and it’s assigning to myself and sending an email using the support template for an escalated case notification.

You can click on this by opening in a new tab here to view what this template looks like. This helps you get an idea as to the use case here and it’s saying that the following case has been escalated to the escalated queue. This is a standard email template that’s available in your own salesforce organization as well under the unfiled public email templates and the template name is called Support Escalated Case Notification. And so I’m going to close out that tab to get back to my escalation action and I’m going to click Edit next to this. And here’s where you can change the timing of this escalation action. This is the number of hours after which a case should escalate if it has not been closed.

So the clock starts ticking once a new case has been created and it waits 2 hours before it’ll escalate, basically. And so you can also do this in half hour increments as well. So if you wanted to do this really quickly, like 30 minutes after it’s created, you go ahead and escalate. You could auto assign these cases to another user or you could do that to a queue. And so I previously created a service queue. Let me make sure I’ve got the name right here and selected from the search results. So I’m going to auto reassign cases to the service queue and then I’m going to select the user to notify and so I’m going to notify myself here. Here’s another notification template. For example, you can do additional emails. These could be people inside or outside of salesforce and then you click Save.

Okay? So I’ve taken a moment to figure out what’s going on with this particular attempt at firing off an escalation rule and getting it to queue up accordingly. And I think that you can’t actually do escalation rules in a free developer account as far as the automation goes and scheduling those for future scheduling. I think it’s a limitation of the developer account. If you do succeed in getting an escalation rule to match in your developer account, please let me know. But I wanted to show you my own internal instance of salesforce here. And here’s a couple of escalation rules, rule entries that I have for my primary escalation rule in my own instance. And you notice that there’s a couple of rule entries here. And this first is if the case origin equals email or the case origin equals web and the case status equals new, then there will be something that happens.

And that something that happens is an escalation after 24 hours and it notifies me. And so it doesn’t auto reassign the case to anyone, but it sends me an email to let me know that there’s a case that’s been created and it’s escalated as well. And so I’ll show you how this works and then we’ll show you the time based queue for case escalation. So if you go to my website and here’s Mike Wheelermedia. com, and if you click on the contact tab, this is a contact form that you can enter in and actually get in touch with me and enter in your email address. I’m going to put in a fake email for sake of this demo and then entering in a message and click Submit.

And this is a web decay form on my website actually. So that flows into my own salesforce instance and it matches the criteria set forth in this escalation to my rule, this first rule entry. And so if I search for escalation and look under monitoring for case escalations, this is much like the time based workflow queue, but this will show any time dependent actions related to the case escalation queue. So I’m going to click Search and I did one of these previously in order to basically figure out what was going on by looking at my own instance and verifying that I was doing things correctly. So this is the one that we just did via the website here. This is the case to escalate is case number 10 86 and the Rule entry. So it tells you which rule actually triggered this time based action. And here’s when it was added in the Escalation action link, you can delete these by selecting them and clicking Delete. I’m going to delete that one that I did previously, leaving the one that we just did now.

And so if you want to review the rule entry criteria, just click on the rule entry number that will take you back to the Rule entry edit screen and the associated Escalation actions. So you’ve seen an example of how now that you can do case reassignments through Escalation rules and then also send alerts as well, and then also monitor those pending actions by going to the Case Escalations link under monitoring. So now that you’re familiar with Escalation rules, it’s now time to talk about the order of execution in salesforce and understand why that’s.

27. Order of Execution in Salesforce, and Why It Is Important

So let’s talk for a moment about the order of execution in Salesforce and why that’s important. And I’ve got here a page that’s available online from the Apex Developers Guide. And this is a pretty complex topic as far as the order of execution of events in Salesforce. And you really get more into the order of execution when you get into the level of the Platform Developer Helper One and Platform Developer Two certifications. But you do need to have a basic understanding of the order of execution, even for the Platform App Builder exam.

And so the idea behind this is you want to understand the order at which Salesforce executes processes and triggers and workflow rules, et cetera, during a transaction. And what I mean by a transaction is when a user, either through the interface or through data loader, through some sort of bulk operation or through some scheduled job where a record is updated, a single transaction would be whatever event is starting. This will have some sort of update that ultimately will hit the Salesforce database behind the scenes and some sort of field or value will be updated. And so there’s a lot that happens in this process. And if you notice, there’s 20 items here in this list and you’re not going to need to know each of these in order on this exam. But I do want to highlight and make this page available to you in the resources section of this particular lecture.

But I wanted to mention that some of these early things have to do with the loading of the record and initializing the record as well, and then loading any new record values, et cetera. And then there’s this concept of doing any before triggers. Now triggers aren’t on the Platform App Builder exam and those are written in Apex code and there’s different types of triggers you can do there’s before triggers. And these are things that happen on the front end of a transaction. And so that’s why this happens early in this 20 step process. Then any system validations run, for example. And then we get into the duplicate rules. It saves the record to the database, but it doesn’t commit it yet, so it’s not a final save. And then it executes all after triggers. Then assignment rules are run and then auto response rules are run. That would be like for lead auto responses. When someone submits a web form, they get an auto response. It is here that the workflow rules run and fire. And if there’s any filled updates, then it updates the record again and it’s still not committed yet for final save. And then we get into it.

The record was updated with workflow filled updates, identifiers before update triggers and after update triggers one more time and only one more time, in addition to standard validations and then custom validation rules, duplicate rules and escalation rules are not run again. So certain things fire a second time. We spoke previously about ramifications of field updates and potential for recursion several lectures ago. And so it’s in this area of this process that this potential recursion could happen. So the next is executes any processes that would be through the Process Builder. So if there are workflow triggers that executes any flows off of this via the processes, and it even mentions this pilot program, which we’re not going to go into at this point, then finally, on the tail end, it executes and remember, we’re still inside of a single transaction here. It executes any escalation rules, then it executes any entitlement rules.

Entitlement rules has to do with the service cloud and entitlements, and there’s rules around that as well. It has to do with service level agreements in the service cloud and what clients are entitled to. And then as well, we start to address any roll up summary fields, any cross object workflows, any calculations, and then parent records go through the Safe procedure, for example. And then finally, as these things start to roll up into the parent and grandparent level, we’re dealing with those sorts of things in the later steps of this transaction. And then finally, it executes any criteria based sharing evaluation, and then it commits all DML operations to the database. That means that it commits the save and the record is saved. And then any post commit logic, such as sending an email, happens at the tail end. And so it’s a good idea to become familiar with, at least at a high level, this order of execution.

Like I was mentioning, you do not need to know this in depth for the Platform App Builder certification exam. But you do need to have an idea of when these things happen in general, especially around workflow rules happening before processes, and then any assignment rules and auto response rules happening before workflow rules. It’s really these main points here, I would say basically about seven through 13, having an idea of when these things happen, and just a general idea of the things on either side of this would be a good rule of thumb, I would say. So I wanted to at least give you more details on the order of execution in salesforce and an idea as to why it’s important. And in the next lecture, we’re going to be getting into monitoring and debugging processes in salesforce.

28. Monitoring and Debugging in Salesforce

A helpful tool in Salesforce when it comes to development is the debug log. And so you can access the debug log and set up by searching for the word debug. And not only can you get to the debug log but also debug levels, which we’ll look at here in a moment. So the idea behind the debug log is you set a user that you want to specify in order to monitor or to debug any actions that they perform on the platform. So the debug log records errors to workflow rules, approval processes, assignment rules, et cetera. And so you first specify a user that you want to set a trace flag for, and so you could also do a trace entity type instead of a class, a trigger or an automated process. But for now, we’re just going to focus on a user and I’m going to monitor myself. And so I’m going to perform a search for myself and select from the search results.

And then the start and expiration date defaults to a 30 minutes window starting from right now. You can expand that to increase the time, but you can’t exceed 24 hours. And then for the debug level, that is where this other menu item comes into play is the debug levels. And so there’s only one right now in our own instance here. I’m going to do a search for it though to find it, and it’s called SFDC Dev Console. And it has these different levels of detail around workflows and validations and call outs, et cetera. And the finest level of detail is around the Apex code.

And so I’m going to select the Dev Console debug level and click Save. And so now I have my user trace flag for myself. And so if I were to go into salesforce, I’m going to open this in a new tab so I don’t lose my place here and perform some actions. Let’s say I were to go into an account and let’s create a new case, for example, and let’s set the case origin to phone and the status to escalate it and the priority to high and click Save. I’ve just created a new case in my own Salesforce instance and let’s go to the debug log. And if I refresh this, we should see some data here in the debug log section of the screen. So I’m going to click refresh. And so now there’s a few items listed in the debug logs. We have a couple of operations here that you can then view.

So in order to view a debug log, you can just click View. And this gives you the details around the different workflow rules that are fired in actions that have been executed, et cetera. If I go back, I can view the other one. And this is an Apex page around sample account that was pulled in somehow. And then as well, if there were any errors, they would appear down at the bottom. It also shows you any limit usage and if you’ve exceeded any limits, those would appear here as well. Everything went fine and there were no errors. And I’m not going to set up and go through the process of trying to get something to blow up. But if there were any exceptions that were thrown, you can find those through the debug log.

So it’s a very helpful tool. And then as well, as I mentioned, I want to also show you the debug levels and how to set a new debug level. So we’ve got the one for SFDC Dev console and I’m going to create a new debug level and I’m going to call this Finest. And this would be if I wanted to get to the Finest level of detail around all the different categories. And it’s a good idea to get familiar with these different categories that are available in the debug log because this will tell you or give you an idea of the different areas or categories that things can go wrong in salesforce. And this has to do with the order of execution that we just talked about. And then as well, these different categories you can set to different levels. Some of them vary, such as workflows. You can give no level of detail this will update as well as you select these different drop downs. If the error level will just show a few errors, warning level adds different elements or events that it’ll bring back in the debug log and you go all the way to finer on the workflow. And this gives you a lot of different things here as far as the different events that will register in the debug log related to validation rules, you can set that either to none or just info. In the debug log call outs, you can set that to Info or Finest Apex code.

I’m going to set that to Finest as well. I’m trying to get this to be as granular as possible and then show you how involved this can get. And so finally, if I click Save, we have this debug level of Finest. So if I go back to my debug log and what I can do is I can adjust my trace flag on myself, but I’m still in this hour and a half window that I set for myself. And instead of the default debug level, I’m going to search for this Finest debug level that I just created and I’m going to click Save. And so now I’ve adjusted my debug level to the Finest level, this new debug level. Here’s the list that shows the debug level name, which is Finest. And so I’m going to go in and do a few things to try to get some things in the debug log and show you the level of detail here.

So if I go to an opportunity, let’s go to the opportunity pipeline here and let’s select one of these opportunities that’s currently open. I’m going to edit this and I’m going to set the stage to closed one and click Save and then let’s go to contacts and let me just randomly delete someone here. So I’m going to attempt to delete this contact record and click OK. And so all of these actions will be captured in the debug log whenever I create new records or edit records or delete records even, there may be delete triggers that fire, for example. And so the debug log, once again I’ll access that. And now since I’ve got a trace flag on myself and I’m within that window, you see that there’s been one more event that has occurred here and it’s got this operation URL and I can either view or I can as well download these or even delete these if I don’t need them any longer.

So we previously looked at these other debug logs. I’m going to delete those and just deal with this one new one. I’m going to click Download and that will download the file to my downloads folder of my computer, which could open separately or reference later. I’m going to click View, though for sake of this recording and show you that this finest level detail of the debug level that I set, that there’s more in greater detail involved, more events that are being captured. And once again there’s no errors. But you see that there’s some things such as some flow start times and some weight elements and assignment details, workflow actions, time triggers, and then finally the process is completed with no errors. So we’ll go back to our list of debug logs and so in the next lecture we’re going to be looking at using the Developer console and there’s a lot of things you can do in the Developer console as far as creating code and performing tests and verifying your test code coverage in salesforce. But as well you can do debugging through the Developer console as well. So stay tuned for the next lecture where we learn how to use the Developer console.

29. Using the Developer Co

So now we’re going to talk about using the Developer Console. And so in order to get to the Developer Console, click on your name in the drop down and select Developer Console. And this is in Salesforce Classic that launches a new tab with the Developer Console. It’s from here that you can create actual new code. And this is a browser based development environment and where you can create, test and deep debug your code. And so from the file menu, you can go in here and select New and you can see the different things you can create in the development console. The Platform App Builder exam is not going to go into a lot related to the Developer Console, but it is helpful to know how to use the Developer Console, especially for running code coverage tests and to debug code as well. Whenever you have an occasion to create a visual force page, for instance, you could do that via the Developer Console, Apex Classes and Triggers, et cetera.

To create a new Apex class, for instance, you just simply click Apex Class from the drop down, you enter the name and click OK. And it starts to fill in the start at least of the code for you. And then you could fill in the rest of the code here. Now, in the exam, there’s no code in this exam, but I wanted to show you at least a little bit of how the Developer Console works as well. You notice you can set the API version and you can down sample that to an earlier version of the API if you wish. You see the Asterisk here showing that there’s been changes made. So we need to save that. So you can try and save, but if the code is not complete, it won’t allow you to save it.

 So, for example, if I were to type in some gibberish here, let’s try and save that. And you notice what happened is there’s an exclamation point here on line two and a red dot and you see the Problems tab lights up with a numeric one. And so this is where you can begin to debug your code. It’s saying that online too. It’s expecting a right curly bracket, but found the semicolon instead. So I could go in and clear that out and then save it as well. And we’ll watch that Problem thing disappear. There’s also the feature as far as automatic code complete as well. You notice that as well. These brackets are green and highlighting. And so that’s the current section of the code that I’m in. Other things you can do. Some of these tabs down below, these are debug logs.

So for instance, this is blank right now if I were to go into Salesforce, let’s go in the other tab and let’s create a new opportunity. Just as an example, we’re going to just do a new product opportunity. Click Continue setting the required fields and click Save. And now we go back to the debug log in the developer console and you see that this operation succeeded. And so you can double click on that to view the content. And this is where you can get into the debug log. And it’s very helpful to show you the sequence of events that occur in creating that new opportunity. You can see that there’s different events that fired and the timestamp of when that occurred as well. Here’s where the workflow evaluations began and here’s a workflow that was evaluated called One Opportunities.

It gives you the IDs for these, and then any errors that occur are down here at the bottom. And so if you have any triggers misfiring or any sort of conflicts or problems or processes that are blowing up, and we talked about in the previous lecture monitoring debugging processes, you can really get into a real fine level by looking at the debug log. You can view those from the developer console. Another thing that I want to show is you can run code coverage tests as well. And so under the test menu, you can select New Run. And the thing that I want to note is a question you may have on the exam is what percent of code coverage do you need in your salesforce environment in order to deploy code?

And that magic number is 75%. That’s kind of a known thing across the platform is that you have to have at least 75% across your entire organization in a production environment for your code to continue to run and be able to deploy things. And when you’re deploying triggers, you need at least 1% of code coverage on a trigger, but cumulatively, across your entire organization, you have to keep things above 75% code coverage. So I selected a test class here called Convert Lead that I have in my and I selected all of these lead tests. I’m going to click Run and show you what a test run looks like from the developer console as well. And you see if you click on Test that it shows you this test run that occurred at this time. You can expand this to see what the test was and the different methods that were tested as well. And you notice in my own organization right now that my overall code coverage is 49%. So before I could deploy things, I need to get this up to 75%. But this Convert Lead that I just ran, it had code coverage of 97%. It covered 75 out of 77 lines.

So if I were to open up this actual class called Convert Lead by going File open and then selecting classes, and then selecting Convert Lead, this is some code that Salesforce has created. And if you want to see the code coverage, we can select from the code coverage drop down. I’m going to select all tests 97%, and that will then highlight any of the code lines that are covered or not anything that’s commented out. These are comments here with the Slashes or the Asterisk Slashes. So those don’t count towards my code coverage. The ones in blue are lines that are covered in code coverage. And we mentioned previously that 75 out of 77 lines are covered for 97%, which is a good score.

 And so you could feel comfortable with deploying this to production and knowing that you’re not going to tank your code coverage or cause errors for your entire organization by bringing it under 75%. You won’t actually cause errors, but you will not be able to fully deploy this because it’ll fill the validations during the deployment process. And so just scrolling through this is the only two lines that aren’t covered by code coverage is this string error here. And this is an exception that we’ll throw an error, basically. So we’ve covered a whole lot in this section here as we’ve been dealing with business logic and process automation around the various ways that you can automate salesforce and do processes in an automatic fashion. And we find ourselves now at the end of this section and I want to congratulate you for making it this far. And now it’s time for the business logic and automation.