When I was first exposed to Salesforce back in 2005, it blew my mind. At that time I had been working for large companies that were stuck between the extremes of very rigid ERPs like SAP (that almost never got updated due to the expense and time involved), and “lowest common denominator” tools like Excel. Great to build stuff quickly, but spreadsheets were not ideal outside of small groups or departments.
Today we take for granted that the cloud is secure and makes business sense. How quickly we forget. It really was not that long ago that I was toe to toe with IT department heads who didn’t want to give up their data centers and servers, and in retaliation played the fear card with CEOs in order to keep headcount and budget. A decade later it’s a mute point, but boy at the time those discussions were heated and intense. I’ve blogged about it before – cloud computing was very threating to IT in the early years.
Even in those early days, we were building web-based user interfaces with a drag-and-drop tools (look mom – no HTML knowledge required!). Salesforce enabled business owners and department heads to create functional applications quickly. You didn’t need to code, you didn’t need a server, and you didn’t need IT – we just clicked away. With Salesforce, you needed to know just enough to be dangerous – and dangerous we were.
Thousands of aspiring Salesforce System Administrators dove in to the deep in of the cloud computing pool, swam and succeeded. These were the days before Sandbox testing environments were available. We “played in the street” and deployed changes and updates in live production environments. That’s the way we were taught – it was the only way we could make updates! As an “old school” Salesforce Administrator I still do quite a lot development in our own company org in production (and if you’re running Professional Edition or below, you have no choice because you don’t have access to a Sandbox environment).
That’s “The Peril of Salesforce” – the platform has empowered legions of users and System Admins to make updates on the fly, quickly, and with little consideration for documentation or change management. It happens like this. You’re a System Admin sitting in a meeting and a business problem comes up. You propose a solution in Salesforce, you get consensus from the meeting attendees and you walk down the hall and bang out some configuration updates in a couple hours (or days). Business need addressed. No problem – right?
Salesforce.com democratized CRM by putting the power of managing and maintaining the platform in the hands of front line department heads. For many, the power went unchecked. Over time orgs started “running away” with ad-hoc changes. Page layouts became bloated with hundreds of custom fields. Configuration changes trickled down to end users with little or no communication – ultimately hurting usability and adoption.
I’ve worked with dozens of companies over the years that have churned through multiple System Administrators. They have no knowledge of how something was built or why. When you ask the question “What is the purpose of these fields,” or “Who uses this report,” you can get a lot of shrugging shoulders and blank stares. They are the org skeletons left over from prior Admins. The intent and business need had long been forgotten, but the users are still working around the rubble of all those ad-hoc updates.
How does this happen? Salesforce doesn’t come with a change log or an easy way to “roll-back” updates to previous versions of the configuration. Good System Administrators will use the description and help fields in Setup to document as they go. Outside of that, it’s really up to the Admin to keep a change log or a release schedule to know what you deployed, when and for what business reason. For bigger organization and companies, there are probably more rigid processes in place and procedures to document the “why, when and for who.” For smaller organizations, not steeped in process, they quickly fall victim of “The Peril of Salesforce.”
Cleaning up the leftover configuration debris is not an easy process. Salesforce does not give you an easy way to know what will happen if you delete a field or change a picklist value. With a click you can break quite a lot: Assignment Rules, Escalation Rules, Workflow Rules, Validation Rules, Reports, Dashboard Filters and Buckets, formula fields, criteria based sharing, triggers, and integrations are all at risk.
Impact Analysis
Lucky for us, there are some tools finally coming to market to assess the impact of making a change in your Salesforce org. While I was at Dreamforce ’13 last year, I learned about a product called Panaya ChangeGuru. What they have done, as I understand it, is take snapshots of your Salesforce meta-data and store this information on Amazon EC2 (so the data doesn’t count against your Salesforce storage limits). From these snapshots Panaya can tell you what’s changed in your org over a period of time, but more importantly, their software can quickly wade through the configuration spaghetti and assess what areas of your org are tied to a specific field. That’s HUGE when you want to be sure you’re not going to break something when making a change. Without such a tool, Admins have no easy way to know what might break changing a field – how many reports will be impacted, if a Workflow Rule is going to stop firing, if Users access will change do to criteria based sharing rule, or if other formula fields downstream start miscalculating.
Cleaning Up Your Org
There is another popular tool out there to help you assess whether a field is being used by your users – Field Trip by Qandor. Field Trip (if you are lucky enough to have Enterprise Edition or higher) can look at the different objects in your org and tell you for a given field what percentage of records have information populated in that field. I like this because it can give Admins some quantitative data to know if a field should make the short list for deletion. After that I’ve seen a couple of techniques to give Users an opportunity to speak up or forever hold their peace before a field gets nuked. I’ve see Admins take the approach of just removing the fields off the page layout to see if anyone notices, and others creating a section on the page layout near the bottom called something like “Fields Targeted for Deletion” to give users a chance speaks up.
Another thing you can do is run a report to find old reports that are no longer used. This is helpful if you’re in an org with hundreds of reports, and the vast number is creating a lot of unwanted noise for your users. When you go to the Reports Tab and click the “New Report” button, under Administrative Reports, you’ll see an option to create a Report on, you guessed it – Reports! The field you want to leverage to identify old reports that are just adding clutter to your org in that Report Type is the Last Run field.
So that’s “The Peril of Salesforce” – with the incredible ease of use and configuration power that Salesforce provides comes the great responsibility to have change management, documentation, and an awareness of how ad-hoc changes impact both user adoption and overall usability. Part of being a good System Administrator is being sensitive and conscious of the changes occurring in your org overtime, as well as how these updates are being received by your Users. At some point someone is going to want to know the who, when and why, and more importantly, what will happen if you make a change to the configuration! Be prepared – start documenting as you go!