Requires access to export permissions, profile IDs and names and permission set assignments
What is the problem?
uhhhhh - this. Try figuring out what row a field is in..... 4 times
This makes edits to Field Level Security (FLS) and Object Level Security (OLS) overwhelming
You know the quote by Erdos, “Mathematicians turn coffee into theorems?”
I am hoping this is well easier than acheiving a low Erdos Number or Proving an Open Conjecture
What are the parts? Data Exports Galore and an Excel File
Downloads Needed:
Permission Sets Field Permissions Profiles Object Permissions
Optional:
Permission Set Assignments Users SetupEntityAccess (Apex Permissions)
Data Loader Directions: Data Loader Directions
Permission Set ID
Everything revolves around Permission Set ID
ID is 18 characters (case insensitive and hardest part) and permission sets refer to profile IDs OR Permission Set IDs
Permission Set ID is easy if you are updating a permission set, just use that ID
Profile ID is the name of the permission set, almost
IDs – keys that turn gobbledy gook into gobbledy glory
18 characters of huh?
First three tell you the object
The last three make it case insensitive
Learn from your peers and don’t use 15 character IDs – the ones reports give you - for anything that requires correct data
Now that we may not need a Power of 1 field, that formula can be replaced by CaseSafeID(Id) - which gives a reportable AND usable ID
DataLoader Exports
Be sure to Click the Show All Salesforce Objects Box in Data Loader
You may also need a security token for data loader:
Username: becca@gmail.com.partyblog
Security token (case-sensitive): bgaV999dontCryeHZEXoMhtz
Enter password as PasswordSecurityToken
Passw0rd!ubgaV999dontCryeHZEXoMhtz
Be sure to Click Show All Salesforce Objects in Data Loader
Objects to retrieve: Permission Sets Field Permissions Profiles Object PermissionsWe want the Permission Set ID from a profile needing updates or just the Permission Set ID, if updating a permission set.
That becomes the Parent ID In Object and Field Level Permissions
They both use the Developer Name of the Object to Identify the SObject
The field is referenced by Object.FieldName
A field can have read and edit permissions
An object can have the above and Create, Delete, Modify All (records of the object), or View All (records of the object)
There is an Excel file with formulas already built if the columns are pasted in their respective tabs
Paste the columns instead of selecting all and then update so formulas fill correctly (if you want to)
Search the Profile Tab for the Profile of interest and copy the ID
Go to the Permission Set tab and Find the Profile ID
Copy the Permission Set ID
Highlight the ID column from the top and
Click Conditional Format
Text that Contains
Paste that ID and Enter
Format Paste to the
Parent ID Columns
in Object Permissions &
Field Permissions
Sort by Cell Color
This gets easier the more you do it, I promise.
Now you can sort and edit the permissions that are there and build the new ones
This is also where you validate that the permissions do not already exist as you will get an error on upload if they do
From here on out, we use field and object names, so the hard part is done!
Columns:
Permission Set IDs
Object and Field (Object.Field) API names (NOT labels)
Object CRUD (Create, Read, Edit, Delete, Modify All, View All)
Field CRUD (Read, Edit)
Save as csv and load!
This uses field and object names, so the hard part is done!
Just pull each Permission Set ID into the Parent ID column in the fields/objects to update
Add Permissions to the Field Permissions Tab and Object Permissions Tab
Next time editing existing profiles, you have the perm set ID, so only the field and object permissions are needed
OR, if it is a new object or permission, you can pull just the permissions and create the Object and Field Perms in excel
Save each as a .csv
Load with your favorite data loader tool
Upload with Data Loader
If you didn’t edit the header, you can automatch fields to get your mapping
More on IDs, in case you were curious... and largely just a copy of the links...
https://salesforce.stackexchange.com/questions/1653/what-are-salesforce-ids-composed-of says of IDs:
First 3 characters - key prefix that identify the object type. There are a few exceptions to this where multiple objects all share the same key prefix! There are a number of fixed key prefixes that are common across all of Salesforce. http://www.fishofprey.com/2011/09/obscure-salesforce-object-key-prefixes.html#0D5
Custom objects get a unique key prefix per Org.
The 4th and 5th characters - Reserved. Currently used for the instance id Indicates which pod/instance the record was created on. Note that data may be migrated to other pods over time.
6th character - Reserved. Will be 0 until such time that Salesforce has a need for it. Next 9 characters - basically a really big number. Like 62^9 big.
Last 3 - 3 character suffix that will make the Id unique case-insensitive
The Id Field Type is a base-62 encoded string.
Each character can be one of 62 possible values: a lowercase letter (a-z) - 26 values, an uppercase letter (A-Z) - 26 values, a numeric digit (0-9) - 10 values