Data 360 data retention: expiring Data Lake Objects with no toggle in Setup

An admin goes looking for the retention screen in Data 360 and never finds it. They have watched a web-engagement stream pour clickstream into the lake for months, they know most of it is dead weight, and they assume there is a policy toggle in Setup the way there is on a Marketing Cloud data extension. There isn’t.

The data keeps landing and the lake keeps growing. The one lever that looks relevant, the right-to-be-forgotten flow, is built to erase one person, not to expire a year of events.

So, the part worth knowing before you promise anyone a cleanup date. Retention in Data 360 is a lifecycle policy attached to a single Data Lake Object. You request it through a Salesforce support case, not a screen, it applies only to Engagement objects, and it deletes rows by comparing them against the Event Time Field you chose when you built the stream.

That last detail is the one that bites. Point it at the wrong timestamp and the policy deletes records that are not old at all.

One naming note. Data Cloud was renamed Data 360 in October 2025, but the APIs, object suffixes, and much of the Help content still say data-cloud and c360. Both names mean the same platform, and you will see them mixed together.

The lake keeps everything until you tell it not to

Start with the default, because it surprises people: a Data Lake Object retains its data indefinitely. Nothing ages out on its own. A data stream lands rows into a DLO, and those rows sit there until you take deliberate action to remove them.

That behaviour is fine for a profile object with a bounded number of customers. Engagement data is a different story, because it is unbounded by design. Web events, app opens, email interactions, order-line events all arrive continuously and never stop.

The fraction of that stream you need for live segmentation or a calculated insight is usually the last few weeks or months. The long tail behind that window is storage you are keeping for no operational reason.

Two mechanisms sound like they should solve this and don’t. The right-to-be-forgotten deletion flow erases the data tied to a specific individual on request, which is a compliance obligation, not a volume tool.

Deleting the data stream doesn’t purge the DLO either. Since the Winter ‘22 decoupling of streams from lake objects, the DLO and its data survive after the stream that fed it is gone. The object outlives the pipe, and you are left with a lake object full of history and no obvious way to trim it.

Retention is a lifecycle policy on the DLO, requested by case

The mechanism is a backend retention setting applied per Data Lake Object. As of this writing there is no self-service UI for it. Salesforce’s Help article on the feature describes the process as logging a Data 360 support case and handing the engineer three things:

The DLO developer name, the exact API name ending in __dll. Not the label you see in the UI, the API name.
The retention period in days. Give a number of days, not “one year” or “12 months”. A year is 365.
The Event Time Field on that DLO the purge should measure against.

Once the policy is in place, the engine evaluates every row against that timestamp field. Rows whose event time is older than the retention window get deleted, along with the metadata table partitions behind them.

The floor is seven days. A retention period shorter than a week, say one day, is not supported, so you cannot use this to keep a staging object trimmed to the last few hours.

The support-case dependency carries a cost that is easy to miss. There is no version-controlled artifact for a retention policy: no line in a sfdx project, nothing in your metadata that says “this DLO expires at 90 days”.

If you don’t document the policies you have requested, the only record they exist is a closed case and the behaviour of the data. Keep your own register: object, retention days, event-time field, date requested. Treat it like any other infrastructure that lives outside source control.

The Event Time Field is the whole game

The setting that decides whether retention helps you or hurts you is which timestamp it measures against. To see why, you have to know how Data 360 categorises objects.

Every DLO and its stream carry one of three categories: Profile (people and accounts), Engagement (time-series events), or Other (reference data like a product catalogue).

When you map a stream as Engagement, Data 360 requires you to designate an Event Time Field, the column stating when the event happened, an EventDate or EventTimestamp on the record. That column is not decoration, it is what makes the object a time series, and the retention purge keys off exactly it.

Retention applies only to Engagement DLOs. You cannot put a policy on a Profile DLO, on a Data Model Object, or on an Other-category object. The reason falls straight out of the design: those objects have no single canonical event time to measure age against. A customer profile is not “old” the way a click from March is old. The feature is scoped to the one category where “expire everything before date X” is a meaningful instruction.

Now the failure mode. The Event Time Field has to represent when the event occurred, not when the row was last touched. Point retention at a last-modified or ingestion-adjacent timestamp and two bad things happen.

A record that keeps getting updated stays “young” forever and never expires. And a backfill of genuinely old events, loaded today but stamped with an event time from two years ago, gets deleted the moment the policy runs, because by its event time it is already past the window. Neither is what you meant.

