Ask Search:
Deb WellerDeb Weller 
Has anyone else tackled sharing and access for accounts and contacts that require Enhanced Handling or Special Practices (typically US Fed)? --- these require that only US Citizens on US soil access the accounts/contacts and identifying information like name, email, IP, log data, etc.     I have seen other large enterprises use completely separate SF orgs for these customers, but our org is not that large.   I am trying to figure out the best way to limit who can see specific accounts/contacts and cases for them.  It's a very small group of accounts, so I am trying to keep maintenance to a minimum.

If anyone has details on what has worked well/not worked, or creative solutions, I'm all ears!  
Best Answer chosen by Deb Weller
Bhavna BanodhaBhavna Banodha
HI Deb,

You can acheive that via Sharing Settings/OWD, Roles and Profiles.
You can create a Group with all US Users.
1. To share ther records - You can make OWD for your Org as Private and with Sharing Rules: share the data between the group memebers
2. In case records needs to be shared with everyone and only certain fields needs to be hidden - With Field Level Security at Profile level you can hide certain fields and Usrs of that profile will not be able ot see those field data in records.

Hope it helps!!
Thanks and Regards,
Bhavna Banodha
Erik PetersonErik Peterson 
Hello all,

I have allowed "edit" on email opt out check box at the profile level.  I also created a permission set, to allow edit of this checkbox.  I have a small subset of support desk and call center users that need access to this, so the permission set would be better.  Currently neither of these changes are allowing them to do so.  check box is still locked.  
Any assistance would be helpful.
thank you.
Best Answer chosen by Erik Peterson
Arpit JainArpit Jain
Have you check if this field Email Opt out (HasOptedOutOfEmail) is Read-only on page layout assigned to the support Desk or call center users.
Maximilian BehnMaximilian Behn 
Hello, 

I have been researching this topic quite a while now but could not get a definite answer.

The situation is as follows:
We have two kinds of Opportunities currently distinguished by record types.
One Type of Opp is only for B2C Opps and the other is for B2B Opps.

The employees handling the B2C Opps should not have any access to the B2B Opps and vice versa. 

I know that record types are basically only used as "themes" and can not be used to restrict access but how would it be possible in this scenario to limit the access as described above? 

Thanks for the help.

 
Best Answer chosen by Maximilian Behn
Sunil SarillaSunil Sarilla
Hi Maximilian,
You are right record types do not control data access.
Since you want to restrict the data based on the record types, you will have to do the below
First make the OWD for Opportunities to Private
secondly, you will need to look into the role hierarchy ( the users in the higher rolle hiearchy will always have access to Opportunities that are owned by the Subordinates)
finally, in order to share the Opportunities within the teams, you will need to create Criteria based sharing rules based on the record type.
Marie-Sophie LegoMarie-Sophie Lego 
Hi, my colleague receives a message to prove her identity with a code being sent to her in a seperate mail every time (!!!) she logs into SF... No one else in our department has to verify like she does.
Could anyone help or has an idea how to fix? Any suggestions would be great :)
Best Answer chosen by Marie-Sophie Lego
Amit SinghAmit Singh
Hello Marie,

Please ask your colleague to add his/her IP into Network Access using following steps.

Setup -> Security Controls -> Network Access -> Trusted IP Ranges and Add his/her IP.

