With the powerful Salesforce sharing features, you can support collaboration within your organization while keeping sensitive information secure. And while you must always balance collaboration with security, there are situations in which you might need to make absolutely sure that record access is limited to a very small number of people, regardless of their position within the corporate hierarchy. In this post, you’ll learn about the sharing features and strategies you can use to do just that. Continue reading
Tag Archives: Sharing
Record ownership is at the core of Salesforce’s record access capabilities, which allow you to specify which users or types of users should be able to access specific records or types of records. Salesforce.com’s architects and developers have spent years creating a highly functional and massively scalable record access infrastructure around record ownership, saving you the monumental effort of building that infrastructure yourself.
In this post, you’ll learn how those years of heavy lifting have actually simplified record access for the most common enterprise security models, allowing you to configure record access declaratively instead of with painstakingly developed code. You’ll also get an “under the hood” view of record access, and learn how to implement your record access model and avoid potential pitfalls along the way. Continue reading
Learn how salesforce.com makes it easy for engineers to work on what challenges and excites them. Opportunity Open Market makes it easy for anyone in the salesforce.com Technology organization move to a new team. This post explains how the program came about and how it works. Continue reading
Salesforce uses a central Group object to manage visibility related to the Role Hierarchy, Territory Hierarchy, Public Groups and Queues. When administrative changes occur in these areas a group membership lock is taken to ensure data integrity is maintained while complex sharing calculations are completed. The following activities take out group membership locks for the duration of their transaction:
- Role creation
- Role deletion
- Moving a role in the hierarchy
- Adding a user to a territory
- Removing a user from a territory
- Moving a territory in the hierarchy
- Territory deletion
- Territory creation
There appears to be a lack of clear understanding around the differences between CRUD, FLS and Sharing. Here's a high-level overview:
Think about your Force.com object as a database table.
- CRUD: is the table level permission. Does the user have access to this table? (Create records in the table, Read records in the table, Update records in the table, and Delete records in the table)
- Field Level Security (FLS): is a more granular column permission. For each column you can set permissions. Does the user have access to this column and what kind of access? Invisible, Visible Read-Only, Visible Read & Write.
- Sharing: is