If your CRM has ever made you question your career choices, your life decisions, or humanity as a whole…

good news: these problems didn’t appear magically. Someone built them.

Let’s explore Part 1: Data Entry & Structure Disasters (Points 1–6)—the foundational mistakes that turn elegant Salesforce orgs into accidental obstacle courses.

Stay with me… this is the fun part.

Data Entry & Structure Disaster

#1 — Make Every Field Required

Or, even better… make none of them required

Rephrased Rule of Chaos: The Mandatory Field Mess

Nothing screams “data quality excellence” like a Lead record with 22 blank fields, or an Opportunity that forces users to fill a 12-field business case just to log a phone call.

Example of What Not To Do:

Imagine forcing reps to fill out “Preferred Shipping Vendor Country of Origin” before they can save a new lead. Because yes—every lead knows that about themselves.

Or the opposite: let nothing be required. Leave it all to chance. Let reps save leads with names like “asdf” and emails like “test@test.test”.

The Correct Approach:

Make only the right fields required, and only at the right stage.

Guide the user; don’t punish them.

#2 — Encourage 3–4 Duplicates of Everything

Rephrased Rule of Chaos: Embrace Redundancy as a Backup Strategy

Who needs a single source of truth when you can have:

• Ahmed Sales,
• Ahmed S.,
• Mr. Ahmed (Sales),
• A7med Sales

…all representing the same human?

Example of What Not To Do:

Create an Account for “Sony”.

Then another for “SONY”.

Then another for “Sony Electronics”.

Then another because the rep was in a hurry and missed the first three.

Users will love spending half their day guessing which record is the “real one.”

The Correct Approach:

Use:

• Matching rules
• Duplicate rules
• Data stewardship
• Standard naming conventions

You know—basic sanity.

#3 — Create Custom Objects for Everything, Even Petty Things

Rephrased Rule of Chaos: Object Bloat Syndrome

Why use a field or a standard object when you could create:

• A Custom Object to store “Salesperson Mood of the Day”?
• Another one to store “Contracts Pending Review but Not Really”?
• One more for “Notes That Could Have Been Tasks”?

Example of What Not To Do:

A real-world scenario I’ve seen:

A team created five separate custom objects just to track different types of discount approvals—each one with identical fields, workflows, and validation rules.

By the time the audit came, even the architect couldn’t explain why.

The Correct Approach:

Before creating a custom object, ask yourself:

“Would a field, picklist, or related list solve this?”

If the answer is yes—congratulations, you’ve saved future admins from suffering.

#4 — Use Multi-Select Picklists Everywhere

Rephrased Rule of Chaos: The Picklist Trap

Multi-select picklists look harmless until…

you try to report on them.

Or filter them.

Or sync them.

Or integrate them.

Or export them.

Basically, until you try to use them for anything other than looking pretty on the screen.

Example of What Not To Do:

A “Customer Intentions” field with options like:

• Buy Soon
• Maybe Later
• Negotiating
• Wants a Discount
• Waiting for Manager
• Not Interested
• Ghosting
• Doesn’t Respond but Reads Messages
• …and all multi-select.

What does reporting see?

A nightmare string of semicolon-separated chaos.

The Correct Approach:

Use:

• Regular picklists
• Checkbox groups
• Junction objects
• Anything else, really

Save multi-select picklists for when you absolutely have no other logical option (rare).

#5 — Add 30+ Deal Stages for “Accuracy”

Rephrased Rule of Chaos: Opportunity Stage Overkill

Because what sales rep doesn’t want to select between:

• Initial Contact Attempt #1
• Initial Contact Attempt #2
• Initial Contact Attempt #3
• Customer Slightly Interested
• Customer Somewhat Interested
• Customer Mildly Interested but Unreachable

…and 25 more?

Example of What Not To Do:

Having a stage called “Manager Reviewing the Proposal for Regional Alignment Approval (South)”—just for one region, one team.

The Correct Approach:

Keep stages simple, like:

• Qualification
• Discovery
• Proposal
• Negotiation
• Closed Won / Closed Lost

Use sub-stages, guidance for success, or paths for extra detail—not the stage picklist.

#6 — Say Yes to Every Feature Request

Rephrased Rule of Chaos: Unfiltered Feature Creep

If one user asks, “Can we add a custom field for the client’s favorite dessert?”—you should definitely say yes.

And if someone else wants a checkbox for “Has Cat?”—add that too.

Soon your Account object will look like a Netflix login page: infinite scrolling and no end in sight.

Example of What Not To Do:

A real example:

A company created 96 custom fields on Opportunity, many used by only one single user… who later left the company.

Half of them were just “Future Use 1, Future Use 2…”

The Correct Approach:

Establish a governance process:

• Review requests
• Validate business impact
• Decline non-value additions
• Prioritize using a framework

Admins should guide, not obey blindly.