Ask Search:
Melissa HallMelissa Hall 

Security by Record Type

I've researched and tested permission sets, validations, and sharing settings for this issue, but for some reason none of those items will allow my users to create and edit by record type.

Scenario:
  • Group A needs to create, edit, and delete the Financials object when record type is Submission - Audited Financials
  • Group B needs to to create, edit, and delete the Financials object when record type is Submission - Non-audited Financials
  • Groups A & B need to create, edit, and delete the Financials object when record type is Moody's Ratings Review
So, in a nutshell, I need all users to read everything on the Financials object, but only select users can create and edit, based on record type.  Oh, and each record type is assigned to it's own page layout.

Solutions tried:
  • Validations: Group A's profile is set up to have CRE rights for the fields on the Financials object.  I've written a validation that will only allow them to edit when the record type is Submission - Audited Financials.  I cloned the validation to allow Group B to edit Submission - Non-audited Financials and cloned a third validation that allows Groups A & B to edit Moody's Ratings Review.  Still with me?
    • This solution gets the job done, but Group A can still create a page for Financials when record type is Submission - Non-audited Financials (aka the only record type they shouldn't create or edit), but when they try to save the record, the validation kicks in and won't allow them to save.
    • I don't want to frustate my users, but will use this as a last resort since it's the only thing working properly at the moment.
  • Permission Sets: I set all the profiles so that every user has read only access to the Financial's fields.   I created three permission sets that allowed the groups above to have CRE rights to their specified record type, and assigned my users to each permission set.
    • This solution does butt-kiss.  If I assign a user to one of the permission sets, they have CRE for every record type.  Ideas on where I'm going wrong?
Permission Set Screenshot
  • Sharing Settings: so I did even more research and discovered that Sharing Settings should be the path to go ... or so I thought.  
    • I set up a Public Group with users from Group A.  Set up my criteria-based sharing rules for Financials and ... Group A cannot edit Financials for any record type.
Sharing Settings Screenshot

Okay Salesforce gurus, can someone please help me figure out what I'm missing, and how to get my users set up to Create and Edit the Financials object by record type?  Thanks!
Best Answer chosen by Melissa Hall
Todd GillTodd Gill
Melissa,

I think you’re very close.  It's might be helpful to look at this scenario by separating a few security concepts:

1.  Allow read only or read/write access to records based on record type = controlled by OWD and Sharing Rules
2.  General ability to perform CRUD operations on records of an object IF sharing rules provide visibiltiy = controlled by Profiles and Permission Sets.

It gets tricky when OWD, sharing and profile settings overlap or appear to conflict with each other.

Record types settings in Profiles - When you restrict a profile so that it includes only a subset of record types for an object, you are really only restricting those users in what record types they can create or which record types they may use when changing the record type of a record they can edit.  However, the profile/permission set settings will not restrict a user from viewing additional record types that were created by others.

Permission Sets control basically the same settings as Profiles - Permission sets are basically just a way to add privileges to a more restrictive profile.  They control essentially the same privileges as profiles. They are used to selectively “opening up” profile-level settings for sub-sets of users. 

Also, remember that if a user's Profile or Permissions Set sets specific record type restrictions for an object, the user can still view all records assigned to any record type for that object as long as the user has visibility to the records via sharing rules.

So, based on what you've shared here, here is an approach that might be helpful:

Sharing Rules Settings
  - Set OWD on Financials to Public Read-Only
  - Create criteria-based sharing rule to give the Group A Read/Write access to Financials records with record type "Submission - Audited Financials" 
  - Create criteria-based sharing rule to give Group B Read/Write access to Financials records with record type "Submission - Non-Audited" 
  - Create criteria-based sharing rule to give Group A and Group B read/write to Financials records with record type "Moody's Ratings Review"

Profile Settings
  - CRUD: make sure members of Group A and Group B belong to Profiles (and/or to Permissions Sets - see below) that allow read, create, update, delete access to the Financials object, since they will need to be able to edit records they have Read/Write visibility to (based on sharing rules).  Make sure all other profiles besides Group A and B have read access to the Financials object.
  - Record types: Here, you can limit which type of record types may be created by each profile, or which record types a user may change a record to if they have read/write access to the record (based on sharing rules).  But again, this setting does not limit which record types may be viewed or edited.

I don't necessarily see a need for Permission Sets in the scenario described here, but they might apply based on other requirements.

I hope this helps!

All Answers

Stephen PriceStephen Price
Hello Melissa,

You can accomplish what you are trying to do with two different profiles.  Profiles will allow you to set access to record types independent of another profile.  So for example:

Profile 1 (rights for edit/create/delete)
Record types: Submission - Audited Financials and Moody's Ratings Review

Profile 2 (rights for edit/create/delete)
Record types: Submission - Submission - Non-audited Financials and Moody's Ratings Review

The cross over is that both have access to the shared record type Moody's Ratings, but only have access their respective other record types.

-Stephen
Melissa HallMelissa Hall
Is creating separate profiles the only solution to set access on different record types?  If that's the case, I'll basically need to give every one of my users a unique profile because we have an upcoming project that is also based upon record type.  I thought that was the point of permission sets and sharing settings.
Stephen PriceStephen Price
If you are going to be using a lot of different rules, then permission sets is definitely the way to go.  Users can also be assigned to multiple permission sets, which is useful.  But it can get convoluted if you are making a bunch of different permission sets for under different profiles with different sharing rules. 

So it really depends on your use case.  But it sounds like Permission sets may be the way to go for you.
Todd GillTodd Gill
Melissa,

I think you’re very close.  It's might be helpful to look at this scenario by separating a few security concepts:

1.  Allow read only or read/write access to records based on record type = controlled by OWD and Sharing Rules
2.  General ability to perform CRUD operations on records of an object IF sharing rules provide visibiltiy = controlled by Profiles and Permission Sets.

It gets tricky when OWD, sharing and profile settings overlap or appear to conflict with each other.

Record types settings in Profiles - When you restrict a profile so that it includes only a subset of record types for an object, you are really only restricting those users in what record types they can create or which record types they may use when changing the record type of a record they can edit.  However, the profile/permission set settings will not restrict a user from viewing additional record types that were created by others.

Permission Sets control basically the same settings as Profiles - Permission sets are basically just a way to add privileges to a more restrictive profile.  They control essentially the same privileges as profiles. They are used to selectively “opening up” profile-level settings for sub-sets of users. 

Also, remember that if a user's Profile or Permissions Set sets specific record type restrictions for an object, the user can still view all records assigned to any record type for that object as long as the user has visibility to the records via sharing rules.

So, based on what you've shared here, here is an approach that might be helpful:

Sharing Rules Settings
  - Set OWD on Financials to Public Read-Only
  - Create criteria-based sharing rule to give the Group A Read/Write access to Financials records with record type "Submission - Audited Financials" 
  - Create criteria-based sharing rule to give Group B Read/Write access to Financials records with record type "Submission - Non-Audited" 
  - Create criteria-based sharing rule to give Group A and Group B read/write to Financials records with record type "Moody's Ratings Review"

Profile Settings
  - CRUD: make sure members of Group A and Group B belong to Profiles (and/or to Permissions Sets - see below) that allow read, create, update, delete access to the Financials object, since they will need to be able to edit records they have Read/Write visibility to (based on sharing rules).  Make sure all other profiles besides Group A and B have read access to the Financials object.
  - Record types: Here, you can limit which type of record types may be created by each profile, or which record types a user may change a record to if they have read/write access to the record (based on sharing rules).  But again, this setting does not limit which record types may be viewed or edited.

I don't necessarily see a need for Permission Sets in the scenario described here, but they might apply based on other requirements.

I hope this helps!
This was selected as the best answer
Melissa HallMelissa Hall
Todd, thank you so much!  Your sequence was exactly what I needed, and my security now works just the way I needed it.  I realize now that only having a criteria-based rule for one record type and not the others was likely what was causing me troubles.  I'm tickled pink.  Thanks for being so clear with your instructions, they were very easy to follow.
Sandip ChakrabortySandip Chakraborty
Todd , you mentioned to setup OWD as public read only. if it is Public do we really need to setup sharing rule ? Will it be Private Read only ? I am new to Salesforce hence  I have a doubt on this.
Steve GummereSteve Gummere
Sandip, the sharing rule gives edit ability for the records they are allowed to edit.