Tweet Library

Ready-to-Post Content

Pre-written tweets for each mistake and tool. Just click, copy, and post.

50 mistake tweets • 35 tool tweets • One-click copy

#1 — The Infinite Flow Loop That Ate Production

I crashed an entire Salesforce org with a 3-node Flow.

Record-triggered flow → updates same record → triggers itself → infinite loop → org locked.

Mistake #1 in my graveyard:
https://glenbradford.com/salesforce/mistakes/recursive-flow-infinite-loop

Tweet250 chars

#2 — Get Records Inside a Loop: The Governor Limit Speedrun

Get Records inside a Flow loop is the #1 admin mistake I see.

15 records in sandbox? Works great.
101 records in prod? Governor limit. Crash.

The fix is embarrassingly simple:
https://glenbradford.com/salesforce/mistakes/flow-soql-inside-loop

Tweet244 chars

#3 — The Flow With No Fault Path (Enjoy Your Cryptic Error)

"An unhandled fault has occurred in this flow"

If your users see this, that's YOUR fault.

Every DML element needs a fault path. Every callout needs a fault path. No exceptions.
https://glenbradford.com/salesforce/mistakes/flow-no-fault-path

Tweet242 chars

#4 — Hardcoded Record IDs in Flows: The Sandbox Surprise

Hardcoded a Record Type ID in a Flow.

Worked in sandbox.
Deployed to prod.
Different ID.
Silent failure for 2 days.

Never. Hardcode. Salesforce IDs.
https://glenbradford.com/salesforce/mistakes/flow-hardcoded-record-ids

Tweet221 chars

#5 — Using After-Save When Before-Save Would Do

Before-save flows: FREE (zero DML)
After-save flows: costs DML per record

If you're only updating the triggering record, before-save is always the answer.

I learned this the expensive way:
https://glenbradford.com/salesforce/mistakes/flow-before-vs-after-save

Tweet261 chars

#6 — SOQL Query Inside a For Loop (The Classic)

SOQL inside a for loop.

The most common Apex mistake. The most preventable governor limit.

Collect IDs → query ONCE → use a Map.

I learned it the hard way so you don't have to:
https://glenbradford.com/salesforce/mistakes/soql-query-in-for-loop

Tweet247 chars

#7 — Test Class That Only Tests One Record

My test class had 100% coverage.

It tested exactly 1 record.

The trigger failed on 200 records in production.

100% coverage means nothing if you don't test bulk.
https://glenbradford.com/salesforce/mistakes/no-test-class-bulk

Tweet228 chars

#8 — Mixed DML: Setup and Non-Setup Objects in the Same Transaction

MIXED_DML_OPERATION

You can't insert a User and an Account in the same transaction.

I stared at this error for 20 minutes before learning about setup vs non-setup objects.
https://glenbradford.com/salesforce/mistakes/mixed-dml-operations

Tweet239 chars

#9 — All Logic in the Trigger Body (No Handler Class)

300 lines of logic in a trigger body.

No handler class. No separation of concerns. No way to test individual methods.

Six months later I had to rewrite the whole thing.

Use. A. Handler. Pattern.
https://glenbradford.com/salesforce/mistakes/trigger-without-handler

Tweet266 chars

#10 — Flying Blind Without the Limits Class

Your Apex code doesn't run in isolation.

Process Builders, Flows, other triggers — they all share the same governor limits in a transaction.

Limits.getQueries() is your friend. Use it.
https://glenbradford.com/salesforce/mistakes/not-using-limits-class

Tweet254 chars

#11 — Mass Update With No Backup: The 'Undo' Button That Doesn't Exist

Mass updated 50,000 records without a backup.

Blanked every BillingAddress.

Client: "Just undo it."
Me: "..."

There is no undo. Export before you update. Always.
https://glenbradford.com/salesforce/mistakes/data-loader-without-backup

Tweet236 chars

#12 — No Duplicate Rules: 14,000 Duplicate Accounts Later

"We'll set up duplicate rules in Phase 2."

Phase 2 never came.

