7.1 Document Checklist Items, Content Management & Upload Portals

7.1 Document Checklist Items, Content Management & Upload Portals

Exam Focus: Document management forms the operational backbone of regulatory licensing, social assistance intake, and public sector enforcement. On the AP-222 examination, candidates must demonstrate thorough mastery of standard DocumentChecklistItem (DCI) records, DocumentType metadata, the constituent upload experience in Experience Cloud and OmniScript, the Salesforce Files data model (ContentVersion, ContentDocument, ContentDocumentLink), and the automated workflows governing document rejections and constituent resubmissions.

---

The Public Sector Document Verification Challenge

Government agencies process millions of evidentiary files annually—building blueprints, proof of income, criminal history clearances, corporate articles of incorporation, professional licenses, and medical certifications. Unlike commercial e-commerce platforms where transactions conclude upon payment, public sector adjudications legally depend on verifying documentary evidence before granting statutory authority, public benefits, or operating licenses.

Historically, public agencies managed documents through fragmented file shares, physical paper dockets, or disconnected email inboxes. This legacy approach created severe operational vulnerabilities:

• Lost or Disconnected Evidence: Uploaded files became orphaned from parent application records, forcing caseworkers to manually search email threads or document repositories.
• Lack of Standardized Requirements: Applicants frequently submitted incomplete documentation because application guidelines varied between municipal bureaus or regional offices.
• Unstructured Rejection Loops: When an applicant submitted an illegible utility bill or an expired driver license, caseworkers had to draft manual emails. Applicants would then resubmit entire duplicate application packages rather than targeted replacement files, multiplying agency processing backlogs.

Salesforce Public Sector Solutions (PSS) resolves these bottlenecks by combining standardized metadata requirements, transactional checklist tracking, an audited Content architecture, and guided digital intake portals.

---

Standardizing Requirements: Document Types & Document Checklist Items

Public Sector Solutions decouples the definition of a required document from its transactional execution using two primary building blocks:

┌─────────────────────────────────────────────────────────────┐
│                     DocumentType (Metadata)                 │
│  • DeveloperName: Proof_of_Residency                        │
│  • MasterLabel: Proof of State Residency                    │
│  • Description: Valid utility bill, lease, or mortgage doc  │
│  • IsActive: True                                           │
└──────────────────────────────┬──────────────────────────────┘
                               │ Referenced by 1:M
                               ▼
┌─────────────────────────────────────────────────────────────┐
│            DocumentChecklistItem (Transactional Object)     │
│  • ParentRecordId: BusinessLicenseApplication / IndivApp    │
│  • DocumentTypeId: Proof_of_Residency                       │
│  • Status: New ➔ Pending ➔ Accepted | Rejected             │
│  • Instruction: Must be dated within the last 60 days       │
│  • IsRequired: True                                         │
│  • IsAccepted: False                                        │
│  • DueDate: 2026-10-15                                      │
└─────────────────────────────────────────────────────────────┘

1. Document Type (DocumentType)

DocumentType is a setup entity that defines standard documentation categories across an agency enterprise. Examples include:

• Proof of Identity (State ID / Passport)
• Proof of Household Income (Form W-2 / Pay Stub)
• Commercial General Liability Insurance Certificate
• Architectural Floor Plans & Structural Calculations
• Criminal Background Clearance Letter

Centralizing these definitions ensures uniform naming conventions, standardized guidance instructions, and consistent retention policies across disparate agency departments.

2. Document Checklist Item (DocumentChecklistItem)

The DocumentChecklistItem (DCI) is a standard transactional object representing a specific document required for a concrete parent record. DCIs can be associated with diverse Public Sector Solutions objects via the polymorphic ParentRecordId field, including:

• BusinessLicenseApplication (e.g., restaurant liquor license, commercial cannabis permit)
• IndividualApplication (e.g., social welfare assistance, childcare subsidy)
• CarePlan (e.g., child welfare dependency plan, vocational rehabilitation)
• Case (e.g., constituent grievance, regulatory violation dispute)
• PublicComplaint (e.g., environmental dumping report, consumer fraud complaint)

Key fields on the DocumentChecklistItem object include:

• ParentRecordId: Polymorphic lookup linking the checklist item directly to the parent application or case record.
• DocumentTypeId: Lookup to the central DocumentType definition.
• Status: Picklist tracking verification progress (New, Pending, Accepted, Rejected).
• Instruction: Agency guidance presented to the constituent explaining exact file criteria (e.g., "Upload a legible PDF or JPEG copy of your utility bill dated within the last 60 calendar days showing your current residential address.").
• IsRequired: Boolean flag enforcing mandatory submission before an application can be formally submitted or approved.
• IsAccepted: Boolean indicating whether caseworker review is complete and satisfactory.
• DueDate: Statutory deadline by which the constituent must supply the document.

