Your follow-up guide to building the kind of Salesforce org that guarantees sleepless nights, finger-pointing, and dashboards that cry for help.

If Part 1 showed you how to sabotage your CRM through data structure, Part 2 takes the chaos a step further. We now enter the realm of administration, access, maintenance—or the lack thereof.

These are the kinds of decisions that don’t just annoy users…

They create legacy problems so legendary that future admins will write stories about them.

Let’s continue our journey of “What You Should Absolutely Never Do If You Want to Love Your CRM.”

7. Give everyone System Admin permissions

The Wild West Permissions Model

Why thoughtfully design roles and profiles when you can give everybody God-Mode?

Let every user, intern, and visiting consultant wield the power to delete objects on a whim.

What could possibly go wrong?

Real Example of Chaos

• A sales rep accidentally deactivates key validation rules “because they were annoying.”
• Someone edits the Opportunity Stage picklist in production at 4 PM on a quarter-closing day.
• Someone clones the standard “Admin” profile… and names it “Sales Team.”

What You Should Do Instead

Follow least-privilege design.

Define profiles, permission sets, and permission set groups with surgical precision.

Admin access should be earned—not freely distributed like stickers.

8. Have the whole team share a single login

The Single Shared Account Nightmare

Why bother with user accounts when one generic login can serve all departments?

Audit trails? Compliance? Accountability?

Trivial concerns—until something breaks and nobody knows who modified what.

Real Example of Chaos

• A workflow rule disappears. Five team members swear “it wasn’t me.”
• Security review fails instantly because the login history shows 27 users “logging in” from different cities at once.
• Password changes become group events.

What You Should Do Instead

Every user needs their own account.

Always. No exceptions.

Your org (and your sanity) depends on it.

9. Avoid the Sandbox at all costs. Ship everything directly in Production.

The Production-Only Development Method

Testing? Who needs testing?

Why validate solutions in a safe environment when you can deploy directly into the live system and see what breaks in real time?

Real Example of Chaos

• A trigger loops endlessly and locks every Opportunity.
• You try to roll back—but your rollback is also broken because it was never tested.
• Management wants to know why the system is down. You point at the mirror.

What You Should Do Instead

Use sandboxes.

Use them deeply.

Use them often.

Treat production like a museum exhibit: look, don’t touch.

10. Never clean it up now—always promise to do it later

The Perpetual Deferral of Maintenance

Technical debt is like actual debt: the longer you ignore it, the more painful it becomes.

But sure—skip data cleansing, rule audits, and archival efforts.

Let future you handle it… or let future admins curse your name.

Real Example of Chaos

• 98,000 contacts with missing emails.
• 17 different lead sources, including “Other,” “Others,” “Other Source,” and “othr.”
• A validation rule last updated “5 years ago” that no one remembers writing.

What You Should Do Instead

Schedule periodic cleansing, implement data stewardship processes, and review automation annually.

Maintenance isn’t optional; it’s survival.

11. Don’t build any CRM health dashboards

The Ignorance Is Bliss Approach

If you never track data quality issues…

Then those issues technically don’t exist, right?

If you don’t measure orphaned records, missing owners, broken automation, or stalled approvals…

Then users can’t blame you for knowing about them.

Real Example of Chaos

• Thousands of Opportunities stuck in “Closed Lost” with no closed reason.
• Accounts without owners… for years.
• A dashboard showing 0 problems—because there is no dashboard.

What You Should Do Instead

Build data health dashboards.

Monitor field completeness, record ownership, activity logging, and process exceptions.

Trust me: you want to see problems before your CEO does.

12. Ignore user training and documentation

The “They’ll Figure It Out” Philosophy

Why train users when you can assume they’ll magically understand Salesforce?

Why create guides when tribal knowledge is so much more… mysterious?

Real Example of Chaos

• Users create Opportunities without Accounts.
• Someone asks, “What’s a report type?”
• A team member tries to delete a dashboard because they thought it was “just clutter.”

What You Should Do Instead

Train your users. Document your processes. Create accessible learning paths.

CRM adoption depends on understanding—not hope.

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.