14,000 Accounts. 4,000 duplicates. 3 months to clean up.

Set up duplicate rules on Day 1. Every org.
https://glenbradford.com/salesforce/mistakes/duplicate-data-no-matching-rules

Tweet244 chars

#13 — Hard Delete When Soft Delete Would Do

Hard Delete in Data Loader bypasses the Recycle Bin.

Permanent. No undo. No recovery.

800 real Opportunities, gone.

Always soft delete first. Verify. Then hard delete if needed.
https://glenbradford.com/salesforce/mistakes/delete-without-recycle-bin-check

Tweet258 chars

#14 — Data Loader Pointed at Production Instead of Sandbox

Data Loader defaults to production.

Forgot to check the Sandbox box.

30,000 Contacts updated with test data.

In production.

On a Friday.

Before a campaign.

Always. Verify. Your. Org.
https://glenbradford.com/salesforce/mistakes/data-loader-wrong-environment

Tweet263 chars

#15 — 10,000 Records Pointing to One Parent: Hello, Lock Errors

UNABLE_TO_LOCK_ROW

10,000 records under one parent Account.

Every batch job fighting to lock the same record.

Salesforce calls it "lookup skew." I call it a nightmare.
https://glenbradford.com/salesforce/mistakes/lookup-skew

Tweet227 chars

#16 — 5 Process Builders, 3 Flows, 2 Triggers on One Object

5 Process Builders. 3 Flows. 2 Triggers.

All on one object. Built by 3 different consultants.

"Opportunities keep changing Stage randomly."

Yeah, I bet.
https://glenbradford.com/salesforce/mistakes/too-many-automations-one-object

Tweet232 chars

#17 — Building Custom Objects When Standard Objects Already Exist

I spent 3 weeks building custom objects for project tracking.

Salesforce already had Tasks, Cases, and Events.

Always check standard objects FIRST.

Custom objects lose Activity Timeline, Einstein, mobile — for free.
https://glenbradford.com/salesforce/mistakes/custom-object-for-everything

Tweet292 chars

#18 — Hardcoded Config Values Instead of Custom Metadata Types

"Why does changing a number take 2 weeks?"

Because I hardcoded it in Apex.

Custom Metadata Types: admin-editable, deployable, cached, no SOQL.

Stop hardcoding config values.
https://glenbradford.com/salesforce/mistakes/no-custom-metadata-types

Tweet246 chars

#19 — The God Object: One Custom Object to Rule Them All

One custom object. 200 fields. 3 Record Types.

Projects, Invoices, and Timesheets crammed into one object.

70% of fields blank on every record.

Record Types are for variants, not different entities.
https://glenbradford.com/salesforce/mistakes/god-object-pattern

Tweet265 chars

#20 — No Naming Convention: The Org That Named Itself

Status__c
Status_New__c
Status_v2__c
StatusFinal__c
Contact_Status__c

All on the same object. No naming convention.

Establish one on Day 1 or your org names itself.
https://glenbradford.com/salesforce/mistakes/no-naming-convention

Tweet232 chars

#21 — Forgot 'with sharing': Every User Could See Everything

Forgot 'with sharing' on an Apex class.

Every user could see every Opportunity in the org.

All sharing rules bypassed. Role hierarchy ignored.

One missing keyword. Total data exposure.
https://glenbradford.com/salesforce/mistakes/without-sharing-keyword

Tweet256 chars

#22 — String Concatenation in SOQL: Hello, Injection

SOQL injection is real.

"It's SOQL not SQL, it's fine."

It's not fine. User input + string concatenation = data exposure.

Use bind variables. Always.
https://glenbradford.com/salesforce/mistakes/soql-injection

Tweet212 chars

#23 — Gave Everyone 'Modify All' Because It Fixed the Bug

User: "I can't edit this record."

Wrong fix: Give Modify All.
Right fix: Fix sharing rules.

"Modify All" is never the answer to a sharing problem.
https://glenbradford.com/salesforce/mistakes/profile-permissions-too-broad

Tweet223 chars