Automated Generation via Action Plan Templates

Rather than requiring caseworkers to manually create individual DCI records for every incoming application, agencies utilize Action Plan Templates:

1. An administrator creates an Action Plan Template with the Target Object set to the desired application type (e.g., BusinessLicenseApplication).
2. The template is populated with required Document Types and instructional text.
3. When an applicant submits an intake form or an application record transitions to Under Review, a record-triggered Flow or Business Rules Engine (BRE) Expression Set evaluates applicant attributes (e.g., business structure, applicant age, premise zoning) and automatically instantiates the appropriate Action Plan, generating the exact set of required DCIs instantly.

---

Constituent File Upload Experience: Experience Cloud & OmniScript

Public Sector Solutions provides two primary digital pathways for constituents to upload required documents: guided intake within OmniStudio OmniScripts and ongoing checklist management on Experience Cloud portals.

┌─────────────────────────────────────────────────────────────────────────────┐
│                       Experience Cloud Constituent Portal                   │
├─────────────────────────────────────────┬───────────────────────────────────┤
│       Intake Pathway: OmniScript        │   Post-Submission: DCI Component  │
│                                         │                                   │
│  ┌───────────────────────────────────┐  │  ┌─────────────────────────────┐  │
│  │ Step 3: Evidentiary Documentation │  │  │ Required Documents List     │  │
│  │                                   │  │  │                             │  │
│  │ • Proof of ID: [ Browse Files ]   │  │  │ [✓] Proof of Identity       │  │
│  │   Accepted: .pdf, .jpg, .png      │  │  │     Accepted - 2026-09-01   │  │
│  │   Max Size: 25 MB                 │  │  │                             │  │
│  │                                   │  │  │ [!] Proof of Residency      │  │
│  │ • Tax Return:  [ Browse Files ]   │  │  │     REJECTED: Expired Doc   │  │
│  │   (Encrypted Upload Direct to S3) │  │  │     [ Upload Replacement ]  │  │
│  └───────────────────────────────────┘  │  └─────────────────────────────┘  │
└─────────────────────────────────────────┴───────────────────────────────────┘

1. OmniScript File Upload Element

During multi-step digital application intake, constituents upload supporting documents through the native File element in OmniStudio OmniScript:

• MIME Type and Extension Filtering: Administrators restrict uploads to agency-approved file formats (e.g., .pdf, .jpg, .jpeg, .png, .docx) while blocking risky executable extensions (.exe, .sh, .bat).
• File Size Governance: File size constraints (such as 10 MB or 25 MB per file) prevent constituents from overwhelming platform limits, while supporting multi-page architectural blueprints or comprehensive medical records.
• Multi-File Upload Capabilities: Applicants can attach multiple supporting documents to a single intake category (e.g., uploading three consecutive pay stubs for wage verification).
• Integration Procedure Execution: Upon submission, an Integration Procedure executes an automated sequence that creates the application record, instantiates the required DCIs, and maps the uploaded files directly to their respective DocumentChecklistItem records.

2. Experience Cloud Document Checklist Component

Once an application has been submitted, constituents track the real-time status of their documentation using the standard Document Checklist Item component embedded on their Experience Cloud portal record detail page:

• Visual Verification Badges: Items display intuitive status indicators: Required (gray/blue), Pending Review (yellow), Accepted (green checkmark), or Rejected (red alert icon).
• Downloadable Templates: If a document requires an official agency affidavit or medical sign-off, the DCI component provides a direct download link to the agency-approved blank PDF form.
• In-Place File Replacement: Constituents can click directly on a rejected or new checklist item to browse and upload replacement files without navigating away from their application portal page.

---

The Document Lifecycle & Review State Machine

A DocumentChecklistItem moves through four distinct standard lifecycle states, governing caseworker review queues and automated applicant communications:

   ┌─────────┐       Constituent Uploads File       ┌───────────┐
   │   New   │ ────────────────────────────────────> │  Pending  │
   └─────────┘                                      └─────┬─────┘
        ▲                                                 │ Caseworker Reviews
        │                                          ┌──────┴──────┐
        │ Resubmission Upload                      ▼             ▼
        │                                    ┌──────────┐  ┌──────────┐
        └─────────────────────────────────── │ Rejected │  │ Accepted │
                                             └──────────┘  └──────────┘

