#Systems Administrator7 discussing

 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.

Hi @Heath Parks

It tracks.  

It sounds like you had an expectation than once you gave one contact a Partial Soft Credit of $500, the other Soft Credit would automatically adjust? If so, then no, that's not how it works. There's nothing that forces the total soft credit to equal the Opportunity amount (it's not like GAU Allocations in that respect). You will need to use the Manage Soft Credit button - which is better than creating Partial Soft Credits directly - to manage the value for each contact. You can also do validation there that would force you to make sure the total doesn't exceed the Opportunity amount if you want (useful when allocating a company Matching Gift).  

It's common for the total to not line up. Soft Credits are more of a stewardship function than a financial requirement like Allocations, Hard Credit, or Payments are. So with that in mind, it's perfectly fine to let's say give everyone in the Household soft credit for a gift at the full amount. Or say John was the Board Member who solicited the $10K gift and Mary in a different Household works at the organization and championed it. It would be silly and probably challenging to say John was worth $9K and Mary was worth $1K.  

Hope that helps!