Feed

Hi @Maida Rider

Your second option scales better. Suggested setup: 

• Custom object “Compliance Requirement” as a child of Account (lookup or master-detail).
• Fields: Requirement Type (picklist: governance, policy, insurance, audit), Status, Issue Date, Expiration/Review Date, Reviewer, Notes.
• Files: attach documents to each Requirement record, not the Account. You get one history per requirement.
• Reminders: a scheduled flow on Expiration Date to create a Task or send an email to the owner. You can even define a standard review period based on the Requirement type field  (this will help standardize the process) 
• Account roll-up: a few fields on Account (for example “Compliance Status” or “# Expired”) using roll-up summary (master-detail) or a flow. Use these in reports and list views.
• Gate the funding: a validation rule or flow on the funding request/award that warns if the recipient has an expired requirement.

Use a small number of custom fields on Account only for the summary. Everything else stays on the child object 

Hi @Karen Hartt

Since each portal account uses a different NPO email, Salesforce won't flag them as duplicates automatically, that's a process problem, not a matching-rule problem, so no dedupe setting fixes it. I have seen this with one of the association I was working with.

Options: 

• Ask at the application stage. Add a question to the grant application form: "Are you already a registered user with us?" If yes, capture their existing email/username and route the new application to that existing Contact/portal account instead of creating a new one.
• Match on identity, not just NPO relationship. Before granting portal access, check for an existing Contact by name + personal email or phone, not just the NPO-specific email. If found, add the new NPO affiliation to that existing Contact rather than creating a second one.
• One portal login, multiple affiliations. If your portal license allows it, let one Contact log in once and see/submit applications for every NPO they're affiliated with, instead of a separate login per NPO. This removes the reason to duplicate in the first place.
• If separate logins are unavoidable (portal architecture requires one Contact per login), don't merge instead, link the duplicate Contacts to each other (a custom "Related Person" or NPSP Relationship record) so staff can see they're the same human, and report on them as one person via that link rather than via Contact merge.

Hi Ashwin, if you’re not using the Lead object, you can restrict users from accessing Leads through the appropriate object permissions in their profiles or permission sets. 

For Data.com specifically, the available controls depend on which Data.com features are enabled and how they are configured in your org. I’d recommend reviewing the Data.com

settings and the Lead object permissions to make sure users don’t have access to create or update Leads. 

If you can share which Data.com functionality you’re planning to use (Clean, Prospector, or another feature), I can suggest the specific configuration. 

Hi Fang, standard Salesforce list views are generally tied to the user who creates them, so you can’t simply create a separate private view for every user through Apex or deployment and have it automatically appear as their personal view. 

If the view needs to be available to everyone, consider creating a public/shared list view instead. If each user must have a private view based on their own Campaign membership, you would typically need to have the users create the view themselves or consider a custom solution to provide the required filtering. 

If you can share the exact filtering criteria you need for “My Contacts,” there may be a way to achieve the requirement without creating a separate private view for each user.