Also refer below articles
Set Trusted IP Ranges for Your Organization (https://help.salesforce.com/articleView?id=security_networkaccess.htm&language=en_US&type=0" target="_blank)
https://help.salesforce.com/articleView?id=users_profiles_epui_login_ip_ranges_edit.htm&language=en_US&type=0 (https://help.salesforce.com/articleView?id=users_profiles_epui_login_ip_ranges_edit.htm&language=en_US&type=0" target="_blank)
Identity Verification Code prompt appears on every login attempt (https://help.salesforce.com/articleView?id=000232553&type=1" target="_blank)
Jerzy SobonJerzy Sobon 
Hi everyone:

Would like to know under what security context does Process Builder run? Is it possible for a user to create/edit a record that launches Process Builder that updates another record they don't have the right to update? If it is possible, what happens? Does the user get an error, the sys admin, or nobody is notified.

In other words, is it possible for a user ti launch a Process Builder process that updates some data they don't have the right to update?

Thanks a lot!
Jerzy
 
Best Answer chosen by Jerzy Sobon
Mayank SrivastavaMayank Srivastava
Jerzy, Process Builder runs in the system mode so the object and field level permissions both will be ignored for the user who triggers the Process.
However, if a Process is launching a Flow (which runs in system mode), the whole automation will ru in the system mode.
Hope that makes sense.
Jess PyneJess Pyne 
What's best practice for sharing records across an entire org?

Every user needs read/write access to all Leads, but due to our Pardot setup I need to restrict OWD for Leads to Private to exclude our Pardot Connector User. New users will need access to all Leads by default whatever their role (across different departments), and without changing additional settings.

Our current role setup is used more in conjunction with our managed package app than for record access, as all users have read/write access to all records.

I'm new to Sharing Settings - at the moment I'm looking at creating a public group containg all roles except the Pardot Connector User (which doesn't exist as a role currently so I'd have to create this), and using a sharing rule to give all access to all Leads to all of these roles.

Is this best practice? Is there a better way to do this using roles?
Best Answer chosen by Jess Pyne
Ashutosh TripathiAshutosh Tripathi
Yes, you can put them all in the public group and give them access. In that way only that group of users will get the access instead of all. And by defauld record is private from OWD so no worries for others.
Mario DMario D 
Our sales org is organized with sales people and one support personnel for each sales rep.
Sales reps are owners of the accounts and they cannot see each-other's accounts.
The sales support people are assigned to the accounts through a custom filed.
Is there any way to limit the visibility to the accounts for the support people same as well?
 
Best Answer chosen by Mario D
Benjamin DoolanBenjamin Doolan
I'm new so please forgive me if this is a stupid question (or answer for that matter)...
Is the custom field that is used part of a criteria based sharing rule? Are you having more than 1 support person assigned to the same account and want to limit their visibility to only accounts for the sales person that they support?

Have you tried account teams? Since it is a 1:1 sales-to-support ratio and the type of access could be controlled for the support personnel as well as limit them to accessing only accounts they are on. Downside to this is I think the sales person would have to manually add the team to each account.

I also think a more automated method might be to put each support & sales personnel into "groups" and then construct a sharing rule for each group based on the owner of the account record (which would be the group). Then assign that sharing rule to each respective support person.

Hope that helps and if someone comes along and sees errors above please help me learn!
 
Kamalakannan SomasundaramKamalakannan Somasundaram 
I've created an object and for that i've created a record type as well ... 

What is the use for the record type and where we using it?

(i'm a begginer so have lot of questions in my mind.)

Best Answer chosen by Kamalakannan Somasundaram
Sindoora gSindoora g
Record Types are used to create different business processes.



for example : if you are working on an application that manages two business process like you want to manage accounts for two commodities A and B .

You want certain fields and picklist values on Commodity A page and different ones on Commodity B page.



You create 2 record types for  Commodity A and B for different picklist to appear on these pages and 2 pagelayouts to control the fields on A and B commodities.



you will assign record type to Page layout i.e for record type A what pagelayout should be displayed,same for B.



Now when you click on Account Tab ,you will have the option to select record type A or B .



You can also control Users who have access to record type A or B or Both in profiles.



Hope you got some idea.
Devon HowardDevon Howard 
I have several questions about the implications of using permission sets. I have consulted all of the help materials on this topic that are available through the Salesforce Help & Training portal. My hope is that rather than responding to these questions with SF link to knowledge articles, documentation, etc. (unless the link really does answer the questions), I will get specific answers to my questions.

Currently, we do not leverage the role hierarchy structure. We use only a few objects and set the OWD for those objects to private.  We then use profiles, sharing rules, and public groups to control object and record access. I am trying to determine whether permission sets would allow us to:
a. reduce the number of profiles we use
b. reduce the number of public groups we use

My questions are:

1. Can we use permission sets to restrict access compared to the profile settings, or only open up access from the profile baseline?

2. In this location: Permission sets > Apps > Object Settings > select the object > field permissions, does the edit permission give the permission set assignee permission to edit field values on records she has access to, but does not own? What does this edit permission do, exactly?

3. What is the relationship between public group membership and permission set assignment?  It seems to me that both grant individual users (or groups of users) access to data that they could not access based on profile alone. The way they work differently, however, is still vague to me-- even after reading the help materials on SF. What are the benefits of using each?

4. Is it possible to provide access to report and dashboard folders through permission sets? Currently, if a user building a report folder selects "this folder is accessible only by the following users"  the options to select from are role, role and subordinates, and public groups. We only use public groups from this drop down list. We would like to use permission sets instead of public groups (or roles) to grant access to report and dashboard folders. Is it possible to add permission sets to that drop down list?

Related to the above question, I tested a work around for granting access to a report folder: Permission sets > System > System Permissions > enabling create and customize reports, run reports, report builder, and manage dashboard permissions. Then, in Permission sets > Apps > Object Settings > (example custom object), I enabled access to the XYZ record type.

I assigned the permission set to a user. I then checked to see if my user with the permission set had access to the XYZ report folder. The user did not have access. I then added my user to the XYZ public group and confirmed that the XYZ public group had access to the XYZ report folder. I tested my user's access to the XYZ report folder, and my user did have access. It seems, therefore, that the only way to grant report/dashboard folder access using permission sets would be to add permission sets to the options in the "this folder is accessible only by the following users" drop down list.

Clarification on any/all of this is much appreciated!
Best Answer chosen by Devon Howard
Rebecca WhitefieldRebecca Whitefield
1. Permission sets can only grant permissions, not deny them so they can only open up access.

2. The edit permission in this location allows users to edit field values on records they have access to. Record access is determined through sharing settings.

3. The short answer is they give access to different things. As I alluded to in my answer to #2, permissions and sharing settings are two separate areas of security. Permissions determine the kinds of records users can create, read, edit or delete. Sharing settings determine which individual records users can view and edit in each object. So the difference in permission sets and public groups is that permission sets allow you to grant additional permissions to specific users, whereas public groups are used in sharing rules to grant access to specific records. 

4. To my knowledge, it is not possible to provide access to report and dashboard folders through permission sets.
Zeeshan UddinZeeshan Uddin 
How can I change my email address on as my email domain has been changed.
Best Answer chosen by Miglena (Salesforce.com) 
Alfred SmithAlfred Smith
I went to answer tab, then I saw the butten and I could ch​ange my emailUser-added image
cangoragilation!