Sforce Maximizer

The Challenge of Portal Security in Salesforce Public Sector Implementations

buyan47

Government agencies implementing Salesforce Public Sector Solutions face a unique challenge: how do you provide secure, compliant access to sensitive benefit information for community portal users while maintaining strict data privacy standards?

When citizens submit claims through a community portal—often involving highly sensitive personal health information (PHI), financial data, and legal documentation—the security model must be both flexible and ironclad.

In this post, I’ll walk through three critical use cases that shaped our architectural decision for a government client’s community portal security model. These use cases reveal why traditional sharing mechanisms fall short and what it takes to build a truly secure, compliant portal experience.

The Context: A 50-Step Claims Submission Process

Our government client needed to support a complex claims workflow where:

The challenge? Creating a security model that handles three distinct access patterns while maintaining HIPAA compliance and federal data privacy requirements.

Let’s dive into each use case.

Use Case 1: Read-Only Access After Claim Submission

The Business Requirement

Once a portal user submits their claim, they should have read-only access to all related records.

This seems straightforward, but it’s harder than it sounds in Salesforce. The portal user needs to:

Why This Matters

In government benefit programs, claim integrity is paramount. Once a claim is submitted:

The Technical Challenge

Salesforce sharing mechanisms typically grant access to records, but controlling whether that access is read-only or editable is a separate concern. Here’s what doesn’t work:

❌ Criteria-Based Sharing Rules: Sharing rules can grant access to records, but they can’t distinguish between read and edit access. You’d need a complex combination of:

This multi-layer approach creates gaps, confusion, and maintenance nightmares.

❌ Sharing Sets: Sharing sets grant access based on set membership, but you’d need to manage users across 12+ different sharing sets (one for “edit” and one for “read-only” for each of the 6 objects). When a claim is submitted, you’d need to move users from edit sets to read-only sets asynchronously, creating timing issues.

The Solution: Apex Managed Sharing

✅ With Apex sharing, we create share records with explicit access levels:

// When claim is submitted with Status = "Submitted"
ClaimShare claimShare = new ClaimShare();
claimShare.ParentId = claim.Id;
claimShare.UserOrGroupId = portalUser.Id;
claimShare.AccessLevel = 'Read';  // Explicitly READ-ONLY
claimShare.RowCause = Schema.ClaimShare.RowCause.Claimant_Owner__c;
insert claimShare;

This approach:

💡 Key Takeaway: For government portals handling sensitive data, read-only enforcement must happen at the sharing layer, not through a patchwork of validation rules and permission restrictions.

Use Case 2: Delegated Submission with Multi-Stage Review

The Business Requirement

A third-party company user can submit a claim on behalf of a claimant. The claimant then logs in to review and edit the claim before final submission.

This introduces a complex multi-party, multi-stage access pattern:

  1. Initial Submission: Third-party company user submits claim (needs EDIT access)
  2. Claimant Review: Claimant logs in to review the claim (needs EDIT access while Claim Status = “Review”)
  3. Third-party company Monitoring: Third-party company user continues to have access to monitor progress (needs EDIT access during review)
  4. Final Submission: When claimant completes review, both parties transition to READ-ONLY access

Why This Matters

Legal representation is common in government benefit claims:

The security model must support this collaborative workflow while ensuring:

The Technical Challenge

This is where most declarative sharing approaches completely break down.

❌ Criteria-Based Sharing Rules: Can’t target two different users with different access levels to the same record. You’d need separate rules for law firm users and claimants, but rules can’t distinguish between them dynamically.

❌ Sharing Sets: Would require 18+ sharing sets:

Managing users across these sets during status transitions creates a coordination nightmare with high failure risk.

The Solution: Apex Managed Sharing with Status Triggers or Flow with Sub/flows

✅ Apex sharing handles multi-party access elegantly:

Step 1: Law Firm Submits Claim

// Create sharing for law firm user (Edit access)
ClaimShare lawFirmShare = new ClaimShare();
lawFirmShare.ParentId = claim.Id;
lawFirmShare.UserOrGroupId = lawFirmUser.Id;
lawFirmShare.AccessLevel = 'Edit';
lawFirmShare.RowCause = Schema.ClaimShare.RowCause.Law_Firm_Submitter__c;

// Create sharing for claimant (Edit access during review)
ClaimShare claimantShare = new ClaimShare();
claimantShare.ParentId = claim.Id;
claimantShare.UserOrGroupId = claimantUser.Id;
claimantShare.AccessLevel = 'Edit';
claimantShare.RowCause = Schema.ClaimShare.RowCause.Claimant_Review_Edit__c;

insert new List<ClaimShare>{lawFirmShare, claimantShare};

Step 2: Claimant Completes Review – Status Changes to “Submitted”

// Trigger on Claim Status Change
public static void transitionToReadOnly(Claim__c claim) {
    // Delete existing edit-level shares
    List<ClaimShare> existingShares = [
        SELECT Id FROM ClaimShare 
        WHERE ParentId = :claim.Id 
        AND RowCause IN ('Law_Firm_Submitter__c', 'Claimant_Review_Edit__c')
    ];
    delete existingShares;

    // Create new READ-ONLY shares for both parties
    List<ClaimShare> readOnlyShares = new List<ClaimShare>();
    for(Claim_Participant__c participant : claim.Claim_Participants__r) {
        ClaimShare readShare = new ClaimShare();
        readShare.ParentId = claim.Id;
        readShare.UserOrGroupId = participant.Portal_User__c;
        readShare.AccessLevel = 'Read';
        readShare.RowCause = Schema.ClaimShare.RowCause.Claim_Submitted__c;
        readOnlyShares.add(readShare);
    }
    insert readOnlyShares;
}

