Retention trigger rules

Deletion should begin with a recorded event. A later touch changes the retention clock only when you can show it was a genuine refresh. For B2B prospect data processed on legitimate interests, the retention window depends on how long that legitimate interest genuinely continues.¹ Record the trigger before calculating the deletion date so the decision can be checked later.

The trigger map

Use this map to identify the event, check whether it still counts, and choose the storage action. Move to the next stage only when the current event and its date are clear.

Stage	What you are trying to learn	Example question
Choose the trigger	Which event starts the retention clock?	What event applies to this type of prospect data?
Check activity	Whether a recent interaction or active contact exists	When was the last meaningful interaction?
Validate a reset	Whether a refresh meets your rule for extending retention	Were the contact details and role verified?
Check the request	Whether the person has asked for an opt-out or deletion	Has the person asked us to stop using the data?
Apply the rule	Whether the record has reached the deletion point	Does the trigger date now meet the retention rule?
Verify the action	Whether the system completed the intended action	Where does the record sit after deletion?

Choose the event that starts the clock

Start with the data context and name the event that starts the retention period. One calendar rule misses the difference between an active contact, a closed matter, and data that has been superseded.

Depending on the data type and context, a retention period can follow the last entry, financial year, case or project closure, or the date the data is superseded.² Set the start point to a specific event that your team can retrieve later.³

For marketing contacts, the last interaction can trigger the retention period.⁴ Write the rule as an objective calculation. For example, B2B prospects could be deleted three years after the last active contact.^{5, 6} Use that example as the rule's format, then set the actual period through your own documented policy.

Validate a reset before extending retention

Activity can extend a record's life, but it should reset the clock only when it is a genuine refresh. A record that was merely opened, copied, or touched by an automated process does not qualify on that basis alone.

A refresh can reset the retention clock when you verify that the contact details remain current and the person remains in the same role, treat the refresh as a new data-collection event, and document it.⁷ Store the verification date, what you checked, and the rule that allows the reset. If those details are missing, keep the original trigger date for the review.

Use inactivity as a review queue. A dynamic list can check for inactivity.⁸ A documented workflow identifies prospects that have been in the system for more than a year without an email through two lists.⁹ The queue tells you which records to inspect. It does not decide deletion until you apply the retention rule and check for a valid reset.

Separate requests from retention events

A request can change the action before the retention period expires. Capture the request type and route it separately from the ordinary inactivity review. An opt-out, a deletion request, and a restriction on data circulation can lead to different outcomes.

Companies are expected to explain what they collect, provide an opt-out mechanism, and honor opt-out requests.¹⁰ In Account Engagement, prospect records have an "Opted Out" field, while Salesforce uses "Email Opt Out" on Lead and Contact records.^{11, 12} The Account Engagement field is intended for prospects to control through an unsubscribe link or an email preference center.¹³

Keep the field meaning visible in your trigger rule. After the fields were decoupled, setting "Opted Out" to true no longer changes "Do Not Email".¹⁴ A field change can signal a communication preference without proving that the underlying prospect record has reached its deletion point.

Centralized requests need their own handling path. California residents can submit centralized deletion requests across the registered data broker market as of January 1, 2026.¹⁵ DROP leaves data in internal systems while restricting whether personal data can continue to be sold, shared, enriched, or resold.¹⁶ Record which outcome the request requires, then apply it to the systems and processes in scope.

Run and verify the deletion action

Once the trigger, date, and request status are clear, execute the action against the correct record and inspect what the system did. A completed workflow should leave a trace of the trigger, the rule applied, the action taken, and the resulting system state.

Check whether the platform's delete action is permanent or moves the record into a holding area. In Account Engagement, prospects can be placed in the recycle bin, where the information remains and can be retrieved, and the bin cannot be emptied.^{17, 18, 19, 20} Treat that state as different from final deletion in your workflow and documentation.

If the record is still present after the action, identify whether it is retained for recovery, still active in another list, or covered by a separate request restriction. Do not close the review until the observed state matches the action your rule requires.

What not to do

These mistakes can make a trigger look complete while the underlying record still needs a decision.

• Do not let an inactivity list erase the original trigger date. Use the list to find candidates, then confirm the event, any documented refresh, and the rule that applies.
• Do not treat a recycle bin as final deletion. Its contents can remain available for retrieval and the bin may have no empty action.^{18, 19, 20}
• Do not treat every request as an internal deletion instruction. A restriction can govern sale, sharing, enrichment, or resale while the data remains in internal systems.¹⁶