Skip to main content

#Minimum Access0 debatiendo

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 FeldmanHere 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.

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!

pasted image 0 (1).png

@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 

3 comentarios
0/9000

I always keep my profile metadata outside of the project default directory in order to have better control over deployment and retrieval of the metadata.

 

When deploying a profile from source this way to an environment where the profile does not already exist, extra permissions (i.e., those not defined in source) are added to the Profile in the Org. I think everyone has come across this.

 

But it just occurred to me that this may be happening because new Profiles deployed from source are following the same process as new Profiles created in the Org (i.e., a default profile is marked as the cloning, guessing the Standard profile). This may be old news, but just dawned on me :)

 

It got me wondering if anyone has come across a plugin that lets me define what Profile to clone from when I deploy a new Profile to an Org from source. Would also be a great feature enhancement to the CLI.

 

FWIW, a workaround I'm using is to manually create the Profile in the target environment cloning from Minimum Access. This creates essentially an empty shell and when deploying the Profile metadata to the Org, only the permissions and settings defined there are deployed.

2 comentarios
0/9000

I am trying to create a minimum access profile for a platform user.  I cannot clone the Minimum Access - Salesforce profile, since it is a different license, so I cloned the Standard Platform User Profile.  The Apps, Tabs and Objects were easy to turn off for the profile.  Is there an easy way to turn off all of the Field Level Security for a profile?  Right now, from the profile, I am going into each object and manually unclicking any read access that the profile has.  Is there a way to turn all of them off at once without going into the objects?  If not, is there an easy way to query which fields still have access?

Thank,

Zach

1 comentario
  1. 6 ene 2021, 21:07
    I use SecuirtyZen for this kind of work. It is a paid app though, FYI. They are on the appexchange.
0/9000

Hi, 

 

Is there a way to deactivate a record type? whenever I try to deactivate it errors "This record type Transfer cannot be deactivated because the following profiles use this record type as default".

 

Profiles

Minimum Access - Salesforce

 

Thanks

2 comentarios
  1. 11 dic 2020, 9:26

    hi Callum,

    first, you have to remove the default record type from all concerned profiles :

    object manager/ object / record Type / Page Layout Assignment/ edit assignment

    hope it helps!

0/9000

Hi everyone, Since the summer 20 there is new Profile named Minimum Access - Salesforce. I used it in to have an empty profiles in all non scratch org orgs. This works fine.

When i create a scratch org i create an empty profie xml file, however the profile after creation have always user permissions. I create a script to make it empty. But now with this new Minimum Access - Salesforce i want to clone it after the scratch org creation before pushing source. Can anyone have an idea of how to clone a standard profile automatically with a script ?

 

Thank you all in advance for your answers

1 comentario
  1. 28 jul 2020, 13:56

    I also want to build our custom profiles off of this new profile instead of the "Standard User" profile but there seems to be no way to do this with the Metadata API. The only way is manually through the UI.

    Very frustrating that you can't control profile creation

0/9000