This approach:

⚠️ Critical Insight: Multi-party access with dynamic permissions is nearly impossible to implement correctly using declarative sharing alone. This use case alone eliminates sharing rules and sharing sets as viable options.

Use Case 3: Internal Staff Read-Only Access

The Business Requirement

Internal Salesforce CRM users (case workers, reviewers, auditors) need to view claims and benefit information in read-only format.

This seems simple until you realize:

Why This Matters

Government agencies must enforce separation of duties:

The challenge: How do you restrict internal users when Salesforce’s default model is to grant them broad access?

The Technical Challenge

Here’s the uncomfortable truth: No sharing mechanism can restrict internal users with object-level permissions.

❌ Sharing Rules: Only grant access; they can’t take it away. Sharing rules don’t apply to users with “View All” or “Modify All” permissions.

❌ Apex Sharing: Same limitation. Apex sharing grants access to records, but it doesn’t restrict users who already have object-level access through profiles or permission sets.

❌ Sharing Sets: Only apply to community users, not internal CRM users.

The Solution: Permission Sets + Page Layouts (Separate Architecture)

Internal user restrictions require a completely different architectural approach:

✅ Custom Permission Sets for Read-Only Access:

Permission Set: "Benefit_Objects_Read_Only"

Object Permissions:
├── Claim
│   ├── Read: ✓
│   ├── Create: ✗
│   ├── Edit: ✗
│   └── Delete: ✗
├── Benefit Assignment
│   ├── Read: ✓
│   ├── Create: ✗
│   ├── Edit: ✗
│   └── Delete: ✗
└── [Repeat for all 6 objects]

Field-Level Security:
└── All fields: Read-Only ✓

✅ Read-Only Page Layouts:

✅ Record Types (Optional):

This approach:

🚨 Important Note: Use Case 3 is NOT a differentiator between sharing mechanisms. All approaches (sharing rules, apex sharing, sharing sets) require the same separate permission set solution for internal users. Don’t let vendors tell you otherwise.

The Architecture Decision: Why Apex Managed Sharing Won

After analyzing these three use cases, the decision became clear:

Use CaseSharing RulesApex SharingSharing Sets
Use Case 1:
Read-Only After Submit		❌ High Risk
Requires complex workarounds		✅ Low Risk
Explicit access level control		❌ High Risk
12+ sets, async delays
Use Case 2:
Delegated Multi-Party		❌ High Risk
Cannot support		✅ Low Risk
Native multi-party support		⚠️ Medium Risk
18+ sets, complex flows
Use Case 3:
Internal Read-Only		N/A
Requires permission sets		N/A
Requires permission sets		N/A
Requires permission sets

Use Case 2 was the deciding factor. Delegated submission with multi-party, status-based access is nearly impossible to implement correctly without programmatic sharing control.

What We Gained with Apex Sharing

What We Accepted as Trade-offs

For government implementations with complex security requirements, these trade-offs are acceptable and manageable.

Key Lessons for Salesforce Architects

1. Use Cases Drive Architecture, Not Features

Don’t choose a sharing mechanism based on “ease of use” or “declarative vs. code.” Choose based on whether it can actually solve your use cases. Sharing rules are “easier” until you realize they can’t enforce read-only access.

2. Multi-Party Access Requires Programmatic Control

If your portal involves representatives, attorneys, guardians, or any third-party submissions, declarative sharing won’t cut it. You need the flexibility to create multiple sharing records with different access levels and reason codes.

3. Status-Based Security Is Not Optional in Government

Government workflows have strict stage gates. When a claim moves from “Draft” to “Review” to “Submitted,” access must change automatically and reliably. Asynchronous sharing set membership changes introduce unacceptable delays and failure points.

4. Internal User Restrictions Are a Separate Concern

Never conflate portal user sharing with internal user permissions. They’re architecturally distinct problems requiring different solutions. Any vendor claiming their sharing mechanism “handles both” is overselling.

5. Compliance Demands Explicit Audit Trails

For HIPAA, FedRAMP, and other government compliance frameworks, you need to answer: “Why does User X have access to Record Y?” Sharing reason codes provide this. Criteria-based sharing rules don’t.

Conclusion: Security Architecture Is About Managing Complexity

The three use cases we explored reveal a fundamental truth: government portal security is inherently complex.

You can either:

For our government client, Apex Managed Sharing was the only architecturally sound choice. It’s the only mechanism that could handle:

If you’re building a community portal for public sector, healthcare, or any industry with complex multi-party workflows and strict compliance requirements, don’t default to “declarative is always better.”

Sometimes, the right architecture is the one that works. If you want to do this using Flows, here is a great article that you can use as a reference to implement apex sharing with Flows.

What’s Your Portal Security Challenge?

Are you facing similar challenges with multi-party access, status-based permissions, or compliance requirements in your Salesforce implementation?

Drop a comment below with your toughest portal security use case. I’d love to hear how you’re solving these challenges (or where you’re stuck).

And if you found this post helpful, share it with your Salesforce architect community. Complex security problems deserve thoughtful solutions, not one-size-fits-all recommendations.

Exit mobile version