Lately I've been involved in several discussions around how the Force.com platform handles object and record level security. I'm surprised that there's still a lot of confusion around this topic despite all of documentation available out there so I'll try to explain this topic in more detail. It
usually helps to start the conversation referring to Jason Ouellete’s
“Development with the Force.com Platform” book where he illustrates these
layers of security as a funnel.
Each request has to go through several layers starting with
CRUD and FLS checks and then moving to verifying org-wide default sharing model
and any exceptions to org-wide sharing model if applicable. If the request
“survives” through all of these checks then access is granted. This funnel provides a great way to illustrate how data
security works at a high level but it still doesn't explain all the
nuts and bolts involved with sharing rules and how to enforce these levels of security when using Apex. We …
Wow, it's been almost 2 years since my last post. It's been pretty busy for me lately but I'm still very involved with Salesforce and excited to share a project I've been working on for a while now (drumroll) :
What is almond?
Almond is a Learning Management Application built on top of Salesforce1. The goal of this app is to create engaging learning experiences for your employees and reward them as they make progress through their learning activities. Learners can take quizzes, complete tasks and launch learning resources from a desktop or mobile device as well as provide feedback on the learning content.
Here's a quick overview of the app:
Why is it called almond? It all started with the idea of creating Learning Management ON Demand (LMOND) system and ended up adding an A in there because I think it's awesome, plus, almonds are tasty. How can I use it?
The app can be used in different scenarios, here are some examples: Create on-boarding training plans for new hi…
I spent a few minutes today thinking about my experiences developing on the Force.com platform. Overall it has been great, nevertheless, there have been some bumps in the road (and there will be more to come).
Here's a list of some commandments that I've come to think of as imperatives for development on Force.com.
NOTE: This is just a list with no particular order of some of what I consider are the most important items.
Thou shall not:
Say a class or trigger is ready without having any test units Place a SOQL query inside a for loop Place a DML operation (for a single record) inside a for loop Hardcode an id, object prefix or service instance names... anywhere Create a full sandbox without being damn sure you're ready to create it Say a field is hidden by just removing it from a page layout Assume your test units will magically find data in a new org Assume a 75% coverage is good Ignore asserts in your test units Rely on good percentage coverage of other classes to upload your "…