While we don’t want to waste time needlessly testing for “edge cases,” the different scenarios that might break our automation in Salesforce can become numerous as the automation becomes more robust. Furthermore, something that we judge to be an edge case at first might turn out to be something an end-user tries more frequently than first thought.
This is certainly the case when we use processes, flows, or apex code to create/update records automatically based on a specific update to a record in a different object. The potential for inadvertent creation/update of records is huge, and there are some sneaky ways an end-user could accidentally trigger our automation when they shouldn’t.
This kind of process could be as simple as a course attendance flow in which we need to create an attendance record from a user’s action on a course record. It could be even more complex if we need to create more than one record automatically based on a user’s action. For example, let’s say we set up a process using Process Builder and Flow that automatically creates records in Object B based on a number field and a status field on Object A. The status field tells the process when to start and the number field tells the process how many records to create in Object B.
But what could go wrong? Salesforce makes this easy, right? Let’s take a straightforward example of a possible error that the following checklist is meant to uncover.
In our example of Object A and Object B, we want Process Builder to fire and run our Flow when a record of Object A reaches a certain status. This could happen when the user creates or updates the record, so we choose to start the process “when a record is created or edited.” Then we create a node that runs the Flow (which creates the records in Object B) when the status field equals “Completed.” Then we add the Flow as an action on the node. All set, right?
Nope. When a user first saves an Object A record with “Completed” in the status field, the Flow runs, and the Object B record is created successfully. However, as we go through the below checklist, we will quickly realize that every time the user updates other fields on the “completed” record, the node fires, and the Flow runs again, creating duplicate records in Object B.
Of course, this is a simple fix (making the record read-only when “completed,” using ISCHANGED(), or the “specified changes” checkbox under Advanced on the criteria node). But errors of this sort are easy to come by, and the sheer variety of ways that unexpected outcomes can arise begs for a systematic approach to testing.
This checklist is great for developing test classes and doing your testing in the user interface. Some scenarios won’t apply to all types of processes, but you can pick and choose which situations to test based on the features of your automation.
The Checklist
- Are the records created correctly if one record fires the Process/Flow/Trigger?
- Are the records created correctly if more than one record fires the Process/Flow/Trigger (as in bulk processes and data imports)?
- What happens if the user makes an unrelated edit on the Object A record and saves the record again?
- What happens if the user tries to role back the edit that fired the process?
- If Flow is supposed to create a certain number of Object B records based on a number field of the Object A record, will the process fail if a large number of records are called for (as in 1,000+)?
- This will test the Executed Elements at Runtime limit in Flow of 2,000
- What happens if the number field is blank when the user saves the record with the triggering status?
Orgs That Overcome 