#24 — API Keys Hardcoded in Apex: Now in Version Control Forever

Hardcoded an API key in Apex.

Committed to Git.
Deployed to production.
Visible to every developer forever.

Named Credentials exist for exactly this reason.
https://glenbradford.com/salesforce/mistakes/api-key-in-apex-code

Tweet224 chars

#25 — New Field Visible to Everyone: Forgot Field-Level Security

Created a Salary field. Made it visible to all profiles.

"I'll fix permissions later."

Three weeks later, sales reps could see everyone's salary.

Default to hidden. Use Permission Sets.
https://glenbradford.com/salesforce/mistakes/field-level-security-forgotten

Tweet264 chars

#26 — Making a Callout from a Trigger

I tried making an HTTP callout directly from a trigger. Salesforce said no. 200 records failed.

Here's the async pattern that actually works:
https://glenbradford.com/salesforce/mistakes/callout-from-trigger

Tweet208 chars

#27 — Hardcoding API Credentials Instead of Using Named Credentials

I hardcoded a Stripe API key in an Apex class. The security team found it in 3 sandboxes and version control.

Named Credentials exist for a reason:
https://glenbradford.com/salesforce/mistakes/no-named-credentials

Tweet214 chars

#28 — No Retry Logic on External API Calls

My Salesforce-to-ERP sync had zero retry logic. The ERP went down for 2 minutes. 400 records vanished into the void.

Always retry + log:
https://glenbradford.com/salesforce/mistakes/no-retry-logic

Tweet197 chars

#29 — Publishing Platform Events Without Error Handling

Platform Events aren't truly fire-and-forget. I lost half my downstream automations because I never checked EventBus.publish results.

https://glenbradford.com/salesforce/mistakes/platform-event-no-error-handling

Tweet212 chars

#30 — Using the Same Connected App Across All Environments

A dev in sandbox triggered our payment integration. Against the PRODUCTION endpoint. Real charges to real customers.

Always separate credentials per environment:
https://glenbradford.com/salesforce/mistakes/mixed-up-connected-app-environments

Tweet243 chars

#31 — Deploying to Production on Friday Afternoon

I deployed to Salesforce production at 4 PM on a Friday. 3,000 contacts lost their email addresses by Saturday morning.

Here's my deployment checklist now:
https://glenbradford.com/salesforce/mistakes/deploying-friday-afternoon

Tweet228 chars

#32 — Deploying Apex Without Including the Test Class

Deployed my Apex class to production but forgot the test class. Coverage dropped below 75% and I couldn't deploy anything else.

Always deploy in pairs:
https://glenbradford.com/salesforce/mistakes/forgot-test-class-in-deploy

Tweet225 chars

#33 — Running Destructive Changes Before Deploying Replacements

I ran destructive-changes.xml BEFORE deploying the replacement. Cascading deletes wiped fields, flows, and validation rules.

3 days to recover.

https://glenbradford.com/salesforce/mistakes/destructive-changes-wrong-order

Tweet222 chars

#34 — Skipping Sandbox and Deploying Straight to Production

"It's just a formula field." I deployed straight to production. It referenced a field that had been deleted.

Every Account page errored out.

https://glenbradford.com/salesforce/mistakes/no-sandbox-testing

Tweet206 chars

#35 — Force-Pushing Source That Overwrites Production Customizations

I deployed my stale local source to production and wiped out 5 fields an admin had created.

Always retrieve from prod BEFORE deploying:
https://glenbradford.com/salesforce/mistakes/overwriting-production-metadata

Tweet213 chars

#36 — Mixing Wire and Imperative Apex Calls for the Same Data

My LWC datatable flickered between old and new data because I mixed @wire and imperative Apex calls.

Use refreshApex() instead:
https://glenbradford.com/salesforce/mistakes/lwc-wire-imperative-mix

Tweet197 chars

#37 — Calling querySelector Before the Component Renders

this.template.querySelector() in connectedCallback returns null every time. The DOM doesn't exist yet.

