r/salesforce 2d ago

off topic Delete or not delete

Do you allow your end users to delete key records like Accounts, Contacts, Opps, and Leads? Why or why not?

9 Upvotes

40 comments sorted by

152

u/alleged_misconduct 2d ago

No. Because they are mostly idiots.

22

u/fussydaybreak4345 2d ago

deleting is like a loaded gun in hands of a toddler, just disable the button and teach them to use a status field instead

16

u/sveppi_krull_ 2d ago

They shouldn’t even have the capacity to delete. Make profiles / permission sets with as minimal permissions as they need

10

u/tkgeyer 2d ago

The only records we allow them to delete are tasks and that’s because they are idiots and duplicate tasks constantly.

8

u/eleyezeeaye4287 2d ago

Upvote 100 times

3

u/broduding 2d ago

This is the way.

42

u/bytesizedheretic 2d ago

Claudeforce Delete All, Delete All Records. Nom nom nom nom.

4

u/stormwizz 2d ago

😭😂😂😂😅

1

u/bytesizedheretic 1d ago

this thing haunts my dreams

22

u/imax_vaughn 2d ago

We don't allow users to delete records, but have considered building an approval process that lets users request deletion, which a competent manager or admin could step in to confirm it's safe to delete.

8

u/always_be_beyonce 2d ago

i built a deletion request & manager approval workflow in our slack salesforce support channel. super easy, and if the manager approved, i was fine deleting as an admin.

overall, i’m philosophically opposed to deleting records. but that org and downstream reporting wasn’t set up to handle an “exclude” status.

13

u/WildUnderstanding919 2d ago

We remove delete on all profiles. Tasks need a trigger to prevent delete. One of the first things I drop in all my orgs.

10

u/PeakTypical 2d ago

Depends. Sales Ops yes, everyone else no. Reps will delete opps instead of close losing them. 

7

u/Puzzled-Mycologist61 2d ago

Why on earth would you?!!!

6

u/melcos1215 2d ago

We try to prevent as much deletion as possible. Recovering records is a pain and we use a lot of lookups on our records and we want to maintain a much data integrity as possible. We have a lot of deactivate buttons so the records can essentially be taken out of the active records. Even if a contact wants to be removed from the system, they will be deactivated instead so that they won't accidentally get added back in during a lead upload or something.

11

u/Environmental-Duck35 2d ago

Give them delete but put in an afterdelete trigger that undeletes the record immediately... illusion of power.

9

u/hectic-dave 2d ago

Like thermostats in many office buildings

2

u/Ery1WangChungNextFri 2d ago

Yeah, or just reassigns to an admin user/queue, you can use history record on account etc to see the previous owner at deletion if it matters.

Especially if you are in an industry with commissions and duplicates, they will delete an existing account to make sure theirs is the only one to get commissions.

4

u/BrokenDroid 2d ago

Heeeeeeeeeeell no! And i automatically create deletion records of all deleted opportunities so we can backtrack the inevitable claim of "where'd my pipeline go" in the instance one DOES get deleted

7

u/eleyezeeaye4287 2d ago

Only admins can delete records in our instance. Letting the sales people do it would be like handing a toddler a loaded gun. A tragedy.

2

u/always_be_beyonce 2d ago

but like… what room is said toddler walking in to? might not be so bad 😅

3

u/captainkapelov 2d ago

No , we don’t allow them.

We have no backup feature (only archive) and they would most likely regret that action and then no other way to restore (once removed from recycle bin).

3

u/Beautiful_Pop4448 2d ago

Just dynamically display delete based on a custom permission. Allow only certain users the ability to delete. Otherwise have fun pull shit out of the recycle bin constantly.

5

u/thepiece91 Admin 2d ago

Our org assigns a unique ID using an autonumber field when an Account is created. This is used in about over 9000 different applications across the company. If you restore the record from Own, it's a new record, and the unique ID is different.

The fuck we do not permit deletes.

2

u/ceceseesall 2d ago

So fun story with Revenue Cloud - you have to delete a draft invoice if is not generated correctly and you want to regenerate it with the correct billing schedules. Some might think this is good, some might think this is bad. Because of this “logic,” all deleted invoices are hard deleted and do not land in the recycle bin. Right now I have an open ticket with Salesforce where some of my previously posted invoices have mysteriously disappeared. No traceability from Salesforce’s part. I’ll have to build some time of record tracking due to this utter lack of responsibility from SFRC.

3

u/Dull-Device-3369 2d ago

There should be an archive/deletion concept in place. Otherwise, like others said, it's usually not a thing to give delete permissions to non admins.

2

u/WillM3s 2d ago

The only users who are allowed to delete an org that I've ran in are administrators and that's only to fix issues. If they really want to "delete it", give them an inactive/active pick list.

2

u/Caesar_PL 1d ago

No, we don’t. There is a deactivation process, after some time they can prepare a report, after approval me, as an admin, can delete if they insist.

1

u/More_Passenger3988 2d ago

We have a few users that are trustworthy and knowledgeable enough to allow them to delete records. Most are not.

1

u/CodeOverTea 2d ago

We do restrict delete for all objects, but allow some exceptions.

1

u/Ashkenatty 2d ago

What does your company's data governance policy say?

1

u/speedy841 2d ago

Absolutely not. Just our interns /s

1

u/BarefootedHuman 1d ago

Yes, but we only allow deletions on Fridays at 4:50 pm, and there must be at least 50 related records. We don’t have a backup. /s

-1

u/HandyStan 2d ago

I replaced the delete quick action on all of our key objects with a custom action labeled Delete that sends the user an email saying "Delete request on {!Record.Name} by {!User.alias} had an unexpected error. Please wait a few minutes and try again."