#Profiles0 utenti parlano di questo argomento

Hello - I am a solo admin for a nonprofit and I am starting the journey of migrating from Profiles to Permission Sets.  I have been doing some research and talking with others, watching presentations, and more.  So at a high level, things are making sense.  However......I am also trying to determine what are the main things that are important and what is just "noise". 

For example, I am doing some comparisons of the profiles and I am also just reviewing what access each profile has, not what is just different but do I have profiles that have access to object and fields that they should not have (or do not use). 

I am using the Elements app to help with this and one thing I noticed is that in some cases, even if a person has a Profile called "Coach" for example and that Profile does NOT have access to a specific Object, like "Opportunities" they are showing that they DO have access to a number of fields in the Opportunity Object.  

Now, I know that since they don't have access at the Object level they can't view those fields.  But my question is Do I need to make sure that I remove the field level access on the "Coach" profile and another other profiles that were cloned off that?  Or just leave it as is and just focus more at the overall Object level? 

Again, just trying to determine how much clean up (or pre work) I need to do. 

I should mention that our org has been using SF since 2009 and I was not here, so I really don't know what they did to make a number of the profiles or specifically what base profile they cloned a lot of what I am dealing with now. 

Anyway, any insight/advise is appreciated. 

Here are two brand new posts on what I believe are best practices for the next decade of Salesforce user provisioning at small organizations. Lol... what a statement. I'll guarantee you that what I have in my org of more than ten years is a far cry from best proactive now... probably wasn't then. But I've been trying! And it's starting to save time and make more possible...

It starts with a minimal user profile. Then you add tasks to be done broad permission sets and put them into a permission set group muted down to those needed by the user or user group.

It's not easy stuff but I highly recommending learning how. There is too much valuable data in your org to continuing running "wide open" and there isn't enough time in the day to manage it any other way that I know about.

P.S. LAtely I can't seem to get my game together to release a blog on Wednesday which is probably the best day. So please comment and share on Wednesday. Lol

1. Brief intro to creating an empty or minimal profile article: (summary created with help of AI): 

Enable restricted access login users like volunteers or interns by creating an empty

profile. Salesforce’s default “Minimum Profile” has been inadvertently added

Permissions by us (you have to uncheck it each time you add stuff), making it useless and requiring cleanup. Workbench allows easy addition 

of a blank profile with only name and license type, saving time and effort compared to

searching for granted access. Created a test user named Nobodyx @SYMin with no

role, assigned minimum profile, and unique email address. Login-as admin without

password. Currently, there is only one app (and one rogue app) available.

https://mighyforce.dreamhosters.com/2024/01/sym-publicity-volunteer-permission-set-group/. Compliments to @Tom Bassett for the neat method to create your own.

When you login as a user created with no checkboxes per missions other than this profile, you simply get lightning with one app (chatter). This is what we want! (P.S. I did eventually get rid of Power of Us Hub... it was a tab setting apparently ignored by the profile and permission sets) @Cheryl Feldman

2. Brief intro to creating a permission set group to capture a complex jobs to be done for a volunteer publicity helper: (summary created with help of AI):

A volunteer will access Salesforce Experience Cloud to edit objects at

cconnect.SYMin.org, allowing them to view, proofread, and modify data from numerous

records. Volunteers will receive a minimum profile and permission set for working with

functional tasks. Tasks include working with SYM Events, inventory items, programs,

and Managed Content. They will fix spelling errors, view impact data, and fix errors in

various objects. CRM content may be an alternative if needed. The document outlines

permission sets for various SYM objects, including SYM Events, Inventory, Programs,

and Managed Content. These permissions require full CRUD access to custom objects,

SYM Event Management App access, and access to the SYM Inventory App. The

permission set also requires read access to Program Engagements and Program

Cohorts, and access to the Program Management Reports folder. The document

emphasizes the importance of these permissions for effective use. Users assigned to

the experience cloud can access web pages, navigate to record pages, and edit fields

with edit permissions.

This is a veal example--it's messy... not simple at all. But it wasn't hard. And the parts are reusable and set the template for how all future tasks for internal ad external users will be provisioned.:

https://mighyforce.dreamhosters.com/2024/01/sym-publicity-volunteer-permission-set-group/

Here is the finished user logged in. They see a number of apps because the items exposed on our experience cloud site come from a variety of places. They have no delete rights for most items, although our custom object for managed content (a CRM type object) has full rights. Very cool... nothing distracting or dangerous! Just what everyone would order for a new person!

@The Blog Group @MVPs & AppExchange All Stars @Nonprofit and Education MindShare @Ryan Ozimek @Nonprofit User Group, San Antonio, US @Nonprofit User Group, Dallas, US @Nonprofit User Group, Houston, US @Nonprofit User Group, Austin, US #User Provisioning #Profiles #Minimum Access