As an Accidental Admin one of the most frustrating things in the beginning is learning the new language of Salesforce. OWDs, FLS… WTF? Every time I needed to do something I would turn to Google to find assistance but with each article would come another word or acronym I didn’t know. I had to look up the new terms, not a bad thing but certainly not efficient when I needed that task done yesterday and had a boatload of other work stacking up. It was like traveling to another country where I didn’t speak the language and desperately needing to find a bathroom but understand the directions.
These were my top five terms that I wished I knew earlier on. Many of them around centered on security, another area I wish I had learned about earlier on in my journey.
API Name versus Label
Understanding the difference between an API Name versus Label is a good place to start. The API Name is the unique name for the component, be it a record type, field, page layout, etc. The API name is auto created from the label but does not have to be the same as the label. It cannot contain any spaces or special characters so be prepared for the name to be adjusted by Salesforce. The label on the other hand is the user friendly name that will show up for your users, so set this to something they will understand. It can contain spaces and special characters.
Sandboxes
Sandboxes are not just for kids anymore. A sandbox is an environment where you can test out an app, process automation, or other customization, without putting your Production org at risk. It was always a bit scary to try to work on improvements to the org when I first started because I was in Production. There was always risk that I could do something that would have far reaching negative impact.
App
An app or application is a combination of objects and components that make it easier for an individual to do their job. Don’t confuse it with a product from the AppExchange. You can set up Apps for different profiles so everyone has the right components at hand. Why field questions about Campaigns from the service team when they don’t need to be using that object?
FLS
FLS stands for Field Level Security. Second only to OWDs, FLS is one of the most import terms to understand. Field Level Security says let me show fields which only certain people should see without creating a separate page layout. As a new admin, you’ll encounter the FLS settings when you create a new field but if you’re like me, you’ll have no idea their power. I needed to have donation information show for my development officer so I created a separate page layout. If I had just updated the FLS, I could have had a single page layout for everyone. AND… bonus, the volunteer team and the programs team wouldn’t have been able to pull that field into a report.
OWDs
OWD stands for Org Wide Defaults. Org Wide Defaults are the basis of how data is available within your Org. When you are trying to figure out why everyone is seeing data that they shouldn’t be able to see or folks are complaining about not being able to edit records that they should be able to, the OWDs may be the source of the problem. The consultant set ours up for us and I had no idea that this existed. So when there were problems with security, I created new profiles. We had just about one profile per user. That’s a bad idea.
Hopefully this clears up a few terms that have caused more than one accidental admin more than a few hours of trouble.