---

Content Architecture: ContentVersion, ContentDocument & ContentDocumentLink

Salesforce Public Sector Solutions manages physical files using the core platform Salesforce Files relational model. Understanding how this tri-object architecture links uploaded files to DCIs and parent application records is essential for AP-222 architectural design:

┌─────────────────────────────────────────────────────────────────────────────┐
│                             ContentVersion                                  │
│  • Id: 068... (Specific Version Instance)                                   │
│  • Title: 2025_W2_Statement.pdf                                             │
│  • VersionData: [Binary Payload Blob]                                       │
│  • IsLatest: True                                                           │
│  • ContentDocumentId: 069... (Lookup to Master)                             │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │ Master-Detail to
                                       ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                             ContentDocument                                 │
│  • Id: 069... (Master Abstract File Entity)                                 │
│  • LatestPublishedVersionId: 068...                                         │
│  • Archival & Retention Metadata                                            │
└──────────────────────┬───────────────────────────────┬──────────────────────┘
                       │ 1:M                           │ 1:M
                       ▼                               ▼
┌──────────────────────────────────────┐ ┌────────────────────────────────────┐
│         ContentDocumentLink 1        │ │        ContentDocumentLink 2       │
│  • ContentDocumentId: 069...         │ │  • ContentDocumentId: 069...        │
│  • LinkedEntityId: DCI-10042         │ │  • LinkedEntityId: BLA-88301       │
│    (DocumentChecklistItem Record)    │ │    (BusinessLicenseApplication)    │
│  • ShareType: 'V' (Viewer)           │ │  • ShareType: 'I' (Inferred)       │
│  • Visibility: 'AllUsers'            │ │  • Visibility: 'InternalUsers'     │
└──────────────────────────────────────┘ └────────────────────────────────────┘

The Tri-Object File Architecture Explained

1. ContentVersion: Represents a specific version of a document. It contains the actual binary file blob (VersionData), file size, file extension, and modification history. When an applicant uploads an updated revision of a rejected document, a new ContentVersion record is inserted under the existing document master.
2. ContentDocument: The parent document record that groups all historical versions of a file together. It represents the conceptual file entity and maintains the pointer to the latest active version (LatestPublishedVersionId).
3. ContentDocumentLink: The critical junction object that associates a ContentDocument with any standard or custom Salesforce record (LinkedEntityId).

Architectural Best Practice: Dual-Linking Files

In public sector implementations, files must be accessible both within the narrow context of document checklist review and within the broader context of overall application management:

• When a file is uploaded, automation creates a ContentDocumentLink pointing to the specific DocumentChecklistItem record (LinkedEntityId = DCI.Id). This allows caseworkers reviewing the checklist item to view the attached file directly.
• Simultaneously, automation creates a second ContentDocumentLink pointing to the primary parent application record (LinkedEntityId = BusinessLicenseApplication.Id).
• Zero Storage Redundancy: Because ContentDocumentLink creates relational pointers rather than physical file copies, the agency incurs zero duplicate file storage penalties while ensuring that reviewers examining the main application record can see all attached evidence in the standard Files related list.

Security & Visibility Configuration

ContentDocumentLink governs file security through two key attributes:

• Visibility: Set to 'AllUsers' to make the document visible to external portal users (the constituent) or 'InternalUsers' to restrict sensitive internal audit notes strictly to agency staff.
• ShareType: Set to 'V' (Viewer - read-only access, preventing external alteration), 'C' (Collaborator - allows uploading new versions), or 'I' (Inferred - permissions derived from the parent record).

---

Rejection Taxonomy, Constituent Notifications & Resubmission Loops

Incomplete or defective document submissions represent the single greatest cause of application processing delays. Public Sector Solutions enforces a structured, closed-loop resubmission architecture that eliminates manual caseworker back-and-forth.

1. Standardized Rejection Taxonomy

Caseworkers must not enter free-form text as the sole rationale for rejecting a document. Agencies establish a standardized picklist on DocumentChecklistItem (RejectionReason__c), ensuring consistent audit reporting and enabling automated branching:

• Illegible / Blurry Scan: The uploaded image resolution is insufficient to read legal text, numbers, or official seals.
• Expired Documentation: The document validity window has elapsed (e.g., driver license expired, utility bill older than statutory 60-day limit).
• Missing Mandatory Pages / Signatures: The file omits required addenda, notarization seals, or required co-applicant signatures.
• Incorrect Document Type: The applicant uploaded an invalid document class (e.g., uploading a credit card statement instead of a government tax return).
• Altered / Suspected Fraudulent: The document exhibits indicators of digital manipulation or mismatched font artifacts, triggering specialized fraud investigation routing.