The field is set at stream-creation time and is awkward to change afterward, so this is a design decision you make early and live with. Choose the field that answers “when did this happen in the real world”, and confirm it before the object has a year of data mapped to the wrong column.

The credit assumption it overturns

Teams often build the business case on the wrong premise. The intuition is that trimming the lake cuts the Data 360 credit bill, so retention gets pitched as a cost-savings project.

Salesforce is explicit that it isn’t one. The Help article states that applying data retention settings to your DLOs does not affect your Data Cloud credit consumption. Retention reduces stored data volume, which is a governance and storage win and can matter for your storage entitlement. The purge itself is not billed, and it does not move the meter your credit consumption is measured on. Processing, queries, and activations draw credits; deleting old rows does not.

Frame it correctly with whoever funds the work. Retention keeps the lake honest, shrinks the surface a query can accidentally scan, and holds less personal data than you need. Those are worth doing. It is not a line item that pays for itself in credits, and pitching it that way sets up a disappointment when the consumption dashboard looks the same next month.

What retention does not reach

A retention policy trims one lake object. It does not cascade. The rows you delete from the Engagement DLO may already have been consumed upstream into Data Model Objects, calculated insights, activated audiences, or copied into a downstream warehouse. Expiring the source does not rewrite those derived layers, and each has its own lifecycle you have to reason about separately.

The mental model is narrow on purpose. Retention answers one question, “how long does raw event data live in this lake object”, and answers it well. It does not answer “how long does a derived metric live” or “what happens to the copy I activated into an ad platform”. Treating a DLO retention policy as if it garbage-collects the whole downstream graph is how you end up surprised that a two-year-old insight still references events you thought you deleted.

The order of operations that avoids the mistakes

Put together, the safe sequence looks like this:

Confirm the object is Engagement. If it isn’t, retention doesn’t apply, and the real question is why unbounded time-series data is landing in a Profile or Other object.
Verify the Event Time Field is a true event time. Read the mapping and make sure it is when-it-happened, not when-it-was-touched. This step is what prevents deleting the wrong rows.
Pick a retention period at or above seven days, in days, that matches how far back your live segments and insights actually look. If your longest lookback insight needs 90 days, don’t set 30.
File the Data 360 support case with the __dll developer name, the period in days, and the event-time field. Record all three in your own policy register.
Account for the derived layers separately. Note which DMOs, insights, and activations draw from this object, and decide their retention on their own terms.

Do those five in order and retention becomes a boring, reliable piece of your governance. Skip step two and the first run of the policy is the day you learn which timestamp it was really measuring.

Understanding the basics

How do I delete old data from a Data Lake Object in Data 360?

You request a backend retention policy through a Data 360 support case; there is no self-service UI as of this writing. You provide the DLO’s developer name (the API name ending in __dll), a retention period in days, and the Event Time Field to measure against. The engine then deletes rows whose event time is older than the window, minimum seven days. Deleting the data stream does not do this, because since the Winter ‘22 decoupling the lake object and its data survive the stream.

Does data in a Data Lake Object expire automatically?

No. By default a DLO retains its data indefinitely, and nothing ages out until you apply a retention policy to that object. This matters most for Engagement objects, which take in unbounded time-series data such as web and app events, so the lake grows without limit unless you set a window.

Does setting DLO retention reduce my Data 360 credit consumption?

No. Salesforce states that applying data retention settings to your DLOs does not affect Data Cloud credit consumption. Retention reduces stored data volume, which is a governance and storage benefit, but the purge is not billed and does not lower the consumption your credits are measured on. Treat it as data hygiene, not a cost lever.

Can I set retention on a Data Model Object or a profile object?

No. Retention applies only to Engagement-category Data Lake Objects, because those carry an Event Time Field that defines record age. Data Model Objects, Profile DLOs, and Other-category objects are out of scope. Limiting data in those layers is a separate design task handled on each layer’s own terms.

What is the difference between DLO retention and right to be forgotten?

Retention expires all rows in an Engagement object past a time window, for volume and hygiene. Right to be forgotten erases the data associated with a specific individual on request, for compliance. One is a scheduled, object-level purge keyed to event time; the other is a targeted, person-level deletion. Most orgs need both, for different reasons.

Trying to work out which lake objects should expire, which timestamp the purge should trust, and how retention fits the rest of your governance model? Talk to us. Getting the data foundation to hold only what it should, and prove it, is the part of a Data 360 build that keeps you out of trouble later.