scenario: you are given a user story to estimate and write the technical design for the next sprint user stories.
user story:
Users should not be able to save the case record when the product field on the case is of a family laptop and the case reason is blank.
you started to estimate the user story and write the technical design for it.
Technical design:
validation rule on the case object.
Estimate:
1 story point for writing the validation rule + testing + deploying to the CI org.
Since the user story estimation and technical design are completed. you are about to proceed with other work that was assigned to you.
suddenly, you realize that you missed something.
wait...
now, take a moment and think through what was missing in the technical design and estimate.
did you get the answer?
if you figured out what is the issue. congratulations....
if you are still figuring it out. I was in your shoes when I realized what I was missing. It came at a big cost. Last min changes.
If you are thinking. enough. tell me what was missing. The answer is the technical design itself.
ok. no more suspense. validation rule would stop the user who acts on the record. it can stop the new records if the above conditions are met or if the user edits the old record which satisfies the conditions.
For the new records, users would be able to get the information from the end user when creating the case. what about the old case records? do we need to correct these records as well? if we don't if any user wants to change anything on the records they will get the validation. this would stop them from saving the changes on that records.
so what should we do? in such cases we need to check with the business/clients on what should happen on the old case records. do we leave it to the user to figure it out?
If the answer is yes, we are good. if the answer is no. then we need to correct the old case records in the org.
Now, if you are wondering there would be a large volume of case records in the org. How do we edit those records?
I am glad that you asked for it. There are two options here.
1) data loading.
2) Batch class.
Let's review option 1 first. To operate on large volumes of records, we are choosing the Data Loader as an option here. In order to proceed first we need to get the extract of the records that we need to proceed then prepare the csv file with the correction on the necessary fields. followed by updating this file again to the Data Loader for the update operation on the case object.
Looks cool right?
yes, it is. we can do this approach. if we have one sandbox and prod org. what if there are 5 sandboxes and prod as part of your application/deployment lifecycle?
It would lead to 3 problems.
1) Resource bandwidth.
2) delayed timelines for project delivery.
3) manual effort and may cause manual errors.
if you are thinking is there any alternative? yes, there is one.
what is it?
Batch class.
what are the advantages of it?
you write the code once. it can be used in others org as well. all it takes is to just deploy the code to the orgs you need it and run it using two lines of code. FYI... we can put that into one line as well. :D
if you are looking for where can i get started in learning the batch class?
you are at the right place. we had made this course covering from basics to the most advance sections in batch class concepts including all the best practices that you need to keep in mind while writing your batch class. In fact, who would want their code to fail in higher orgs and get rejected in the code review?
if you are reading this line, I hope you had made a decision. I am eagerly waiting for you inside the course. Let's together jump on this roller-coaster ride. see you on the other side!!!