The Day Custom Objects Ruined My Plan (And What You Can Learn from It)

Let me tell you about something that happened to me recently. It’s one of those stories that you don’t want to live through—but you’ll be happy someone else did and is now writing about it.

I was working on a Salesforce project and, as you probably know, sometimes System Objects just aren’t enough. That’s when we create Custom Objects to fill in the gaps. Simple, right?

Well, Custom Objects have three key settings that you really need to pay attention to.

1️⃣ First one: Retention.
This defines how long your Custom Object instances stay in the system before being automatically deleted. Salesforce has a quota—400,000 Custom Object instances. So, if you forget to set a retention period, you might hit that limit faster than you think.

2️⃣ Second: Replicable.
If this isn’t checked, your Custom Object won’t be moved between environments during data replication (staging to production, for example). And no, you can’t just change that setting later. You’ll have to delete the Custom Object type, recreate it, and reload all your data. Fun times? Not really.

3️⃣ Third: Storage Scope.
This defines whether the Custom Object is linked to a site or is global to your organization. I didn’t think much of this one until I scheduled nightly data replications… and the objects never showed up in production. Why? Because I had selected Organization storage, but forgot to tick the right box in the replication settings.

Result: no data in prod, lots of frustration, and a lesson I won’t forget.

So here’s my advice:

• Always decide upfront if your object will need to be replicated.

• Choose your storage type carefully (Site or Organization).

• Don’t skip retention—it might save you later.

I messed it up so you don’t have to.

👉 If you’re new to SFCC B2C or want to seriously level up, check out this intro course I recommend:
https://www.sfcclearning.com/course-detail/salesforce-b2c-commerce-introduction-course/22173