#Systems Administrator21 personnes en discutent

Hi Nancy, 

(or vice versa) for an existing field. 

Go to Setup → Object Manager → Your Object → Fields & Relationships → Your Field 

Click Edit 

You'll see the picklist is tied to a Global Value Set — there is

here to detach it and switch to manual values. This choice is locked in at field creation and isn't editable afterward. 

@Nancy MagalhaesOne limitation I’d consider is the underlying data model: the native Relationship Map is primarily account/contact relationship-focused, so a true side-by-side “customer org + our internal org” hierarchy is difficult to maintain dynamically.

If this is a recurring sales use case, I’d model the internal stakeholders and customer contacts as related records with an explicit relationship type (Decision Maker, Executive Sponsor, Account Owner, etc.), then surface those relationships through a custom LWC. That would keep the visualization data-driven instead of relying on manually added cards, while still keeping everything inside Salesforce.

 If you are working with a mail house/print service provider and intend to continue using them, make sure to send your list with the account id so you can match them up after the fact.  Having said that, using a Mail house and moving your address quality initiatives downstream prior to mailing is the absolute worst place to manage data quality.  IMO, data quality is best managed at the record of truth proactively.   This includes building a custom app or using a managed package like NCOA 4 Salesforce which is available now and in the process of getting in the app exchange.  The process handles the entire data set (not just what you are mailing) and works with a few clicks.  You can choose how to import and avoid duplication.  Happy to show it to you or can see a common demo: Typical NCOA 4 Salesforce demo to a nonprofit organization 

Hello Heath, 

Honestly, what you’re describing is exactly the kind of scenario where Salesforce native reporting starts to feel stretched. It works great for structured, object-based reporting, but once you get into a lifetime journey model with re-engagements, mixed time contexts, and loosely connected data, it creates noise that’s hard to cleanly model in standard reports. That’s usually the signal to at least consider something like Tableau or Power BI — not because Salesforce is failing, but because your data storytelling has become more complex than what report types and joins can comfortably handle.

That said, I wouldn’t jump tools immediately. External BI tools shine when you need cross-object, time-series, historical layering, and flexible data modeling — basically building a cleaner “analytics layer” on top of Salesforce. They’ll let you reshape your data and remove that noise. 

A lot of orgs in your situation land on a hybrid approach — keep operational dashboards in Salesforce, and use Power BI/Tableau for impact reporting, leadership insights, and longitudinal analysis where your lifetime model really matters. So yes, it’s less about when to move completely and more about when to extend, and from what you described, you’re pretty close to that point. Hope this helps!

The Current Best Practice

Install for System Administrators only, then use Permission Sets (or Permission Set Groups) to grant access to other users. This is the right approach, and here's why:

Why This Model Makes Sense

1. Profiles are becoming baseline containers – They define the minimum floor of access (object CRUD, app visibility, page layouts, record types). The System Administrator profile remains special because Salesforce pushes critical updates to it (like the recent "Manage Connected Apps" permission).
2. Permission Sets layer on top – All incremental access—including app-specific permissions, Apex classes, Visualforce pages, and custom permissions—should be granted via Permission Sets or Permission Set Groups.
3. Admins still need Permission Sets sometimes – As Judi correctly noted, even after installing for Admins, some apps require you to assign their Permission Set(s) to actually use the app. This is intentional: the app may include custom permissions, connected app policies, or field-level security that aren't automatically granted just because you're a System Admin.

What Happens During Installation

When you install an AppExchange package and select "Install for Admins Only":

• Profile-level grants (Apex classes, Visualforce pages, custom tabs) go to the System Administrator profile
• The app's Permission Sets are created but not automatically assigned—you must assign them manually, even to yourself
• Other profiles get nothing unless you explicitly choose them during install

Recommended Pattern

For System Administrators

• Do not clone the standard "System Administrator" profile. Salesforce deploys critical updates only to the standard profile.
• Create a custom Permission Set (e.g., "Acme System Administrator") to grant any additional permissions your admins need beyond the standard profile—new field access, integrations, etc.
• Assign app-specific Permission Sets to admins when needed.

For End Users

• Install apps for Admins only.
• After installation, assign the app's Permission Sets (or build Permission Set Groups) to the appropriate users based on role/function.
• Use Permission Set Groups to bundle related permissions (app access + object permissions + field access) for easier assignment.

Why Profiles Still Exist in the Install Flow

Salesforce hasn't fully deprecated profiles—they're still the required baseline for every user. The install wizard asks for profiles because:

• It needs to grant access to Apex classes, VF pages, and other package components
• Not all packages include Permission Sets (especially older ones)
• The System Administrator profile is the safest default for initial installation

Over time, expect Salesforce to evolve this (possibly auto-creating Permission Sets during install or allowing install without profile selection), but for now, "Install for Admins Only" + Permission Sets is the cleanest, most future-proof approach.

Bottom Line

You're on the right track. The confusion is normal—Salesforce is mid-transition, and the install experience hasn't fully caught up to the permission set model. Stick with:

✅ Install for System Administrator profile only 

✅ Leave the standard System Administrator profile untouched 

✅ Use a custom "System Administrator" Permission Set for any add-on admin permissions 

✅ Assign app Permission Sets manually after install 

✅ Use Permission Set Groups to bundle access for end users

This keeps your org clean, maintainable, and aligned with Salesforce's direction.