Have you ever had that feeling of finally getting a piece of Salesforce data processing just the way you need it? Everything is working perfectly. You relax and start to think about your next project. Then you get that email from a User: “Hey, I updated this field and someone changed it back on me!” We’ve all been there. We all have a moment of panic when we think we’ve missed something. The question is, why did the field change “for no reason”? This post describes one approach to getting the answer.
When you need to add a trigger to Salesforce, you will also have to write a test class. In addition to being a Development Best Practice, Salesforce requires that each trigger have at least 1 test class; and that the total test coverage of all your Apex code is at least 75%.
Unlike other Apex classes, you can’t add the test methods to the same file as the trigger. You need to create a separate Apex test class.
This post provides an overview of two aspects of Salesforce record security that every Admin runs into almost right away — Profiles and Roles — and how they work together to control access to your data.
It is important to understand how Salesforce collects and organizes your data. Salesforce objects (Account, Contact, Opportunity, Campaign, etc) are really tables in the database. Each object has its own table. Each Salesforce record is stored in the database table for its object. A Lead record is stored in the Lead table. An Opportunity record is stored in the Opportunity table.
To view any particular data record, the Salesforce User has to be allowed to see the table in which the record is stored, and also be able to see the record itself. Without both access levels, the record is hidden from the User.