What are limitations of Free version? How does it differs from Full Paid Version?

Free-version is a limited version and valid for 15 days. After 15 days, application will automatically get locked. In Free Version - user can bulk create only 30 fields, but in Full version there is NO limits. - user can bulk delete only 10 fields, but in Full version there is NO limits.

How many salesforce users can use BOFC within an org?

BOFC is an org based app. We have no limit on users within an org.

What does Licence Portability mean?

In case user want to use same licence key for multiple clients, then he can use the key in first client org, after work is finished, this key can disabled from first client org and can be used in next client org.

Which payment methods do you accept?

BOFC accepts online payments via Credit Card, Debit Card, Netbanking and Paypal. To pay by check, wire transfer or ACH, please call +91 9953170767.

How can I reach out for support and service?

We have a dedicated team of customer support & service available 24 * 7. You can simply contact us via Email, Phone Support and Quick Response.

Can I upgrade my plan at any time?

You can upgrade at any time. For this, you can write to our sales department at sales@tech9logy.com or call at +91 9953170767 to see how it works for your business.

Salesforce Org Cleanup, Step by Step: A Full Pre-Checklist

Published: Sep 24 2026

Most Salesforce org cleanups start the same way: someone notices clutter, picks a category, and starts deleting. That approach works fine for a small org with a year or two of history. It falls apart fast once an org has real age on it, because categories interact. A field flagged for removal might be feeding a report someone still relies on. A user flagged as inactive might be the reason a sharing rule still exists.

This is the sequence that actually holds up on a larger org: define scope first, inventory before you touch anything, analyze dependencies properly, then execute in a deliberate order rather than category by category as clutter catches your eye.

01

step 1

Define the scope before you start

Before opening a single object, decide what this cleanup actually covers. A full org cleanup and a targeted cleanup of one business unit’s custom objects are different projects with different risk profiles, and treating them the same way is how scope creeps until the project stalls.

Set a clear boundary: which objects, which business processes, which time period of inactivity counts as “unused.” Write this down before you start, not because it needs to be formal, but because it’s the reference point you’ll need when someone asks why a particular field wasn’t touched.

02

step 2

Build a full inventory before touching anything

Pull a complete list of what exists in the scope you defined: fields, objects, automation, users, permission sets, connected apps, and reports. Work from an actual exported inventory, not from memory or by scrolling through Setup screens as you go. A tool like BOFC can pull this kind of bulk metadata export across an entire org in one pass, which is the difference between an inventory that’s actually complete and one that quietly misses whatever didn’t come to mind while clicking through Setup.

This step feels slow compared to just diving in, but it’s what prevents the most common cleanup failure: deleting something, then discovering later that it wasn’t on anyone’s radar because nobody had a full list to check it against in the first place.

03

step 3

Check usage before assuming anything is unused

With the inventory built, pull usage data for each category. Field population percentages, login history for users, run history for Flows and scheduled jobs, view counts for reports. Usage data narrows the list, but it doesn’t finish the job on its own. A field can show near-zero population and still be exactly the field a specific team or process depends on in an infrequent but critical scenario.

Treat this step as a filter that produces a shorter, “needs closer investigation” list, not a final decision on what’s safe to remove.

step 4

Check dependencies on everything that survives Step 3

This is the step most cleanups skip, because it’s the most tedious to do manually. Everything that made it past the usage filter needs to be checked against what actually references it: Flows, validation rules, Apex, formula fields, page layouts, reports, and any external system that might reference a field by its API name rather than through the UI.

Skipping this step is how a field with 2% population turns out to be the exact field an integration has queried every night for the past three years. Nothing about the usage numbers would have told you that. This is also the step BOFC was built to make less painful, exporting fields, validation rules, and record types into a documented base you can actually cross-check dependencies against, instead of opening each component individually to see what references it.

05

step 5

Prioritize by risk, not by what’s easiest to delete

Once you know what’s actually safe to remove, resist the urge to start with whatever’s quickest. Order the work by risk instead. Low-risk items, zero population, zero dependencies, no assigned users, go first. Anything with partial usage, ambiguous dependencies, or connections to reporting goes last, and gets more scrutiny along the way.

This ordering matters because early wins on low-risk items build confidence in the process, while starting with a borderline item and getting it wrong early can stall the entire cleanup out of caution.

06

step 6

Deactivate before you delete

Wherever Salesforce allows it, deactivate before removing something permanently. Turn off a Flow instead of deleting it. Remove a permission set assignment before deleting the permission set itself. Give each deactivation a real observation window, ideally covering at least one full business cycle, monthly close, a full sales cycle, whatever’s relevant to what you’re touching, before making the change permanent.

This step is what turns a mistake into a two-minute fix instead of a rebuild. A deactivated Flow can be turned back on instantly if something breaks. A deleted one has to be reconstructed from scratch.

07

step 7

Communicate before you execute, not after something breaks

Tell the teams affected by upcoming changes before you make them, especially anything touching reports, dashboards, or fields visible to end users. This isn’t just a courtesy. Users often know whether something matters operationally in a way that technical dependency checks can’t fully capture, since not every real use case leaves a technical trace.

A short heads-up before a change goes out is far cheaper than an incident conversation after it does.

08

step 8

Execute in phases, not all at once

Even with a fully vetted list, don’t run the entire cleanup in a single pass. Work through it in phases, aligned to the risk ordering from Step 5, and confirm each phase is stable before starting the next. This keeps a mistake contained to a small, identifiable batch of changes instead of buried somewhere in a much larger one.

09

step 9

Document what changed and why

For every item removed or deactivated, log what it was, why it was flagged, what the dependency check found, and when it happened. This isn’t extra overhead. It’s the difference between a future admin understanding a decision that was made and a future admin having no idea why something that used to exist is now gone.

10

step 10

Review the org again after the dust settles

A cleanup isn’t a one-time event. Config drift and clutter accumulate continuously, which means an org that’s clean today won’t stay that way indefinitely. Set a recurring review, annually at minimum, so the next cleanup starts from a much shorter list instead of repeating this entire process from scratch.

Conclusion

None of these ten steps are complicated on their own. What makes org cleanup risky isn’t any single step, it’s skipping the order: deleting before inventorying, assuming before checking dependencies, executing everything in one pass instead of in phases. Followed in sequence, this turns cleanup from a project admins put off out of caution into something that can run predictably, on a schedule, without the fear of breaking something nobody saw coming.