The document discusses setting up security and access controls in Salesforce. It provides examples of how to configure profiles to control what users can see and modify. It also explains how to set up sharing rules to determine access to records at the object, field, and record level. Specific examples include allowing all sales teams to see accounts but only modify contacts for their own accounts, and making opportunities private except for amounts under $10,000. The document emphasizes defining user profiles and mapping them to object and field access levels based on business needs.

1. Setting up security
​ Naveen Gabrani Joseph Dindinger
​ CEO CEO
​ ngabrani@astreait.com TO A FINISH
​ @ngabrani
​

2. ​ Safe harbor statement under the Private Securities Litigation Reform Act of 1995:
​ This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties
materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed
or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-
looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any
statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new,
planned, or upgraded services or technology developments and customer contracts or use of our services.
​ The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our
operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any
litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our
relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our
service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger
enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our
annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter.
These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section
of our Web site.
​ Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available
and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features
that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
Safe Harbor

3. Naveen Gabrani
CEO, Astrea IT Services Pvt Ltd

4. ​
§ Security: Who has access to what records
§ What type of access: No access, View, Write, Delete
§ Scenarios
Importance of Security
Criteria Access Level Profile
Opportunity value > 1 Million Visible Sales persons
Account in California Editable Sales team in CA
Cases Visible All organization

5. § Talk to senior users and management
§ What tasks different users need to perform
§ What all information needs to be kept secure
§ Classify your users into groups that perform similar operations
§ Map your objects to these user groups
§ What level of visibility is needed
Design of Security

6. Access is a many layered thing....
ORG
ACCESS
OBJECT
ACCESS
RECORD
ACCESS
FIELD
ACCESS
IP RANGES,LOGIN
HOURS
PROFILES
ROLE HIERARCHY
FIELD LEVEL
SECURITY

7. § Profiles: Group of users that perform similar operations
§ Sales Team based in Boston
§ Customer Service Project Managers
§ Call center agents for European customers
§ Each user is mapped to a unique profile
Profiles

8. § Minimum access needed for all the Salesforce users to an object
§ Possible Values
§ Private
§ Public Read Only
§ Public Read/Write
OWD: Organization Wide Default

9. Role Hierarchy
CEO
VP Sales
Sales Director
International
Sales Director
US
VP Projects
Project
Manager
A Manager has access to all records that are accessible to
its reportees
ü “Grant Access Using Hierarchies”
Record owner and Salesforce Admin have access to all records
Master Detail relationship, child inherits OWD from parent
View All Data settings: access to all records
Each user is mapped to a unique role

10. Joseph Dindinger
CEO, To A Finish LLC

11. ​
§ Control access to company data
§ Rules for sharing access to data
§ Accounts
§ Contacts
§ Widgets_c
§ Etc.
What ARE sharing rules?

12. Access to objects
Access to fields
Access to features
What sharing rules are NOT.

13. Private
Sharing Rules Starting Point
Public

14. ​
§ Read Only
§ Read Write
§ Full Access
Different Types of Access
​
§ Transfer
§ Use

15. § Public Read/Write
§ Public Read Only
§ Private
§ Controlled by Parent
§ Grant Access Using Hierarchies
Common Sharing Settings

16. Manual
Sharing
Sharing Settings Strategies
Rule-based
Sharing
Programmatic
Sharing

17. Sharing Rules Scenario

18. ​ Cars X provides high-end cars for
executives around the world. Sales reps
at Cars X are given full access to all
accounts, but can only edit contacts that
belong to them. Opportunities are
strictly private; only the sales rep and his
or her management tree are allowed to
see them.
​ * Note: Some opportunities, those under
$10,000 should be seen by everyone.

19. ​ We must set the
Accounts to:
​ Public Read/
Write (Default)
Step 1: Account Sharing Settings

20. We must set the
Contacts to:
Public Read Only
(change from Controlled
by Parent)
Step 2: Contact Sharing Settings

21. § We must set the Opportunities to:
Private (Change from Public Read Only)
§ We must add a sharing rule to give read only access to sales reps
who share roles
Step 3a: Opportunity Sharing Settings

22. § We must add a sharing
rule based on specific
criteria to give read only
access to any
opportunity below $10k
Step 3b: Opportunity Sharing Settings

23. Sharing Rules Demo

24. Sharing Settings Overview

25. § Can be enabled or disabled per object
§ Can be confusing and only to be used in
cases where rules cannot be made to fit
§ Needs maintenance, especially if ownership
changes
Manual
Sharing

26. § The most common solution for most
situations
§ Extremely powerful and customizable
§ Once set, can be forgotten until the rules of
business change
Rule-based
Sharing

27. § If default settings don't work
§ If roles don't fit the bill
§ If rules can't be written
§ If manual sharing is too tedious and error
prone...
​ THEN you can use Apex programing to
share records correctly
Programmatic
Sharing

28. Programming Scenario

29. ​ Cars X hires drivers in each state who will take a
car from the dealer and drive it to the buyer’s
house. These drivers are in the Cars X Partner
Community and should be able to edit only three
fields on Closed Opportunities in their assigned
states. The three fields they can edit are:
1. Assigned Driver (a lookup to the User object)
2. Target Delivery Date
3. Date Delivered
​ * Note: Once the Assigned Driver field has been
saved, all other drivers should no longer be able
to see the opportunity.

30. Programming Sample Code

31. Sample 1: Trigger to Share Code

32. Sample 2: Trigger to Remove Share

33. Sample 3:
Trigger
Handler
Code to
do the
actual
Sharing

34. § Think it through with all involved
§ Document thoroughly
§ “Bulkify” your code carefully and
thoroughly
§ Set up a log in case of failure
§ Use Asynchronous Code
(@Future or Batch)
Tips for Programming Sharing

35. Permission Sets & Profiles Overview

36. § Which Objects and Fields you can see
(not which records)
§ Which Features/Functions you can use
Permission Sets & Profiles Determine

37. Permission Sets vs Profiles
​ Differences include :
§ The ability to set features across multiple
profiles
§ Ease of assigning to multiple users

38. Profiles,
Permission Sets & Sharing Rules

39. Data vs. MetaData
Permission Sets
& Profiles
Sharing
Rules

40. Our Last Scenario
Our last scenario could not have been
completed without sharing rules AND
permission sets/profiles

41. Thank you

42. Share Your Feedback, and Win a GoPro!
3
Earn a GoPro prize entry for
each completed survey
Tap the bell to take a
survey2Enroll in a session1