Use renderedCallback instead:
https://glenbradford.com/salesforce/mistakes/lwc-queryselector-before-render

Tweet210 chars

#38 — Mutating Objects Without Triggering Reactivity

Mutated an object property in LWC. The UI never updated. LWC only tracks REASSIGNMENT, not deep mutations.

Spread into a new object:
https://glenbradford.com/salesforce/mistakes/lwc-mutation-tracking

Tweet200 chars

#39 — Custom Events Not Reaching Parent Components

My LWC custom event never reached the parent component. Unlike React, LWC events don't bubble by default.

bubbles: true, composed: true

https://glenbradford.com/salesforce/mistakes/lwc-event-bubbling

Tweet201 chars

#40 — Using @api Properties Without Default Values in Parent Templates

My LWC component rendered blank. No console error. Turns out an @api property was undefined and .length on undefined fails silently.

Always set defaults:
https://glenbradford.com/salesforce/mistakes/lwc-api-property-no-getter

Tweet226 chars

#41 — Validation Rules That Block Your Own Automations

Added a required field validation rule. It blocked every Flow, trigger, and integration that touches that object.

Always add a bypass mechanism:
https://glenbradford.com/salesforce/mistakes/validation-rule-blocks-automation

Tweet224 chars

#42 — Creating an Infinite Loop with Record-Triggered Flows

My record-triggered Flow updated a field on the same record. That update triggered the Flow again. 50 times. The entire org locked up.

https://glenbradford.com/salesforce/mistakes/recursive-flow

Tweet195 chars

#43 — Managing Access with Profiles Instead of Permission Sets

I inherited an org with 15 custom profiles that were 95% identical. Took 2 weeks to refactor into Permission Set Groups.

Profiles are dead. Use Permission Sets:
https://glenbradford.com/salesforce/mistakes/profile-instead-of-permission-set

Tweet240 chars

#44 — Workflow Rules, Process Builder, and Flows All Running on the Same Object

The org had Workflow Rules + Process Builders + Flows + Triggers all on the same object. One user save triggered 47 SOQL queries.

Consolidate:
https://glenbradford.com/salesforce/mistakes/workflow-rule-flow-trigger-conflict

Tweet224 chars

#45 — Setting OWD to Public Read/Write Because Sharing Was 'Too Complicated'

The client set every object to Public Read/Write because sharing was 'too complicated.'

A departing rep exported the entire customer database.

https://glenbradford.com/salesforce/mistakes/sharing-rules-too-open

Tweet212 chars

#46 — Turning On Einstein Prediction Builder with Dirty Data

We turned on Einstein Prediction Builder. It gave 90% close probability to new leads because won deals were never moved past Prospecting stage.

Clean data FIRST:
https://glenbradford.com/salesforce/mistakes/einstein-no-clean-data

Tweet230 chars

#47 — Deploying Einstein Copilot Without Testing Its Guardrails

During a live CEO demo, Einstein Copilot mass-deleted 150 production Accounts because we enabled the Delete action with no guardrails.

Least privilege. Always.
https://glenbradford.com/salesforce/mistakes/copilot-no-guardrails

Tweet227 chars

#48 — Building Prompt Templates Without Grounding in Record Data

My Prompt Template generated a customer email with the wrong name, wrong product, and wrong price. I didn't pass any record data.

Always ground prompts in real data:
https://glenbradford.com/salesforce/mistakes/prompt-template-no-grounding

Tweet240 chars

#49 — Letting AI Trigger Actions Without Human-in-the-Loop Approval

My AI Flow auto-escalated a happy customer to legal because they said the product was 'criminally good.'

AI should suggest. Humans should approve.
https://glenbradford.com/salesforce/mistakes/ai-flow-no-human-approval

Tweet218 chars

#50 — Feeding Customer Data to AI Models Without a Consent Framework

We fed customer support transcripts to Einstein GPT for marketing emails. A customer's sensitive case details showed up in a promo email. GDPR complaint filed.

Consent first:
https://glenbradford.com/salesforce/mistakes/data-cloud-no-consent-model

Tweet248 chars