function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Glenn Nyhan 54Glenn Nyhan 54 

One Standard Profile and Configuring for Individual Users with Permission Sets Alone

We are dealing with two schools of thought around the creation of Profiles at my organization. The contention is that we only need one Profile for the entire organization, and then everything else can be done using permision sets. We have a variety of of end users in various management positions requiring access. The plan (see below in itallics) I personally don't think covers a wider variety of issues, such as field level security and reporting (exposure of information to which certain individuals should not have access). Suffice to say I do not see this plan as working versus individually designed profiles based the end users need. In order to make sure there are no holes in the bucket so to speak I am looking for advice on where those might be and type of correction to this plan that would be indicated to plug those holes. Thanks in advance for any assistance from an expert in security would be very helpful:

“All Users” profile and permission set - Design and Implementation
This document describes the design of the All Users permission sets.
Design
For All Users, we create an "All Users - Read" profile; this profile will be used by all Salesforce users (except system administrators), and it gives read access to those objects and fields that each Salesforce user should have access to. The "All Users - Read" profile provides read access the following types of information:
Basic personal contact information (name, address, phone, email, etc), emergency contact information
Personal affiliations -- Basic account information including affiliations (for both organizations, households, and all other account types)
Basic SFZC donor status (e.g. most recent donation date)
Basic dharma status (e.g. is the person a teacher, a priest, a student; who a student's teacher is)
Non-financial reservations information
Non-financial events & classes information
In conjunction with this profile, we create two permission sets - one to grant Change access and one to grant Delete access. Either one of these permission sets may be attached to user or user group to grant additional permissions as required.
Implementation
In the SFZC Salesforce, the “SFZC Front Office User” user profile was used as the starting point for creating the “All Users - Read” permission set and its companion Change and Delete permission sets.
Field-level permissions control Read and Edit permissions on each field of an object [and object-level permissions control Create and Delete permissions for the entire object]. For objects requiring differing field-level permissions, we disable (uncheck) the Read and Edit object-level permissions - thus allowing the field-level permissions to control those permissions on a per-field basis.
Process to create the “All Users - Read” profile:
Clone the SFZC user profile “SFZC Front Office User” to form the initial version of the “All Users - Read” profile.
Looking at the “All Users - Read” profile as a detailed model, create a permission set “All Users - Delete” which has the same Read, Create, Edit, and Delete object permissions as the profile except omit permissions for those objects that our design does not provide to all users e.g. financial data, management data.
    Notes:  
In each of the individual Object Settings, it is not necessary to assign values for Tab Setting - because the profile already provides those settings. Similarly, it is not necessary to assign values for Page Layouts - because the profile already provides those settings.
I did not give All Users any permissions for Click & Pledge-related objects. (Access to these objects will be assigned in the Development permission sets.)
I did not give All Users any permissions for campaign-related objects. (Access to these objects will be assigned in the Development permission sets.)
I did not give All Users any permissions for Classy-related objects. (Access to these objects will be assigned in the Development permission sets.)
Contacts TO DO: Assign field permissions.
I did not give access for DEPRECATED objects.
I did not give access for Fund-related objects. (Access to these objects will be assigned in the Development or financial permission sets.)
I did not give access to Guest Students Information.
Households - TO DO: Assign field permissions.
I did not give access to Trigger Handlers.
Issue:  A few objects e.g. “CC Front Office Operations” have the special permissions View All and/or Modify All. I have copied those settings into this permission set.
“All Users - Delete” / Object Settings / Contacts / Field Permissions: In this “. . . Delete” permission set, the object-level permissions grant all permissions,
TO DO: Remove Create, Edit, and Delete permissions from the starter version of the “All Users - Read” profile.
MORE goes here
END of document.