#OrgConfessions – there are some lists you shouldn’t be on
We can all learn from other people’s misfortune. Hence this anonymous confessions page.
We built Elements.cloud to make sure you are not on this list!! It supports the entire implementation lifecycle and gives you insights into your Org. Watch the demo video or download and trial it from the AppExchange.
I inherited an org with over 12,000 duplicate contact records. Seems we used to have volunteers doing our data entry.
I inherited the “simple” org with 39 different record types, and 290 Lead routing rules for Call Center with about 350 active agents, almost rule per agent.
Was asked to create a new lead queue and “give everyone access to it”. Created the queue and added all users to it. Suddenly 400+ users are being notified that leads are being reassigned to this newly created queue – over 150 records before a panicked phone call over a weekend got the notifications turned off.
All managers insist on having a password that never expires.
One of our developers linked their Trailhead SFDX work to our Production org.
I inherited an Org with 16 Opportunity record types and 16 page layouts to support 2 sales processes.
97.3% of all email to case records created daily are from spam. This has been happening for the last 18 months.
Former CMO insisted on a 3 level lead source dependent picklists process with 200 options to select from in each picklist. 10 MILLION sources…
After cloning off a Full Copy sandbox, I extracted all of the Contact emails to mask with a fake address. And then ran the update in Production instead of the Sandbox. I caught it and it was an easy fix from the source file, but I am reminded of the gaff every time I see field history on the Contact record.
I once worked on an org with 18 users and each had a custom profile.
I can’t use change sets half the time because the original team that set up the org messed things up so badly that the standard tests fail for the smallest field update.
The org had around 60 roles named according to the sales team managers. There roles like were “Tom’s Team”, “John’s team”… and only 4 of them actually had users assigned. Management explained to me that when one sales manager leaves, they hire a new one, get Salesforce consultant to create a new role with new manager’s name, reassign users and leave the old role empty.
Former accidentals admins would test in production and now there are 782 custom fields on the Account object. I should have looked at the org before accepting the job.
I’m a new Admin and I just found out that org I will support has 3500 Apex classes. I can’t open the list of all classes in Salesforce Setup because the page times out. I can’t open the dev console at all because page times out. I don’t have any ideas how Enterprise org with 30 users ended up having such a high number of Apex classes.
Former “Acting Admin” had no idea what they were doing. Would give it a whirl and then submit a case to Premier Support.
Inherited an org where multiple partners spent several years doing ‘daily admin’. Some used Dutch or French for field labels and English for the API-names. Others did the opposite. Someone played around with translation workbench and changed standard labels. Documentation is nowhere to be found …
My favorite was when I went into Prod one day and went “wtf is Dreamhouse?!” before realizing what happened.
I change everything in production because I’m an awful human being.
Users doing a Trailhead course and started installing apps in our prod org vs their own playground.
Hired an Admin who claimed he had 6 years of international experience to assist my work; fired him because of 2 pages of red flags in a month; the guy might have only 6 weeks of training from India.
Org with 350 users migrated to Lightning using an SI. Company got the cheapest option possible and ended up with a “lift and shift”. All the issues we had in Classic are now amplified 10x and half the stuff we had working in Classic don’t work in Lightning.
35 users logging in with shared username/password that had System Admin access.
I once had to teach a Senior Admin not to build things in production, and how to use a sandbox and change sets.
Once worked with a Senior Admin that refused to fix profiles and permissions, saying they were “not important”. This was after I explained that Sales Directors had access to the CPQ pricebook and were deleting products to try and bypass approvals. Needless to say, ended up mass changing profiles and permissions without telling him. To this day, I don’t think he knows I did it.
Community cloud was so much customized that to refresh the org and to get it back running takes 1 entire week.
Spent a whole week building Reports and Dashboards for an old company and was then told to export all the data into Excel and prepare a 20 Page PowerPoint with the exact same information! Needless to say I didn’t last long there.
The Data ‘Expert’ cleansed the data and re-added as 20% was correct and that was good enough.
As a new admin, my CFO at the time didn’t listen when me and my dev coworker advised we use the private sharing model before deploying a User Community for the customers. When a customer asked why they could see private information on employee’s users, that same CFO then approved 6 months of audit logging at 10s of thousands of dollars and 3 months of lost dev and admin time as we combed through the logs to make sure there wasn’t an exploit of the discovered “data breach” …. we turned on private sharing after that.
Started learning and working as a Salesforce Admin in a small company. The current Admin said he used a separate spreadsheet for the sales data. Upon investigation found out there were no customized fields on Opportunities to record said information. Added 10 fields and no more separate spreadsheet!
When I was first learning Salesforce, I thought sObjects stood for Standard objects and assumed there was a cObject for Custom Objects.
Previously came across a new admin at #SalesforceSaturday completing their Trailhead on their company org. Definitely had a serious conversation with that person.
Can no longer upload CSV updates to Pardot because Prospect ID is a 9 digit number. So are Canadian Social Security numbers. So, naturally, our company Infosec blocks upload of any files containing any 9 digit numbers…
A former colleague was given the task of removing erroneous data from a client’s Production org. Once the bad records were identified, rather than deleting, they flagged them for removal by renaming them all “Nuke ’em”…in production…in a client’s instance. The client thought they were hacked and lost all their data. This happened late on a Friday afternoon. That led to a fun weekend activity for me and my team.
Our Salesforce “owner” turned on Lightning for several teams with absolutely no communications to the users.
10 year old Org. Admin didn’t know how customize nav bar. So they went in for each user and customized their tabs.
“You’re an Admin in our Org.”
Field name were changed when a field was deprecated by adding _DEL. Sometimes it was deprecated and then brought back and deprecated again so it had _DEL_DEL in the name.
The app was used by an Asian offshore team who didn’t speak any English. But all the field labels and help was in English, so the data quality was a disaster.
Dutch company with offices in 10 African countries, who never talked to each other. They all wanted to run in their own language and data was a mess.
We consolidated 7 Orgs into 1 by simply adding everything into 1 Org. Now we are trying to understand how this impossibly complex Org with many, many duplicated field names works.
Org is so messed up we cannot run tests unless you make them so specific to make sure that they only touch certain classes in Apex.
A lot of fields were created by someone who couldn’t spell. Fixed the labels, but the API names are used by integrations and code and will never be fixed. So everyone in the company talks about “customer tupes” not “customer types”.
Creating a lead page layout for a customer that contained over 500 fields and layering in validation rules to enforce conditionally required fields based on business rules.
Brand new Admin. Accidentally deleted 3 million records, so spent all weekend re-importing them before anyone noticed.
We have over 10,000 custom objects, so many apps will not run in our Org. I have been given the job of cleaning it up.
290+ users, 40+ profiles, and 200+ roles.
Regular orders, replacement orders, and missed part orders all pushed into salesforce. Only one record type exists….
Inherited an org where input validation for a single object was buried inside multiple Apex classes instead of using validation rules 🙁
47 user profiles for approximately 150 users
“We want a custom object that does everything Opportunities does”
“Why not just create another record type for opportunities?”
Opportunity object re-purposed and utilized as if it was a custom object.
User did the MyDomain Trailhead in Production. So our Prod login was changed to kittiesarecute.my.salesforce.com It took a tech call escalated to Salesforce Tier 3 support to undo.
26 multi-select pick list fields on Accounts.
Flows that run instead of validation rules to correct data errors.
Multiple users for the same person in the same Org.
Field names that mean different things based on how it is used.
Sandbox not updated 10 years.
Multiple PBW on the same object.
I inherited an org where pretty much everyone was given system admin access.
Duplicating Account team members just to make case routing work with GainSight.
Creating a set of custom text fields for the account address instead of using native ones.
Our best customer in Production is “Testy McTesterson”. We have to add filters to every report to exclude their records.
Inherited an org with a public group for pretty much each user vs. using role hierarchy in sharing rules and report folders
Tracking financial information on a record and with a set of fields created for each year
Spent our entire first year with Salesforce entering real-time data into our Full Sandbox instead of Production. Now we can’t refresh because we might lose something important.
Had a problem with a CPQ cpq field not working. Submitted a case went all the way to the executive level to find out I was missing an underscore in __c. So embarrassing.
At my first admin job they wanted an email alert setup when any opportunity was closed/won. I then had to do a mass update of 20,000 old opportunities to update a field. I forgot to turn off the workflow rule. Crashed our email server sending 20k+ emails out to 10 people.
Just joined company. The Org is 8 years old and I am the first full time Admin.
A managed package that used Translation workbench to swap the labels on two fields so they are now the opposites of their API names.
1 process includes 18 PBW, 2 flows, 12 workflow rules, 30 custom formula fields. Plus maybe some code. No one knows how or why it exists.
Created a custom fields for every standard field because admin couldn’t see them in searches.
Renamed every metadata API name to the business unit that needed it. The developers needed to access lookup sheet to be able to decipher.
Process consolidation – 16 PBW on a single object and each PPW has single action and criteria.
Multiple fields with same label.
We track everything in spreadsheets not Salesforce. Why? No idea. I don’t have a good answer and I’m an MVP!
We have OCD (Org Complexity Disorder).
Law firm created a Case record type for every case they tried. We got the call when they maxed out their Case Record Type at 300.
Customer sold 10 products. They put a checkbox on the Account record for each product and company. Every time they sold to a new company – they added those 10 checkboxes to the Account record for the new company. We got the call when they reached their 500th field on the Account record.
Customer used workflows and triggers to create tasks for their service representatives. After 3 months they had maxed out their storage. We had to explain that there was no way that 25 service reps could clear the 450,000 tasks that had been created for them.
Renamed Opportunity object to Donations, but users couldn’t cope with concept so had to change it back.
Made to implement 50 unique compliance checkboxes and then an action to check them all as True in one go.
Consultant created custom object called Opportunity, but report builder displays name not API, so we could not determine between custom and standard Opportunity object.
So much customization with external interfaces it takes weeks to create a new Sandbox.
We consolidated Orgs and an object for one business unit had 800 fields all visible in one page layout and the page kept scrolling and scrolling like a CVS receipt.
29 users in the Org had 6.6m archived tasks. Data storage cost was $15,000 so instead I took 14 hours report on the IDs and export. They were hours I will never get back.
Checkbox on Account “Is not active”. Default was false.
Pairs of fields on an object. One field is a checkbox and other is date completed. 200 pairs of fields.
400 custom fields of which 390 were 30 groups of 13 questions.
Opportunity object with 360 fields, 60 validation rules, 0 record types and just 1 page layout.
27 System Admins – 29 users.
We installed a managed package that added a currency field onto every standard AND custom object.
That’s a big Org…. 1,058 Custom Objects, 14,108 Apex Classes, 47 Managed Packages, 896 Permission Sets, 2,269 VF Pages and 446 Lightning Pages.
We have an Org with 2 custom objects – Contact and Report.
We have problems regularly with troubleshooting and regression testing Process Builders to the point that we’re telling business users we can’t make updates to automation because the time commitment for regression testing even basic updates is huge.
I inherited an org which had the sales team using a custom object for Leads… because another team was already using Leads to track their opportunities. Because obviously two teams couldn’t use the same object for similar purposes… I blew their minds with record types!
The company service team started storing employee ID’s in the same field as the employee name. Talk about data integrity, and a massive export for clean-up.
We have a custom object called ‘abc’.
Somehow, a business user had System Administrator as profile. We noticed when that person installed dreamhouse application in Production environment using Trailhead!!
A Solo Admin has developed the Org for the last 8 years. They have just left but there is no documentation on any of the changes. So now the new team of 3 people is trying to work out what was done and why.
One of my clients directly changes Fields, Workflows, PBW, Approvals, Formulas in Production and they are careful in Full Sandbox. Developers are confused which is the real production org: is it Production or Full Sandbox?
We have 2 Product objects and nobody knows what the differences are.
One of our team – NOT a System Admin – is able to use the Data Import Wizard but cannot see the results file. So they are able to create havoc, but not see what they have done.
Three fields on the same object with the same label. Even better, the Process Builder on the object references all three… except you can’t see which field is which because API name isn’t visible in PB.
We can’t add documentation to a Process Builder Workflow because each PBW does not have a unique URL in setup. Doh!!!
Dev team wanted to put all regional account record details into a single account, with each region having its own section.
It is easier to create and customize a new Org than get approval to add functionality to our existing Org because it is so bloated.
In our clean up exercise we have just deleted 178 objects. Yay!!! But how did we have that many that could be deleted?
Making changes to launch our Service Cloud and Community in production because I can’t 100% deploy both using metadata.
Case Sharing Setting is “Public Read/Write” and there are many Sharing Rules which are supposed to restrict the case records to different teams.
Deleted a field, but only discovered months later when end of year processing integration ran.
Preparing a demo, I set Deliverability to ‘no e-mail’. Result: not getting a verification code to log back in to the Org. A once-in-a-lifetime mistake!
24 Process Builder Workflow on the same object, some of them with Active Version not being the Latest Version, plus some Workflow Rules thrown in just to keep it interesting. Then some dependencies on the Condition Criteria on those Process Builder Workflow without any way of controlling the order of operation.
Hardcoded Record Type IDs in Apex that don’t correlate to anything? If it passed testing, it must have been ready to deploy!
For a large telecommunications business I was asked to add a checkbox to a page, then make it required.
Every standard object recreated as custom objects because 2 different groups were using Salesforce. When I started I was given 2 logins for the same org because nobody understood security. THEN instead of moving opportunity owners when a sales person left, they just typed over the name instead of inactivating users. Audit trails are apparently not necessary in insurance.
Uneditable closed opps.
No process for auditing fields before creating new fields so many duplicated fields and multiple conflicting triggers.
All the object names were stored in code as variables a, b, c, d, e with no commenting. So impossible to read or debug.
10 competitor fields on the Opportunity object.
Maxed out field validations, so validations were triggering other validations. It was easier to not enter any data.
Replaced every standard page with a VF page.
Page layouts with 500 fields and page takes ages to load.
9 Triggers on Lead Insert.
Couldn’t run any report because it always times out. Too many records – 90% of the data is garbage.
Inadvertently commenting code during Prod deploy.
Found this code in project –
30min trying to fix a formula (NULL v. 0, blanks as blanks v. blanks as 0s, etc.). No documentation so discovered I was referencing the wrong field….
When you discover work done with code that could’ve easily been done with declarative tools.
Opportunity object has “Qualified Date” and “Date Qualified” fields
User: I don’t want to have to look at anything or click any buttons or do anything. I just want everything to be served up to me in an email everyday.
No naming conventions, the field names (API) don’t make sense and don’t match the field values. Cleaning up page layouts is a nightmare.
No role hierarchy implemented in complex HR app. New consultant came in and fixed the role hierarchy on Friday. Sunday morning call from CEO “Everybody’s salary is now visible”.
Whether declarative or programmatic, it’s pretty easy to mess up a Salesforce org.
Recreated standard system fields – such as Created By, Created Date/Time, etc – as custom fields.
Request for a multi-select picklist with 98 values. When advised this was not the best practice and to rethink the need, they came back with a request for a picklist with 78 values.
Question: “Can you send me an excel of this report?”
Answer: “So I can add a graph to understand the data!”
Users who can’t be bothered to learn the newest Salesforce instructions asking why they don’t have admin access and can’t see every field.
Account object is set to private. Found a sharing rule that gives read/write access to everyone if the creator was any user…
Salesforce is no longer our source of truth. It’s our source of duplication and despair!
100+ Process Builder versions.
Directors were told that setting up email-to-case is easy, it just needs to be turned on….
Object with 2 fields “shoe size” and “size of shoe”. Why? Because couldn’t change field due to dependencies, so just created a new field.
Custom developed project management app – core object maxed out fields.
Regression test and UAT before CPQ go live. But clearly missed something as couldn’t do a system generated quote for 6 weeks. So had to manually create quotes. BTW quotes are 200 line items.
40 lookup fields on the Product object.
Validation rule firing on a field in a managed package which not visible because the managed package is expired.
Duplicated Lead and Contact as custom objects.
50 different records where they are lead and contact with the same name.
3 Apps installed all with the same field name but cannot change field labels so super confusing especially as one App is not used but we cannot uninstall.
Product object, 250+ quantity and 250+ price fields. But needed to write some Apex to query the record. CPQ on one record.
3 million lines code, 100% was not necessary because it was an app that is not needed.
Hard coded profile IDs in Apex Class.
My report isn’t returning the results, because there wasn’t a role hierarchy.
We created a custom Opportunity object because we didn’t like the name “opportunity” and now we can’t build a sales pipeline report easily.
As we acquired companies and added their sales methodologies and opportunity stages… 30+ stages with overlap e.g. 7 different versions of “sales won” and 10 different versions of loss stages. And then how do I report on that.
Hard coded vendor names in Apex Class.
No code coverage – anywhere.
3 custom Product objects with duplicated fields and no documentation…
We only had 2 profiles; SysAdmin and Staff. But we discovered both had full Admin rights.
We have 4 different source fields on the Lead object filled out by our marketing team.
We’ve let sales people add fields and picklist values to solve their problems.
Every day, users need to log into at least 4 different Orgs to get their job done.
Multiple Orgs. They couldn’t work out what was configured so they start again, and again, and again. We see this a LOT in the nonprofit space.
35 Users, 25 Profiles. Every custom field on every object starts with z_ . Different suppliers, created different fields for same purpose.
Custom address fields on Contact and Lead objects.
Using i++ to increase code coverage of test classes unethically.
My Manager removed the ability to export reports. Without telling anybody. 2 days before month end reporting was due.
Added 20 dummy classes (8000 lines code) and test classes to boost code coverage.
A single apex class with 13,000 lines of code!
Written and Modified Lightning Flows, Processes, and Validation Rules, in Production.
Lead Source values maxed out with 1,000 entries.
30 profiles, 5 had the same name with a year marked at the end. Example = account manager 2015, account manager 2016. Not sure why? No documentation on what was different.
Date of first meeting being stored on Lead and Lead Stage being processed on Task.
Two custom fields on Lead – “Converted Date” and “Date Converted”.
200 Apex Classes. 50 tests failing in production. The other ones are fake tests with no assertions.
Our Org was taken over by keen developers who automated everything and now we have “the world’s best self driving car… with no wheels”.
2500 permission sets.
UAT Sandbox not refreshed in 15 months.
Hard coded user names in Apex classes.
1000 users but 5000 roles.
Core Opportunity object and then 2 extra custom objects for more fields.
Took all custom fields off standard objects and put them on a single custom object.
Everything was coded in Apex by consultants who didn’t understand core Salesforce features. 3 million lines of code!! Every field was referenced so none could ever be deleted.
Inherited 6 year old Org and discovered Field History had never been switched on.
12 triggers on the Case object. Sigh.
1,500 lines of j++ intended to inflate test coverage.
Inside sales couldn’t work out how to convert lead so printed it out and left on the desk of the sales person.
Another scary Org: over 600 objects, 24,000 reports & 1200 dashboards.
User could not access an opp. Asked them to send the URL of the record. They printed out the opp, scanned it and sent it as an email. Bless their heart.
Someone had referenced all the Test 1, Test 2, Test 3 account names to be ignored in their code. Yikes!
Every object had a custom field for last modified date/time.
Every user is a system administrator.
All business process and data for a 40-user company was on the same standard object.
Profile for every user.
Thousands of private reports for inactive users.
Inherited Org. Every user had Admin rights.
Managed packaged installs 209 objects, 79 tabs, 351 Visualforce pages, 160 apex triggers and 3126 apex classes into your org.
Replicated Siebel CRM using all custom objects.
700 fields and 280 are formula fields on one object.
Our Development team built a trigger that lets an external system synchronize the account address to their contact addresses and validates with an error message if any user tries to update the contact addresses. After deploying it to the Production environment, users could not create contacts anymore.
We spent time analyzing what was going on and found out there were workflows overlapping the trigger in the way that any user can update the contact addresses through the respective account. Workflows were given every time a Contact record is created or updated.
738 Apex triggers developed over last 8 years by external consultants. No documentation.
Case object maxed out at 800 fields with 54 record types.
We found people who are doing Trailhead modules inside our Production Org.
We have 271 Permission Sets, 100s of public groups used in sharing rules and 103(ish) profiles.
Consolidating 2 small Orgs after an acquisition took 8 people 4 months.
464 fields (all used) and 14 stages on Opportunity object but the page goes on forever and takes minutes to load.
15,000 reports. No comment.
Contact object maxed out with 800 fields when trying to consolidate 5 orgs. So we have no idea how to consolidate without duplicating an object.
Over 100 picklist values on a field but we have no idea which ones are used so we can’t delete any.
We have run out of fields on the Opportunity object 5 times.
We have 49,700 email templates. A bug in the managed package that integrated with a 3rd party marketing app (not Salesforce) created email templates every time it ran.
We are trying to consolidate 55 Orgs. We have 4 business units but shared customers. So should we have 4 Orgs or 1? And how do we get there?
The audit to scope the clean-up work has taken 4 consultants 30 days. This 8-year-old Org doesn’t have a single line of documentation.
I learned we had 1,500,000 lines of undocumented Apex code.
5372 Apex Classes and 55 Managed Packages, but I am not sure which we can delete.
We have 15,000 reports with no sensible naming.
We’ve maxed out our 500 field limit on a Task. Let that just sink in for a minute.