We want a volunteer to be able to log into SF and edit everything that is in SF that appears on our web from the Salesforce Experience Cloud (although not the actual Experience Cloud yet). At the moment, we just want them to be able to view, proofread and modify objects that are shown at cconnect.SYMin.org. We won’t give them delete or create access. This will likely get expanded in the future.
This is the experience cloud site which exposes data from lots of objects and records. The volunteer will be able to click into these and have access inside Salesforce to edit and make changes to the underlying records.
Strategy:
- The volunteer will get a minimum profile (which will be modified to include any necessary default page layouts and record types). How I created that is covered in a previous blog.
- They will get a permission set for working with each of our functional tasks, but delete and create will be muted in the permission set group:
- The tasks to be done are:
- Work with SYM Events (a custom object similar to a scheduled service delivery item) — specifically to fix spelling errors on scheduled items, see service project info (what group is helping out, what is involved), and view impact data (we record a story of impact from most events).
- Work with Inventory items — specifically to fix errors in inventory and see needs information
- Work with programs– specifically to see programs, services and subservices and fix any errors. Programs and services are from PMM. Sub Service is a custom object because we have a learning project that needs hundreds of course listings under a service (ways to earn points). And similarly we have hundreds of store items that need to be listed under a service (ways to spend points).
- Work with Managed Content — this is a custom object that we use to capture stores from donors, volunteers, clients and staff members. It’s basically our blog record. We created it a very long time ago and have incrementally adopted it more and more lately. CRM content might have been an alternative if we were just starting out now although I keep seeing so many issues from users that I’m not sure about that.
Permission Sets:
- Working with SYM Events
- Full CRUD access to SYM custom objects and fields.
- SYM Event Management App access. This application hosts client logging as well as basic access to SYM Events. The page layout contains a flow that will crash due to the restricted access of this profile.
- Run the flow that is the web preview of the record on the page layout (and run flows system permission).
- Working with Inventory
- Full CRUD access to SYM custom objects: Inventory Items, moves, groups, group members, and sources and full access to all fields
- Access to SYM Inventory App and it’s home page
- Requires SharinPix (we have a separate permission set for this already)
- Example current use: For this volunteer, we would grant this permission set in a group and must create and delete.
- Example future use: For an internal user, we will in future assign this permission set and remove access to the object from the various profiles in use (three of them). We would likely delete for everyone except a few people.
- Working with Programs
- Full CRUD access to PMM defined objects Programs, Services and SYM Custom object Sub Services and full access to all fields
- Access to Default Program Record type (apparently defined in PMM).
- Access to SYM Program Manage App and its home page (had to be created first… just created same tabs as PMM managed package except used Analytics tab instead of reports and dashboards. Regrettably you can’t clone a managed package app.)
- Run the flow that is the web preview of the sub-service record on the page layout
- Requires SharinPix
- Requires read access to Program Engagements and Program Cohorts due to a report embedded on the Program page layout. I made these View All so the report might have meaning. This report also means that the permission set must carry Run Reports permission and that the user must have access to the Program Management Reports folder (which must be done at the profile or user level — best through a public group). This report embedded on the page is not crucial to this volunteer but I just wanted to make it work and learn at the same time.
- Working with Managed Content
- Full CRUD access to SYM custom objects and fields.
- SYM Managed Content App access.
- Run the flow that is the web preview of the record on the page layout (and run flows system permission).
Here are the new permission sets. Do note that I name them starting with our org initials so I can tell permission sets I add vs other ones that come along for the ride with other packages or that invade. through some other means. They do have a habit of just appearing from SF sometimes. I have created a custom list view just for our permission sets that start with our initials. You can do the same for profiles and permission set groups, too.
Here is the beta summary of the three permission sets generated by Salesforce:
Working with SYM Events:
Working with Inventory:
Working with Programs:
Working with Managed Content:
Permission Set for SYM Publicity Volunteer
- Add each of the above three permission sets
- SharinPix permission set (previously defined by SYM but not well documented)
- Add Working with Sharin Pix
- Mute:
- Inventory: create and delete object access to all 5 objects
- Programs: create and delete object access to all 3 objects
- Events: create and delete object access, muted fields with PII or useless (contact (client name) details, staff hours — obsolete)
- Managed Content: delete object access (create allowed)
- SharinPix: delete image object access (create allowed)
Empty Profile Changes:
- Default Page Layouts for all 10 objects
Here is the Beta Permission Set Group summary:
Experience Cloud Internal Access:
Since so many of the tasks for this permission set group are driven by access to Experience Cloud connect.symin.org, I wanted to give access to it via a permission set. This doesn’t work like others. You can give members access via a permission set but it’s an Experience Cloud setting. The permission set must be assigned directly to the user. I put it in the permission set group only as a reminder.
Testing:
I created a new user with the empty profile. I assigned them the permission set. I logged in and checked access to all apps. I checked access to each object and page layout.
- Managed Content: all seems to work and be fine.
- Programs: all seems to work and be fine.
- SYM Event: all seems to work and be fine but there are several tabs and items related to logging that show “no permission” errors. This is deemed OK for the moment since it’s true. Better page layout can address this in future.
- Inventory: seems OK
To summarize:
- I created three permission sets that represent jobs to be done. These are created as “wide access” permission sets so they can be reused eventually for our internal staff with different muting allowing creation and/or deletion by appropriate users. The volunteer gets neither for now. This wide permission set is the best practice currently recommended by SF and my current level of implementation backs that up. It is important to remember to mute, however!
- I added default page layouts for all the objects in the permission sets to the minimum profile. It’s such a shame that this has to be done but that’s how it is!
- I dealt with home pages on the apps so that they only require access to relevant objects.
- I dealt with access to anything “extra” that might come from embedded reports or other more complex record page items.
- I created the one permission set group that is specific to this volunteer user. I must create and delete all objects.
- I tested using a nobody user assigned to this minimum profile, no role, and granted this permission set group, making sure the initial screen will be good and making sure changing to each app and each object results in a good experience.
It’s also worth noting that after assigning the permission set to become a member of the experience cloud, this user with this permission set group can switchy into the “app” connection and see the web page as the public does. They can navigate to record pages just like the public does. But when they get to records WITH EDIT permissions, they see pencil icons and can edit the fields! Awesome!