2. Automated Notification Pipelines

When a caseworker sets a DCI status to Rejected:

1. A record-triggered Flow detects the state transition (Status = 'Rejected').
2. The Flow extracts the RejectionReason__c and caseworker comments entered in RejectionComments__c.
3. The system dispatches an automated, personalized notification via email and SMS to the applicant. The communication includes:
   • The specific document that failed review;
   • The exact statutory deficiency;
   • Explicit instructions on how to rectify the issue;
   • A deep link directly to the Experience Cloud portal upload screen for that specific DCI.

3. Closed-Loop Resubmission Architecture

When the constituent clicks the portal link and uploads a corrected file:

• The portal component inserts a new ContentVersion record linked to the existing ContentDocument.
• A record-triggered Flow detects the new file attachment on the rejected DCI.
• The Flow automatically transitions the DCI status from Rejected back to Pending.
• The Flow updates the parent application's status to Re-submitted Documents - Pending Review and creates a notification task in the assigned caseworker's Service Console utility bar.
• This closed-loop process ensures that the historical rejection reason, audit timestamps, and file versions remain fully intact for legal defensibility.

---

Public Sector DCIs vs. Generic File Management

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: Automated Generation of Document Requirements Based on Entity Type

A state Department of Consumer Affairs licenses both individual sole proprietorships and multi-member corporate LLCs. Sole proprietors must submit a government-issued photo ID and proof of residency. Corporate LLC applicants must submit Articles of Organization, a Certificate of Good Standing from the Secretary of State, and an IRS EIN verification letter. The agency requires an automated, declarative architecture to generate the correct document checklist upon application intake.

How should an architect design this solution using Public Sector Solutions?

• Define central DocumentType records for each required documentation category (Photo_ID, Proof_of_Residency, Articles_of_Organization, Certificate_of_Good_Standing, EIN_Letter).
• Build two distinct Action Plan Templates with target object BusinessLicenseApplication—one configured for Sole Proprietorship requirements and one for Corporate LLC requirements.
• Deploy an OmniStudio OmniScript for constituent intake that captures the applicant's legal entity type.
• In the post-submission Flow, evaluate the entity type and automatically instantiate the corresponding Action Plan Template, instantly generating the appropriate DocumentChecklistItem records linked to the application.

Scenario 2: Caseworker Document Rejection and Constituent Resubmission Loop

An applicant applying for a food service health permit uploads a commercial kitchen grease trap maintenance log that is three years out of date. The health inspector reviewing the application in the Service Console must reject the document, explain the deficiency, and allow the applicant to upload a current log without canceling the entire permit application.

What is the recommended declarative configuration to support this workflow?

• The caseworker navigates to the DocumentChecklistItem for the maintenance log, updates Status to Rejected, selects Expired Documentation from the RejectionReason__c picklist, and enters the required date parameters in RejectionComments__c.
• A record-triggered Flow detects the status change, sends an automated notification email to the applicant with the caseworker's notes and a direct URL to the Experience Cloud portal.
• On the portal, the applicant uploads a current maintenance log via the Document Checklist Item component.
• The upload creates a new ContentVersion and automatically resets the DCI status to Pending, re-queueing the item for caseworker inspection while preserving the original application docket number and payment history.

Scenario 3: Linking Files to Multiple Public Sector Records Without Data Duplication

A municipal licensing bureau requires that uploaded architectural building blueprints be accessible from both the specific DocumentChecklistItem (for plan-check verification) and the parent BusinessLicenseApplication (for general inspection access), while ensuring that confidential internal plan-check audit notes are hidden from the constituent.

How should the architect structure the Salesforce Files architecture?

• When the constituent uploads the blueprint, the system generates a single master ContentDocument and ContentVersion.
• Create a ContentDocumentLink record associating the ContentDocument to the DocumentChecklistItem (LinkedEntityId = DCI.Id) with Visibility = 'AllUsers', allowing both the constituent and the caseworker to view the blueprint.
• Create a second ContentDocumentLink associating the same ContentDocument to the BusinessLicenseApplication (LinkedEntityId = Application.Id) with Visibility = 'AllUsers', allowing field inspectors to view the plans without duplicating file storage.
• For internal plan-check audit notes, upload the document with a ContentDocumentLink set to Visibility = 'InternalUsers', ensuring external portal constituents cannot view or download internal agency deliberation records.