Data Retention
Turn a retention policy into one configuration record instead of a custom purge job.
01The problem
Old records pile up: closed cases, aged form submissions, expired usage data. Removing them after, say, 90 days used to mean asking a developer to write, test and ship a purge job for each object.
Who has it: Admins who set retention rules, compliance and audit viewers who need to see what was deleted, and developers for the rare custom case.
02How it works
Data Retention replaces those purge jobs with one rule an admin sets up.
A rule names the object and a plain-language condition for what to delete, and whether to delete for good or leave the records in the recycle bin for a while. A blank condition is refused, so a rule can never mean “delete everything”. Before anything happens, a dry run shows exactly which records would go. Nothing is deleted until an admin switches the engine on, and a daily schedule then does the work.
Every run is recorded in a history that compliance and audit viewers can read without being able to change anything. For the unusual case where deleting is more complicated, a rule can point to a small custom class instead.
Built on the suite's shared foundation: logging, configuration, shared components and a standard Home, Setup and health page per app. Apex Chef for Salesforce
03How to get it
- Ask for a demo30 minutes, about which processes it should cover.
- Try it in a sandboxInstalled in your sandbox with your own test data.
- Licence and go liveA written offer, then installed in production.