Skip to Content

TheBlogReaders.com

Salesforce.com, PHP, MySQL, Javascript, Ajax, Htacces

Overview of Security in Force.com development platform

Be First!
by September 23, 2012 Uncategorized

Overview of Security in Force.com development platform
1. Every user in Salesforce has a profile. Profiles are of two types.
A. Standard profile
B. Custom profile
A user’s profiles determines access to objects, and fields in objects.

2. There are six type of standard profiles –
A. Standard user
B. System Administrator
C. Contract Manager
D. Marketing User
E. Read Only
F. Solution Manager

3. Profiles control-
A. The objects the user can access
B. The fields of the object the user can access
C. The tabs the user can access
D. The apps the user can access
E. The page layout that is assigned to the user
F. The record types available to the user

4. Standard profiles cannot be deleted. Access permissions to objects (and
their fields) of standard profiles cannot be edited. Standard profiles have
access to all standard objects. Read-only profile have read-only access to
objects. However access to tabs and applications can be configured for
standard profiles.

5. Access permissions of Custom profiles can be edited. Custom Profiles are
created by developers by cloning from a standard profile.

6. For each profile one application has default status.

7. Record Types are associated with profiles. Record type play two important
roles in Salesforce –
A. They help define values to be shown in picklist for different profiles.
B. They are used to define a mapping between page layout and
profiles. This ensures that different users are displayed different
views of the same page, depending upon the layout template
selected.

8. A record is an instance of an object.

9. Removing a field from page layout does not ensure that security of that
field. The field may still be accessible using the API.

10. Security in Salesforce is defined at multiple levels. These levels are –
A. Security at object level
B. Security at field level
C. Organization-wide defaults
D. Role-hierarchy
E. Sharing rules
F. Manual Sharing

11. Object level security is given to profile level. Object level security is set up
via Manage Users–>Profile section. Access for Read, Create, Edit & Delete
can be set at standard and custom objects.

12. Field-level security is also applied at profile level. The field-level security is
available via the “Set Field-level security” button in the field definition
page. At field level, for each profile valid settings are Visible and Read-only.
When a user logs in the list of objects that are displayed to her is
determined by object level security, and list of fields that are displayed to
the user is determined by field level security settings of that profile.

13. The next set of security concepts work at record level. These constraints
determine which records should be displayed to the users. The four
constraints that determine record level access are – organization-wide
defaults, role-hierarchy, sharing rules and manual sharing.

14. OWD stands for Organization wide defaults. This setting is defined at object
level. OWD defined the default record level sharing for objects. All profiles
get at least the privileges defined in OWD. OWD takes three different
values –
A. Private
B. Public Read only
C. Public Read-Write
To find out what should be set as OWD for an object, first find out which
user requires least access to an object. OWD is set based upon this users
access requirements.
Most restrictive record access is defined using OWD. Access to additional
records is made available through Role hierarchy, Sharing rules, Manual
sharing.

15. Role Hierarchy allows additional users access to records. A hierarchy of
roles is defined based upon access requirements at record level. Each user
belongs to a unique role. If a role has access to some record, than its parent
and ancestors will also have access to this record. Roles can be created
using the Manager Users menu. Roles are used to control record access,
where as profiles are used to specify access at object and field level.

16. Another related concept that Salesforce defines is Public group. Public
group consists of users, roles or “roles and subordinates”.

17. Sharing rule is defined using public groups. Record that match certain
condition can be assigned to users in public groups using Sharing Rules.
Sharing rules functionality is available via the menu Sharing Settings.

18. Manual Sharing is used to grant one-off access. Manual sharing can be
granted by record owner, any one above the owner in role hierarchy and
System Administrator. Manual sharing is used to handle exception cases
where access to a particular record needs to be given to a specific user.
There is a Sharing button on the records page. This is used to provide
manual sharing

(272)

Previous
Next

Leave a Reply