Make sure prior to mass deleting records that this is your employers desired end state for these records, and that they wouldn't prefer to archive/offload them to another system!
Good stuff. I got kinda confused when you queried for the records and then deleted them. I thought the enqueue afterwards wouldn't work because in my head the list of cases would be empty after they got deleted. But in reality the original list in memory still holds the copies of the records.
Hard to answer without knowing the org/requirements. I think you'd want some level of hard coded definition of what you're trying to delete, so it doesn't run rampant. If you have multiple objects with similar requirements, you could make the code generic (with safe guards) and pass in the target object/age (with safe guards) as a parameter to use in a dynamic query during each run. Or you can delete the children before deleting the parent all in the same transaction's execute, just watch the DML limit if spanning multiple objects in large batches. You can also consider using the build in cascade delete feature of the master/detail or lookup relationship fields to handle cleanup.
I wanted to use flow, but unfortunately there is no LIMIT option when performing a get query in flow. If your get query returns more than 50k results or your delete tries to delete more than 10k records, it will fail.
Except for the org's recycle bin, not exactly. That's why you always want to do thorough testing and keep backups as a last resort. This "reset" was really re-inserting sample test data using a couple of anonymous apex executions.
Make sure prior to mass deleting records that this is your employers desired end state for these records, and that they wouldn't prefer to archive/offload them to another system!
Very clean and clearly explained. Thanks for your inputs 🙏
Good stuff.
I got kinda confused when you queried for the records and then deleted them.
I thought the enqueue afterwards wouldn't work because in my head the list of cases would be empty after they got deleted.
But in reality the original list in memory still holds the copies of the records.
great video.. you are a natural... thank you!
Any suggestions on how to handle any related records that also need deleting? (In a composable/scalable way, hopefully preventing hardcoding)
Hard to answer without knowing the org/requirements. I think you'd want some level of hard coded definition of what you're trying to delete, so it doesn't run rampant. If you have multiple objects with similar requirements, you could make the code generic (with safe guards) and pass in the target object/age (with safe guards) as a parameter to use in a dynamic query during each run. Or you can delete the children before deleting the parent all in the same transaction's execute, just watch the DML limit if spanning multiple objects in large batches. You can also consider using the build in cascade delete feature of the master/detail or lookup relationship fields to handle cleanup.
We can also use flows to delete the records.
I wanted to use flow, but unfortunately there is no LIMIT option when performing a get query in flow. If your get query returns more than 50k results or your delete tries to delete more than 10k records, it will fail.
Is there really a way to reset the org data l? ike what you did in 11:58 ... Thanks !
Except for the org's recycle bin, not exactly. That's why you always want to do thorough testing and keep backups as a last resort. This "reset" was really re-inserting sample test data using a couple of anonymous apex executions.
☹️ *PromoSM*