Open CertifiedOnDemand.com Section Resources
This is not an exhaustive list; additional resources are referenced within objectives below.
| Objective | Resources | Key Facts |
|---|---|---|
| Describe the core principles of the security model. | Who Sees What: Data Visibility How to Series [Must / ~50m / Salesforce.com] [Who Sees What: Organization Access repeated from User Setup & Login Process – Free] (This series is also available via Vidyard but does not appear to contain the entire series.) | The "Who Sees What" series is a great introduction to Salesforce security. If you have not watched the series before, I recommend watching these videos in order. Objectives and resources to follow will expand on these concepts. |
| Describe the capabilities of the User Sharing feature. | Understanding User Sharing [Could / Long / Salesforce.com] | User Sharing allows an administrator to set the user object org-wide default (OWD) to private. This feature is enabled by default for orgs created after the Winter 14 Release. To enable this feature in an existing org, contact Salesforce.com support. |
| Describe how access to data and functionality is structured within Salesforce. | Security Overview [Must / Medium / CertifiedOnDemand.com] | Organization Security: When (Login Hours), where (Login IP Ranges), and how (UI/API/etc.) a user can login. Object Security: What actions a user can take on the records of a particular object (in conjunction with record security). Record Security: What actions a user can take on an existing record (in conjunction with object security). Field-Level Security: Determines which fields a user can view and update for each object. Folder Security: Determines access to a variety of information including reports, dashboards, email templates, and more. |
| Explain who can delete records in Salesforce. |
| To delete a record, the user must have the "Delete" object permission (profile or permission set) and "Full Access" to the record. "Full Access" is typically granted to the record owner, users higher in the role hierarchy than the record owner, and system administrators. |
| Describe profiles and their influence on security. | Profiles [Must / Short / CertifiedOnDemand.com] User Permissions [Must / Medium / Salesforce.com]
| Each user is assigned one profile, which is instrumental in determining a user’s functional access (apps, tabs, object-level permissions), how information is displayed to the user (page layouts, record types, field-level security), and a wide range of other permissions. |
| List and describe the standard profiles. | Standard Profiles [Should / Medium / Salesforce.com]
| Ensure that you understand the Salesforce license standard profiles: Contract Manager Marketing User Read Only Solution Manager Standard User System Administrator |
| Explain when to create a custom profile. |
| As customization of standard profiles is limited, create custom profiles prior to assigning users to profiles. |
| Describe permission sets, and common use cases where they are appropriate. | Permission Sets [Must / Short / CertifiedOnDemand.com] Overview of User Permissions [Must / Short / Salesforce.com] Winter '12: Efficient, Manageable Security Policies with Permission Sets [Should / Medium / Salesforce.com] The Permissioner [Could / Package / Appexchange.com] Who Sees What: Permission Sets (Repeated from Who Sees What Series above)
| Whereas the profile is used to set the foundation for a user's privileges, permission sets are optionally used to extend a user's privileges. Permission sets can drastically reduce the number of custom profiles required in an org. Two common use cases: 1. One-off cases where a user needs privileges not granted by their profile (e.g. extending the delete leads permission to one inside sales team, while the rest of the team cannot delete leads). 2. Extending privileges to users that are assigned different profiles (e.g. access to a 3rd party application). |
| Describe how Organization-Wide Defaults (OWDs) influence security. | Sharing Default Access Settings [Must / Medium / Salesforce.com] Default Organization-Wide Sharing Settings [Should / Short / Salesforce.com]
| Organization-wide default settings determine the default record-level permissions granted to all users for all records within each object. For instance, setting the Account object to "Public Read/Write" will ensure that all users have "Read/Write" record-level permissions to all account records. The most commonly used settings are: Private: No record access granted Public Read Only: Read only record access granted Public Read/Write: Read/Write record access granted Public Read/Write/Transfer (Cases, Leads): Full record access granted Controlled by Parents (Contacts, Activities): Parent record controls access |
| Describe roles and their influence on security. | Roles [Must / Short / CertifiedOnDemand.com]
| A user's role sets the foundation for what records and folders they can access. Users are granted full access to records owned by users in subordinate roles on objects where "Grant Access Using Hierarchies" is enabled. |
| Describe public groups and their influence on security. | Groups [Must / Short / CertifiedOnDemand.com] | Public groups are used to streamline the process of sharing access to records and folders. A group is comprised of users, roles, and other groups. |
| Describe manager groups and their influence on security. | Sharing Records with Manager Groups [Should / Medium / Salesforce.com] | Manager Groups are used to share access to records based on the user's manager (specified via the manager field on user record). Manager Groups is disabled by default, but can be easily enabled by the system administrator. |
| Describe sharing rules, and when their usage is appropriate. | Sharing rules are used to extend record access to users within specified roles or groups. Records can be shared either based on record owner (role, group) or record criteria (known as a criteria-based sharing rule; e.g. all accounts in state "OH"). Sharing rules can extend either Read Only or Read/Write access. |
|
| Describe a queue's influence on security. |
| Ensure that you understand the fundamentals of queues - see User Setup & Login Process – Free for more. When a user is a member of a queue and a record is owned by a queue, then the user will inherit "Full Access" to that record. |
| Explain how manual sharing can be used to extend record access. | Manual Record Sharing & Auditing [Must / Short / CertifiedOnDemand.com] | Users can manually share access to records that they own with other users, roles, and groups. |
| Describe delegated administration. | Delegated Administration [Must / Short / CertifiedOnDemand.com] | Whereas profiles and permission sets grant the ability to administer all users and objects, delegated administration allows administration of only specified users (based on roles/profiles) and specified custom objects. |
| Describe the capabilities of Custom Permissions. | Custom Permissions Overview [Could / Short / Salesforce.com] | Custom permissions can be used to define permissions within a custom application or process. For example, your organization has implemented a custom application in Salesforce to track leave requests. One of the buttons in the application invokes a custom process (apex/VisualForce code) to mass approve leave requests. Previously, if a developer wanted to define a permission to mass approve leave requests, this was often configured through the use of a custom field on the user object (e.g. checkbox "Can Mass Approve Leave Requests") or via the use of a hierarchy-based custom setting. Both of these approaches have limitations. With custom permissions, a developer can define a permission to represent the user's ability to mass approve leave requests. This custom permission can then be assigned through the use of a profile or permission set, like any standard Salesforce permission. Creating and defining custom permissions would be performed by a developer. However, administrators should be aware of custom permissions and the potential security implications when used. |
| Describe the capabilities of Single Sign-On (SSO). | About Single Sign-On [Should / Medium / Salesforce.com] Single Sign-On Implementation Guide [Could / Long / Salesforce.com] | Single Sign-On provides the capability for a user to login to one system and have access to one more additional systems facilitated systematically as a result. For example, a user may authenticate to their network through Active Directory (Microsoft Windows) and thereby be granted access to Salesforce.com without providing a username and password. |
| Describe the capabilities of the Salesforce App Launcher. | Setting up the App Launcher [Could / 6m / CTOBuddy] | The Salesforce App Launcher is a single sign-on portal, allowing users to launch both Salesforce and external applications (external apps via single sign-on). |
| Describe the resources to monitor Salesforce system performance and security. | Trust.Salesforce.com [Must / Short / Salesforce.com] | Use trust.salesforce.com to monitor system and security status, as well find best practices from Salesforce. |
| Given a scenario, determine the appropriate security configuration. | Security: Scenario 1 [Must / ~10m / CertifiedOnDemand.com] Security: Scenario 2 [Must / ~10m / CertifiedOnDemand.com] Security: Scenario 3 [Must / ~10m / CertifiedOnDemand.com] Security: Scenario 4 [Must / ~15-30m / CertifiedOnDemand.com] | |
All Objectives Met | Security Matrix [Should / Short / CertifiedOnDemand.com] A Guide to Sharing Architecture [Could / Long / Salesforce.com] Record-Level Access: Under the Hood [Could / Long / Salesforce.com] Workshop: What's Possible with Salesforce Data Access and Security [Could / 2h9m / Salesforce.com] Nailing the “Gotcha” Questions [Must / Medium / CertifiedOnDemand.com] Security: Quiz [Must / Short Quiz / CertifiedOnDemand.com] Security: Advanced Quiz [Must / Short Quiz / CertifiedOnDemand.com] Security: Feedback [Should / Feedback / CertifiedOnDemand.com] |
Finished this section? Next section: Data Model - Free
heres the updated video series.
http://salesforce.vidyard.com/watch/B1bQnMFg2VyZq7V6zXQjPg
Thanks- will get this updated
Hi John ,
I have a quick question on the article ” A Guide to Sharing Architecture ” under All objectives Met section . In that article –> under Record Ownership and queue section on page 2 , it says that User higher in hierarchy inherit the same access as their subordinates for standard objects. If subordinate has Read only access so will the manager. Is that true ? I thought Manager has full access to record ( minus the delete ) owned by subordinates. Please clarify .
Thanks
KJ
They inherit record security through the role hierarchy. The owner of the record will always have full access to the record, which will get inherited upwards via role hierarchy.
However to take an action you need access both at the record, and object level. So an owner of an account can’t edit the account without also having the object permission to edit.
Example scenario:
User A is assigned Account B. User A has full access to Account B. User has profile permissions to read account object (no others). User A can only view the account they are assigned.
User X is assigned above User A in role hierarchy. User X inherits full access to Account B (despite User A cannot edit the record b/c of object permissions).
I tested the below scenarios to clear my confusion:
1. User A has CR permission on Account object and is owner of Account B. User X has CR permission so this means User X will also have READ permission on that Account B but can’t edit the record because of profile . User A also cannot edit the Account B
2. User A has CR permission on Account object and is owner of Account B. User X has CRED permission so this means User X can edit the Account B but User A cannot
Nice!
Hi John,
The Who Sees What series now appears to be available for Lightning Experience via the Salesforce YouTube channel. Any thoughts on whether it’s better to study in Classic v. Lightning mode for the exam?
https://www.youtube.com/playlist?list=PLnobS_RgN7JblbKvcMjzZUd_RPdEYwiME
The content should be largely the same for both – I suspect the exam will still lean towards classic though
Hi John,
Silly question but I cannot find customize> opportunities under setup (even using quick find). Does one need to enable a feature or contact salesforce in order to set field level security?
You can try:
Setup –> Field Accessibility –> Opportunity–> View By Fields–> Chose the field that you want to manage.
Here you can see manage the access by profile and record type.
If you want other kind of setup, go to Setup and type the name of the standard object like Opportunities, Accounts, etc.
Carlos you champion!
Thanks pal I am able to do it 100% now.
Matt
Nevermind I have found it. Whilst you here :).. My opportunity name has no data for me to set any security so I’m going to have to go and create some test opportunities right?
Otherwise thanks for the guide and the salesforce “who sees what series” is fantastic thanks for that link.
Matt
Hi John, quick question on the who sees what.
The OWD is set to private. Phil is the owner of ABC account, is a US sales reps reporting to US sales director. The users in the US sales rep role can edit ALL opportunity associated with the accounts they own. Tim, an EMEA sales rep, owns an opportunity associated with the ABC account. Which one are correct?
– Phil can view and edit Tim’s ABC labs opportunity (yes that is correct)
– Time can view but cannot edit Phil’s account (that is correct but why ?)
– Tim cannot view or edit Phil’s account (I thought this one is correct but no)
Thanks a lot!
The reason that Tim can view the account is because he owns an opportunity related to that account – this in turn grants him read access to the account (that’s why #2). WIthout some other reason (e.g. role hierarchy, sharing rule, etc.) Tim is not going to have any additional access (why not #3)
Hi John,
I have a a scenario where
There are 8 organisations using my instance. I created a custom object and added all the organisations as records.
there are many facilities(Accounts) where each facility can be a part of many organisations and each organisations can have many facilities. I created a junction object to achieve this requirement. So far so good.
Now I want to set the access to each organisation user.
When a user from organisation A will login to salesforce should be able to view and edit the records that are related to his organisation. Also he should be able to view but not edit records that are related to other organisations.
How can I achieve this. I tried making OWD to public read only and custom object to read/edit under profile. Any changes are giving the same access to all records. Please suggest
Thank you,
Alekhya
Cool question. So that’s a bit tricky.
The inherent problem with this scenario is that sharing is based on a single object (account), where-as your goal is to share based many records related to the account. So ultimately you need to either:
a) summarize the related records on the account, then share the account based on that summarized (field) data OR
b) use a programmatic (possibly process builder or flow) mechanism to create share records that mirror the custom object data (read up on the share object, this is a technical solution) OR
c) re-purpose an existing feature such as account teams, where you create an account team member (instead of using a custom object) OR
d) simplest solution: create a multi-select picklist for the organization on each object you implement sharing, then create sharing rules based on the picklist values (assuming you can use multi-selects in a criteria-based sharing rule, which you might not be able to do… if not, you could use 8 checkbox fields) OR
e) implement territory management (has a bit of overhead and only works for the account and opportunity objects)
That’s a really open ended but interesting problem (there are probably other solutions as well). Drop a line and let us know what path you choose.
Cheers,
John
Hi John, Thank you for a quick reply.
I went through everything thoroughly and thought that
re-purpose an existing feature such as account teams, where you create an account team member (instead of using a custom object) will solve my issue.
So now my organisations are the accounts and I add team members deciding the access.
Now I have a new issue. I will still have facilities that are related to these accounts with many to many relationship. So I created a junction object between accounts and facilities. Now I want to give access to the junction object records that are related in this account can be modified by the team member but he should not have the privilege to modify other organisation records. As this is a custom object. how should I proceed further.
Alekhya.
The junction object (if m/d) inherits permissions from the parent object (account), so if the user doesn’t have edit access to the parent object, then they won’t have access to the modify the junction.
In the settings for the junction object, you can further tweak the permissions of this relationship.
Ultimately you should aim to set the permissions on either the account (via account team) or facility then allow the junction object to inherit those permissions.
My Problem is If I am making the user profile as any standard profile he is not able to see any of the custom object records. So I have create a custom profile and give view all access on the custom object permissions. This is deciding the record access of the object for the user. How should I limit this
I achieved it thank you for the support
Hi John,
On the account team I can give access to account opportunity,contact and account.If my Custom object is a junction between Account and Opportunity or Contact it is controlled by parent hence I give OWD as public read and set the account team access for the parents it is achieved. What if my junction is between Acoount and other custom object. How will I control this access.
Thank you,
Alekhya.
Link “Single Sign-On Implementation Guide” goes to a page that does not exist.
Updated, thanks
Link “Understanding User Sharing” is going to a page that does not exist.
Updated, thanks
Hi ,
I need to confirm the answer to this question :
Universal containers set the organization-wide defaults for cases to private. When a case is escalated, case ownership changes to Tier 2 support agent.
How can a system administrator give the sales operation team read/write access to all escalated cases?
a. Create a case escalation rule.
b. Create a case assignment rule.
c. Create a criteria-based sharing rule.
d. Create an ownership-based sharing rule.
I believe the answer should be “d” .Since the criteria of the case being “escalated” is already met and the ownership of the record has changed.As a next and final step I can just create an ownership-based sharing rule to share the record with the sales team with the right level of access.am I thinking in the right direction?any thoughts anyone?
thanks
rashminder
Where did this question come from? The answer is most likely C- as the criteria would be “isescalated”. This question was recently asked on another page (please don’t double post if that was you)- thanks!
One of the sample questions I found online..and no I havn’t posted this question before..
thanks
I’d love to know the answer to this. I have found mixed answers online. Is it Criteria-Based or Owner-based sharing? I lean to criteria-based bec it doesn’t tell us whether the Tier 2 support agent has the ability to transfer their cases in which case it wouldn’t be safe to assume that they didn’t transfer a case to someone else. To be safe the isescalated = TRUE would be the criteria to share on – can you please confirm?
Yes I would answer this as criteria-based sharing (although to be 100% sure I would actually configure and test it out in my environment)
Viewing Which Users Have Access link not working , Documention not found , under Explain how manual sharing can be used to extend record access. step
Removed- haven’t been able to find a replacement for this doc unfortunately
Hi John/All,
Can someone help me understand why Role field is shown as a mandatory field while creating user and in developer edition I am able to create users without assigning a Role to them. So, is Role mandatory while creating user? If not, then what is the purpose of showing Role field as Mandatory. Any urgent reply would be really appreciated.
Role is shown as mandatory but you can select “none specified”, which leaves the role blank. In short it is listed as mandatory but in actuality is not.
Hi,
Can someone tell me the difference between a manager group and an accounts team ?
Thanks.
They are not related – manager group looks at the manager field on the user record to facilitate sharing. Account teams are used to build sharing on an account record based on who is involved in the management of the account.
Hi,
A custom field is made Read only from the Field level security and Required from Page layout. The Field will be
A. Read Only for the User
B. Required for the User
C. Throws an error and don’t allow to make Read only field Mandatory from page layout
D. User is given a choice in a pop up window
Option A.
If you are an Admin, you might be able to edit the field.
Make sense. Thanks.
‘Viewing which users have access’ link dead ends.
https://help.salesforce.com/HTViewHelpDoc?id=viewing_which_users_have_access.htm&language=en_US
Removed – thanks
Hi John,
Thanks for making a great site for all newbies.
I wanted to understand why Role field is shown as a mandatory field while creating user and I am able to create users without assigning a Role to them. Is Role mandatory while creating user? If not, then what is the purpose of showing Role field as Mandatory.
It is technically speaking not mandatory… its just a quirk that it shows as required (it almost always *should* be populated)
Question/confirmation…..
In the You Tube video “Who See What Overview”, it shows Field Accessibility as having the option to be viewed by either Profiles or Record Types. However, in the Developer edition I am using, you can only view Field Accessibility by type of record for which you would like to grant access.
Can you confirm if this is different in Developer vs other editions?
Field level security is independent of record type (and is determined by profile/record type)… can you point me to the video/spot you are talking about (there might be a spot in setup where you can view FLS by record type, its just not something I’ve used recently)?
I think I found my answer. It is at about the 3:52 mark in the 1st video. I just didn’t go deep enough in my Developer edition; the choice to view by Profiles or Record Types comes AFTER you choose which object you want to edit. The videos move along quickly so will be sure to have my coffee first next time!
Hi John, great Site!
FYI: Dead link for Topic “Viewing Which Users Have Access”: Documentation not found.
Yes it sure is … also dead from with the Salesforce app. I’ll check back in a week or so and see if there’s a replacement
hi john
is it possible for a user to own a record but not be able to see it?
Yes – if they already own the record and then access is revoked (e.g. read access removed on opportunity on the user’s profile) then they would still own it but could not be assigned new records
hi john,l
Which of the following is the best way to make the Field Mandatory for everyone?
A. Page Layout
B. Validation Rule
C. Roles & Profiles
D. Field Level Security
i think it’s B ..
A. Page Layout – would only make it mandatory on specific page layouts
B. Validation Rule
C. Roles & Profiles – not applicable
D. Field Level Security – not applicable as this only determines whether fields are visible/read only/hidden
Hi John
Can you explain which one is the best way to make field mandatory and why
? There is lots of confusion regarding this question .
Thanks
Anu
The best way to make a field mandatory is in the FIELD SETTINGS, lol… there are a lot of similar questions out there and the correct answer isn’t listed 🙂 Assuming that you really want the field to be required for everyone, all the time.
Second to that, a validation rule is the best way to ENFORCE a field requirement.
Page layouts can only enforce the field requirement if the user has visibility to the field, which is not always the case.
Thanku so much John for ur reply.
Thanks
Anu
Quick question regarding IP address. A company has an IP range set up and a user’s profile has a specific IP address. If the user moves out of that IP range but is still under the company’s IP address range, will the user be denied access, granted access or will be required to enter a security code ?
-Thanks
There are two types of IP ranges:
trusted and login ranges
if they login outside of trusted, then they need to activate
if they login outside of login ip ranges, then login will be denied
login ip ranges (restrictions) will override trusted ranges
This link appears to be empty. Winter ’12: Efficient, Manageable Security Policies with Permission Sets
Try: https://developer.salesforce.com/blogs/developer-relations/2011/10/winter-12-efficient-manageable-security-policies-with-permission-sets.html
Existing link appears to still work
I just can’t. Since this is a training environment, I removed all the permission sets associated with Opportunity. Now, when I log as Matt and try to share the Opportunity, I can only share with user Matt. I created a permission set for the role EMEA Sales Rep (Karen’s role) and then I can share the Opp with Karen, but all EMEA Sales rep get the same access. I will try to remove some other stuff and see if works. I tried similar scenario on a Production environment and it worked fine. Really strange because Matt and Karen have the same profile and Matt owns both the Account and the Opportunity, still unable to share either with Karen.
I have 2 users with profile as Sales User. OWD for Opportunity is private. Matt has a role as US Sales Rep and Karen has a role as EMEA Sales Rep. Under Security Control/Sharing Settings/Opportunity sharing rules, I see a Global Sales Rep Group which contains ALL Sales reps (US, EMEA, APAC) sharing ALL Opportunities with ALL Sales Rep as read only. When I login as any user with a profile Sales User, I can see any Opportunities (US, EMEA, APAC) regardless of owner/role.
When I login as Matt, I want to share all his Opportunities with Karen or at least one Opportunity.
I tried a permission set with read/edit access to Opportunities and added Karen, when I log as Karen, I can read but can’t edit Matt’s Opportunities. I logged again as Matt, chose one Opportunity and clicked on Sharing. I can pick Public Groups, Roles, Roles & Subordinates, Users. When I try to chose Users hoping to be able to pick Karen, it shows me only 5 users: One VP of Marketing (role) Excutive User (profile), one APAC Sales Rep (role) Sales User (profile), 2 Marketers (Role) General Marketing User (profile) and one Marketing Director (Role) General Marketing User (profile). All these 5 users were grated read only access thru existing Opportunity Sharing rules. If I chose Roles and pick EMEA Sales Rep with read/edit acces, Karen gets edit access to this Opportunity but ALL other EMEA Sales Reps get the same. How can I give access ONLY to Karen to edit this Opportunity that belongs to Matt? I thought manual sharing was exactly that. Sorry for the long question.
You should be able to share the record directly with Karen – does Karen already have access to the record? If not have you tried specifically searching for her name?
Hey John,
I have troubles understanding something.
While in the Salesforce video that explains role hierarchy, it shows view/edit access can be controlled through roles as well. But when looking at dev org, there is no option to choose whether we can control view / edit access through roles as well.
Access is granted via the role hierarchy (those in higher roles auto inherit access to records owned by those below) and through sharing rules to grant additional access. You are correct that there is a limited impact to security by configuring the role directly.
If I update the password in Salesforce,will SSO reflect it and the other way around it. If I update the password in SSO will the password be update in SFDC?
John, any thoughts?
I don’t think you have a password at all with sso enabled. Your source system(eg active directory) performs the authentication. The password is not stored in salesforce in that scenario. Not an expert here, but that’s what I’ve seen working with clients that have it enabled (you will get an error in salesforce if you try to reset the password of a user that has an sso enabled profile).
Hi john,
Finally stated working with my first ever free app i got from here “The Permissioner” and its awesome.
Thank you again.
Tejal.
Hi John,
I am not clear about the difference between:
Role Hierarchy and Sharing Records with Manager Groups
If an object has Private setting on OWD, the role hierarchy will allow higher roles in the hierarchy of the record owner to access it. Why would i use “Sharing Records with Manager Groups” than?
Thank you,
Gil
Manager groups depend on the Manager lookup field on the user.
E.g.
Bob (reports to) –> Jim
Jim (for whatever reason) is not above Bob in the role hierarchy. The Manager group allows you to declare sharing based on the manager field, rather than the role hierarchy (e.g. direct reports only… versus all those lower in the role hierarchy).
Hi John,
What are External users? what licence to they have to my org. instance?
What is partner (user)?
User sharing for external users
Users with the “Manage External Users” permission have access to external user records for Partner
Relationship Management, Customer Service, and Customer Self-Service portal users, regardless of
sharing rules or organization-wide default settings for User records. The “Manage External Users”
permission does not grant access to guest or Chatter External users.
Regards,
Gil
External users would be customer/partner/community licenses- users in these categories are typically enabled from an existing account/contact record (the resulting user record is linked back to the contact that it was created from).
If you are curious about this I would suggest enabling communities in your org – create a test account/contact and then grant access. DE orgs have community licenses to test with.
Hi john,
It might be a silly question at this stage , but want t know that record access level , sharing rules can only be defined by ADMIN in ur org, ?
—————————————————————————————————————————————————————————————————–
OR
Record owner can also define there sharing rules , to whom they want to share with.
and further in sharing rules and manual sharing ,,,,and hierechy,
another question is …when i have OWD more restricted then public Read/Write…
Hierarchy :
there is a hierarchy and , if i m a subordinate of manager, and as the rule define at Role hierechy my manager can access my roles..so how much manager access allowed for a record at that point( i means is he able to vie,edit,delete,share to others in org.?)
Sharing Rule:
same for sharing rule (how much access to the person have with my record access), can he view,edit,delete,or further can share my record to others?
and same question for manual sharing of my owned record. if i share manually to some user who w/o considering hierarchy…
Manual sharing:
how much access do he have with my record which one shared manually with him?
can he view ,edit, delete, or further share to other user in org.?
at this point , i m really craving for answer related to effect of security model(profile,Sharing settings and again it relate to one of my question on reports and dashboard).
you answers Really helping me gain confidence with my Salesforce learning.
Thank you for putting such an effort to direct learners to the right direction.
Thank you .Thank you .
Tejal.
Tejal.
Sharing rule = defined by admin
Record level sharing = defined by a user that has full access to the record
Role hierarchy grants full access for records owned by users below in the role hierarchy (where grant access via hierarchies is enabled, which is the case for standard objects)
Sharing rule only grants up to read/write (not full access, which grants delete)
Manual sharing also grants up to read/write (read or read/write)
Cheers,
John
Thank you john,
this will help .
Tejal.
Hi John,
The following video has been removed, a shame, I saved it to watch it later now that I have completed your guide but it is gone 🙁
“I love Permission Sets: A Deep Dive Into Profiles 2.0”
Yeah it doesn’t look like it has been replaced by Salesforce either, but is available here: http://fr.podcastmanager.fr/episode-47-i.love.permission.sets.a.deep.dive.into.profiles.2.0-podcast-137301.html
in the Who Sees What: Data Visibility How To Series, the first video “Who sees what: Overview” won’t load. I get an error “Error Code: 200
: NetStream.Play.StreamNotFound”
Works for me. I have a pc using chrome
I would also suggest using Chrome. You may need flash installed as well?
Hi John,
I have a question regarding email notifications I receive as a system admin when OWD settings are changed in SF. How can this be switched off?
Is this setting only valid when changing OWD or also other config?
Secondly, the abbreviation SFDC is mentioned quite a lot, what does it stand for?
Thanks,
Soraya.
Soraya,
SFDC stands for Salesforce Dot (.) Com. Sometimes people just say SF instead.
Hope this helps. (I don’t have the answer to your other question at the moment. Hopefully someone else does.)
Rena
Thanks Rena!
I don’t know of a way to turn off the system emails – Thanks Rena
Hey John can you please help me to understand this question.
Accounts teams are used for the following reasons: (Select all that apply)
a. Share roles with the sales team
b. Are used for collaborative account management
c. Are used for sharing and reporting purposes
d. Are used for splitting of account credit if needed
what his mean by “Accounts teams”
its answer is a,b,c but I’m missing something here.
Hello Bilal:
I am not sure about the answer, I think A,B,C look correct. But, in the attached link, you can learn more about Account Team. Hope this helps.
https://help.salesforce.com/HTViewHelpDoc?id=accountteam_def.htm&language=en_US
Hello John,
Thank you for this excellent Website.
Would appreciate if you could explain or provide a link explaining the difference between team and group in Salesforce. I understand where groups are to be used but no clear understanding on how and when to use teams in sharing.
Thank You
That is a good question. I think Group is mainly used in Chatter and comprises of folks who share common interest or would like to keep themselves abreast on a particular topic; and Team mainly comprises of a group of people, across various teams/departments, that work on specific project. But, it would be great to get more info. on these for clarification.
Hello Sps:
Here is a link that helps clarify the concepts
https://success.salesforce.com/answers?id=90630000000DEbTAAW
Nice link 🙂
Teams are defined for select objects (e.g. accounts, opportunities) and are used to designate which users are involved on the record (e.g. an account team indicates who is involved in managing that accounts) – teams also provide access by sharing the record to the user (so that if you are a member of the account team you can view the record).
Groups are multi-purpose and are generally leveraged for purposes (e.g. within a sharing rule).
John:
I think the answer is A.
B. can only read , edit their own opportunities , but can view every one else
VIEW EVERYONE ELSE? Does not make sense.
Answer A should be correct because it says
Can read,Edit and view their own and every one else opportunities
It specifies EVERY ONE ELSE OPPORTUNITIES.
View ALL permission is on Opportunity Object. So, the User will be able to View Opportunities they own AND ALL OTHER RECORDS ON THE OPPORTUNITY OBJECT that others own.
Pl. correct me if I am wrong.
Correct- but if OWD is set to private, then they would not have read/write to all other opportunity records (view all providing only read access)… its not a very clearly worded question though.
If so, then, you may want to change your answer to A
JohnCoppedge September 3, 2015 at 1:32 pm #
Oh I didn’t see ‘view all’ my mistake – the answer would be b then
I still think the answer would be B. OWD private means that they would only be able to edit and read their own opportunities, then view all would open up view access to all opportunities.
Not sure it notified as a duplicate, so i just to be on the safer side i am posting only the question ..
1) when the user profile on the opportunity was set to Edit and read , and view all .OWD is set to private ,The user can
a)Can read,Edit and view their own and every one else opportunities
b)can only read , edit their own opportunities , but can view every one else
c)can only Read, view , edit their own opportunities and they can’t view other opportunities
My answer is ‘b’ but the answers seems to be ‘a’ .
I am confused now , can you please help me here???
hi can some one help me on the questions please?
It depends on where the user is in the role hierarchy. The closest answer is probably c.
If the OWD is private, that means that the user won’t be able to view or edit opportunity in the same role as they are assigned or any roles above that role. They will be able to view and edit (granted access via the role hierarchy) records owned by users in roles below theirs.
hi John,
Yes i agree with you depends on Role hierarchy, but if the role hierarchy was not enabled . And the OWD is private.
But the User profile has ‘View all’ option , that means they can view all other opportunities .
am i missing some thing here ?
Oh I didn’t see ‘view all’ my mistake – the answer would be b then
I am unable to see the videos, they seem to be private. Is there any other source which can help me view these?
Just figured out…You can watch the videos on http://salesforce.vidyard.com/watch/v66PY49hTxxQiZe1h4RX1A
Awesome, thanks! I will get the links updated shortly.
http://salesforce.vidyard.com/watch/v66PY49hTxxQiZe1h4RX1A
Thank you!
Here’s a link to the Salesforce YouTube Channel playlist of 10 videos for Who See What. The VidYard appears to only have 6 videos.
https://www.youtube.com/playlist?list=PL6747B4DAE356E17C
Nice catch Matthew- updated
Sweet! Thank you!!
This is unfortunate. Yesterday all but one video was view-able. Today only 3 are available. I was only on like the 3rd one in the series and the were great. Why do they keep making them private then public?
This resources provides a visual perspective on Salesforce Security:
https://chendamok.files.wordpress.com/2014/11/salesforce-security-sharing-model-layer-of-visibility-new-page2.png
Wow… Just loved it. Thanks for letting me know John.
HI John,
Who Sees What: Data Visibility How To’s — these videos are made private in you tube. can not access all of them. only 3 videos are made available.
They appear to be back online…
Thanks Patrick.
Only 3 are available.
All but three of the videos in the “Who Sees What: Data Visibility How To’s” youtube playlist are now private.
Hello John – I am not able to see all the videos in ” Who Sees What”. It says the videos are Private.
Do I need any specific user credentials to view those videos ? Please help.
I thought I’d posted this yesterday, but now I can’t seem to find it. I apologize in advance if, in fact, it is a duplicate post.
For some reason, I’m having problems with this concept, and I’m taking my cert exam next week so I’m more than a little nervous :-).
If someone has limited or no access at the profile level to an object and – therefore – to records they own, can the OWDs/Role Hierarchy/Sharing Rules/Etc. give them more access to objects and records that they don’t own?
My instinct would be to say that if you can’t see/edit/etc. your own records at the profile level you can’t see/edit/etc. someone else’s records.
I don’t think I clicked on “Notify me…”
Correct – you are granted the lowest combination of all of the permissions.
E.g. in order to edit a record, you need edit at the object level and edit access to the record. So if your profile is read only on the account object, you will never be allowed to edit account records.
Needs editing:
Each user is assigned a one profile
…should read
Each user is assigned a one profile
Also, a space needs to be between “user(page” in the same paragraph.
Thanks, updated
I’m finding that the user interface screens in the video do not match what I’m currently seeing in the developer or my Enterprise edition. It’s making it a bit more difficult to follow along and find these fields. For instance, there are drop down arrows in the profile settings, but links instead.
Any idea when SFDC will be updating these fields?
You should be able to turn off the new UI:
Instructions within this guide make the assumption that the Improved Setup User Interface is disabled.
I suggest you double-check your org settings by navigating to Setup –> Customize –> User Interface; ensure “Enable Improved Setup User Interface” is not checked.
If you enable this feature, step-by-step instructions within scenarios and exercises will not line up correctly (as the setup navigation menus will be different).
Hi John,
In the section “Describe the capabilities of the Salesforce App Launcher”, the link is damaged:
[sc:youtubelink id=1_cTGhxPJHQ text=”Setting up the App Launcher”]
BTW, thanks for creating this site…I’m working my way through…
Thanks, updated
The repeated links for object access still needs to be updated to: https://www.youtube.com/embed/9hxRSxWRmAc
I found a typo – I think you meant to say “comprised” -> “A group is compromised of users, roles, and other groups.”
Thanks, updated
It looks like a number of these have changed. Here’s the new list of these revised videos –
https://www.youtube.com/playlist?list=PL6747B4DAE356E17C&src_vid=5KLTcu02nfY&feature=iv&annotation_id=annotation_3297769117
updated, thanks!
John,
The Who Sees What Organization-wide Defaults video has been updated – here’s the new link – https://www.youtube.com/watch?v=8rzn-DtG8nc&src_vid=u9PHTLwtomo&feature=iv&annotation_id=annotation_2699026523
Thanks so much for this training series!
Why is it showing only opportunity access and case access options while defining role?
The relationship between accounts, opportunities, and cases is unique and configured in this fashion. Other objects are not influenced by their relationship to accounts in this fashion.
I recently took the exam and was asked the question.
Whats is the Salesforce default OWD for accounts?
Could be worth researching all the OWD defaults for the exam.
Public Read / Write
https://help.salesforce.com/apex/HTViewHelpDoc?id=security_sharing_owd_default_settings.htm&language=en_US
Great notes – thanks James/Ravi
Should note – is already listed in the contents above
What is your best practice regarding the organization-wide defaults? E.g. do you change these settings as soon as you start a new instance? Or do you keep these settings default?
Generally you want to figure out what security settings will apply to the whole organization and then implement them after that is fully understood. If you need a private sharing model, it is generally best to implement sharing rules first – so that when you turn off org-wide access to the object the users will already have rules in place to grant access where needed.
In the “List and describe the standard profiles” section, you have “Solution Manager” listed twice.
Thank you Rennie, I’ve updated this