Salesforce AP-222 Salesforce Accredited Agentforce 360 for Public Sector Professional Exam Practice Test

Public Sector already includes a standard object specifically designed for this requirement: Business Regulatory Authorization Type Dependency . Salesforce states that many businesses require multiple licenses or permits and that dependency records establish the relationships and issuance sequence among those authorizations. A parent authorization must be obtained before its dependent child authorization where such a dependency is configured.

Salesforce additionally provides a standard Permits component for the Licenses and Permits Experience Cloud site. The component displays the permits required for a selected business type, including configured permit dependencies. Therefore, the agency does not need to develop a custom Permit Dependency object, custom FlexCard, or custom OmniScript merely to reproduce native functionality.

Option B consequently follows the standard Public Sector data model and minimizes custom technical debt while allowing administrators to maintain permit relationships declaratively.

The uploaded screenshot cuts off the final portion of option D. Its completed wording above was restored from a matching copy of the same item; the answer validation itself is based on Salesforce's official documentation .

Study Guide Reference: Public Sector Solution Product Configuration – Regulatory Authorization data model; Business Regulatory Authorization Type Dependency; parent and dependent permits; Permits Experience Cloud component.

================

Two Decision Matrices provide the cleanest and appropriate Business Rules Engine design because the scenario contains two independent lookup domains . The first matrix represents the federal income-limit values applicable to household size or related criteria. The second maps the calculated percentage of Area Median Income to the appropriate prioritization pool.

Salesforce defines Decision Matrices as tables that match supplied input values against rows and return corresponding output values. Expression Sets can invoke these matrices and combine the results with calculations, variables, and constants.

The Expression Set would therefore obtain or calculate the applicable household AMI percentage by referencing the federal-income-limit criteria and then pass that calculated percentage into the prioritization matrix. Separating these rule sets is preferable to placing unrelated policy dimensions into one monolithic matrix. It improves maintainability because federal limits can change independently of an agency's prioritization thresholds.

Option D unnecessarily creates a third matrix for household data. Household income and household size are transactional inputs , not reference-policy values that inherently require their own Decision Matrix. Option A omits the Federal Income Limit lookup, while B improperly combines two independently maintained rule sets.

This modular design also supports policy changes without rebuilding the Expression Set itself.

Study Guide Reference: Public Sector Solution Product Configuration – Business Rules Engine; Expression Sets; Decision Matrices; policy lookup tables; AMI and prioritization calculations.

================

Salesforce directly documents Action Plans on Accounts as the mechanism for standardizing grantmaking due-diligence processes. An Action Plan Template acts as a reusable blueprint that defines the activities reviewers must complete consistently for each grantseeking organization.

Salesforce's Grants Management documentation explicitly states that organizations can use Action Plans on Accounts to define due diligence steps, related tasks, and documents to collect . Tasks can represent actions such as requesting tax documentation, verifying organizational eligibility, or completing financial reviews. Document Checklist Items identify supporting documents that must be obtained and reviewed.

This architecture directly addresses the problem in the scenario: reviewers currently follow different processes. A published Action Plan Template converts an informal procedure into a repeatable Salesforce-controlled workflow, improving consistency, traceability, accountability, and reviewer productivity.

A Screen Flow or OmniScript could technically guide a user through steps, but both would duplicate functionality already supplied by Action Plans. Merely supplying procedural documentation also provides no technical enforcement, assignment, due-date management, or document checklist tracking.

Therefore, Action Plans represent the product-native and lowest-customization implementation.

Study Guide Reference: Public Sector Solution Product Configuration – Grants Management; Due Diligence; Action Plans; Action Plan Templates; Tasks; Document Checklist Items.

================

The native Public Sector design combines an OmniScript application form with Business Rules Engine . Salesforce explicitly documents this architecture for automatically calculating processing fees associated with business license applications. Business Rules Engine uses Decision Matrices and Expression Sets to determine fee amounts from multiple input criteria, while the OmniScript captures those constituent inputs.

For example, a Decision Matrix can contain base-fee values indexed by authorization type, industry category, location, revenue band, or another applicable parameter. An Expression Set invokes one or more matrices, performs any additional arithmetic, and returns a calculated currency amount. Salesforce documents that Expression Sets and Decision Matrices accept JSON input from and return JSON output to OmniScripts.

The integration is direct: Salesforce explains that an Expression Set Action can be added to the OmniScript so that, when the applicant supplies the required information, the Business Rules Engine processes those values and returns the appropriate license fee.

Triggered Flow could calculate values, but it would duplicate a purpose-built policy calculation engine. Integration Procedures are appropriate for data orchestration and external integrations, not for replacing BRE as the authoritative fee-policy engine. A generic Flow application also bypasses the Public Sector OmniScript application architecture.

Study Guide Reference: Public Sector Solution Product Configuration – OmniScripts; Business Rules Engine; Expression Sets; Decision Matrices; automated application fee calculation.

================

Decision Matrices are the Business Rules Engine component used to map combinations of application inputs to defined outputs such as application fees. Salesforce describes a Decision Matrix as a lookup table containing input values and corresponding output values. When an Expression Set invokes the matrix, Business Rules Engine finds the row matching the supplied inputs and returns the output associated with that row.

Salesforce specifically documents Decision Matrices for Public Sector application-fee calculation . For example, a business licensing matrix can contain authorization category and authorization type as inputs and a base application fee as the output. Different application characteristics can therefore automatically resolve to different required fees without custom code.

This architecture is preferable to hard-coding fee mappings because administrators can update the Decision Matrix as legislation, agency policy, permit categories, or fee schedules change. Expression Sets can subsequently call the matrix and perform additional calculations when needed.

"Data matrices" isn't the Business Rules Engine component name used for this function. Workflow Field Updates and Process Builder are legacy Salesforce automation capabilities; neither provides the structured multidimensional policy lookup behavior required for configurable fee schedules.

Salesforce's current BRE portfolio also includes Decision Tables , which support advanced rule logic, but for the specific matrix-based fee-mapping architecture represented by this exam item, Decision Matrix is the required answer.

Study Guide Reference: Public Sector Solution Product Configuration – Business Rules Engine; Decision Matrices; Expression Sets; automated application-fee calculations.

Decision Explainer is specifically designed to expose why Business Rules Engine produced a particular calculation or eligibility determination. Salesforce describes Decision Explainer as a collection of setup objects that provides transparency into business-rule calculations and supports agencies in explaining decisions to constituents.

When grant eligibility is calculated through Expression Sets and related Business Rules Engine components, Decision Explainer can retain the relevant decision context. Reviewers can inspect the Expression Set used, input values, calculations, and the resulting outcome. This is exactly what is needed when an applicant challenges a declined eligibility determination: the authority needs the reasoning associated with the actual application record , rather than attempting to reproduce the calculation separately.

Debug logs are primarily technical diagnostics. They may show execution details but aren't the business-facing explainability mechanism designed for caseworkers or reviewers and don't provide the same structured decision history. Testing representative datasets validates rules before deployment but doesn't explain why the particular constituent's submitted application was rejected. "Selection Explainer" is not the appropriate Salesforce Public Sector feature.

Decision Explainer therefore supports both operational transparency and governance by making automated eligibility and calculation outcomes understandable and reviewable.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Decision Explainer; Business Rules Engine; eligibility determinations; Explainability Action Logs; auditability.

================

A DataRaptor , now called an OmniStudio Data Mapper , is specifically designed to read, transform, and write data to Salesforce objects. For the use case in this question, the external portal already exists; the primary requirement is therefore to take submitted application data and map it into the corresponding Public Sector Salesforce objects.

Salesforce states that a Data Mapper Load accepts JSON, XML, or supported custom input formats and writes the resulting data to Salesforce objects using configured object and field mappings. More importantly for this scenario, Salesforce exposes a Data Mapper REST API . An external application can POST a JSON payload to a Data Mapper Load, and the Data Mapper updates or creates Salesforce records according to its mappings.

That makes DataRaptor/Data Mapper an appropriate declarative bridge between the existing external portal and Public Sector's Grant application records.

An Integration Procedure is preferred when orchestration involves multiple data sources, several operations, conditional processing, REST integrations, error handling, or multiple Data Mappers. Salesforce recommends a single Data Mapper where the requirement is fundamentally a Salesforce-object write operation that can be handled through direct mappings.

FlexCards provide user-interface presentation. OmniOut runs OmniStudio UI components on third-party sites, but the question states that the agency will retain its existing portal and specifically needs to integrate submitted data .

Study Guide Reference: Public Sector Solution Product Configuration – OmniStudio DataRaptors/Data Mappers; Data Mapper Load; REST API; external application integration.

================

User Stories and a Functional Requirements Specification (FRS) are core implementation artifacts because both translate stakeholder needs into requirements that can guide Salesforce solution design, configuration, development, and testing.

Salesforce defines a user story as a concise description of functionality that a business system should provide from a user's perspective. The commonly used structure is: As a [user], I want [capability] , so that [business value]. User stories become development work items and allow requirements to be prioritized, implemented, and validated incrementally.

Salesforce describes the Functional Requirements Specification as documentation of business requirements from the end-user or business perspective, specifying the expected functional outcomes. It becomes a more comprehensive reference for how required capabilities should operate and supports scope control, solution design, QA, and user acceptance testing.

A Marketing Plan addresses promotion, audience positioning, and communication strategy rather than technical implementation requirements. A Budget Plan is an important project-governance artifact but isn't one of the two requirements-definition documents being tested.

In a Public Sector project, these artifacts are particularly important because requirements commonly involve statutory rules, eligibility criteria, licensing processes, data governance, integrations, and auditable approval workflows that must be defined precisely before implementation.

Study Guide Reference: Agentforce Public Sector Implementation Strategies and Best Practices – discovery; requirements gathering; user stories; functional requirements specifications; implementation documentation.

================

Decision Explainer provides transparency into calculations and decisions produced by Business Rules Engine. For the Public Sector curriculum version represented by this question, Salesforce explicitly identifies Decision Explainer use cases that include individual and business application fees, unemployment benefits, and education loan eligibility checks . Therefore, among the available options, A and B correspond to supported Public Sector Decision Explainer scenarios. Salesforce's Public Sector Developer Guide specifically lists these examples when describing how Decision Explainer exposes the reasoning behind Expression Set calculations.

The architecture is based on Business Rules Engine executing an Expression Set, potentially calling Decision Matrices containing policy criteria, and Decision Explainer recording the inputs, calculations, intermediate values, and resulting decision. Reviewers can then inspect why a claimant qualified, failed eligibility requirements, or received a particular calculated amount.

Person Loans and Car Loan are not identified Public Sector Decision Explainer examples in this curriculum. They represent generic lending concepts rather than the documented Public Sector scenarios.

A versioning point is relevant: newer Salesforce Help currently uses housing loan eligibility checks in its example list, while the Salesforce developer documentation associated with the exam-era content uses education loan eligibility checks.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Decision Explainer; Business Rules Engine; Expression Sets; benefits eligibility and application-fee calculations.

================

A published Action Plan Template is intentionally immutable . Salesforce explicitly states that after an Action Plan Template is published, it cannot be edited or deleted; depending on the implementation, it can be deactivated or made obsolete, and a replacement template must be created when process changes are required.

This behavior preserves process integrity. Existing Action Plans can be traced back to the exact template definition from which they were created, which is important for standardized licensing, inspection, compliance, and due-diligence workflows. Allowing administrators to alter a published template could change the apparent definition of a process after users had already executed tasks generated from that template.

Salesforce's document-automation guidance states the remediation directly: because a published template can't be changed, create a new template and remove or retire the old one. In practice, an administrator can clone the existing template, modify the draft copy with the updated assessment tasks, document requirements, signatures, or inspection steps, then publish the replacement.

The absence of Edit is therefore not a page-layout problem or missing System Administrator permission. Salesforce Support isn't required to modify the existing record because the immutability is an intentional product lifecycle rule.

Study Guide Reference: Public Sector Solution Product Configuration – Action Plan Templates; Draft and Published lifecycle; template versioning; inspection-process governance.

================

Salesforce explicitly states that the Person Account model uses the standard Account object to hold the details about a person . In Public Sector, Person Accounts represent individual constituents who apply for licenses, permits, programs, benefits, grants, and government services.

A Person Account combines selected Account and Contact behavior into a single person-oriented record. Salesforce's Public Sector data-model documentation explains that this record can contain personhood information such as birth date and tax identification information and can relate directly to Cases, Individual Applications, and Public Complaints.

Option B is incorrect because Person Accounts combine Account and Contact characteristics, not Opportunity and Contract fields. Option C is incorrect because the Person Account record type is fundamental to the implementation; Salesforce explicitly identifies Person Account as an Account record type.

Option D is particularly important from an implementation-governance perspective. Salesforce warns that after Person Accounts are enabled in an organization, they cannot be disabled . This is why enabling them requires deliberate architectural planning and testing before activation.

For Public Sector, business constituents should normally be represented by Business Accounts, while individual constituents can use Person Accounts. This separation supports Public Sector data relationships while maintaining a consistent CRM data model.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Person Accounts; Account data model; constituents; Person Account record type; implementation considerations.

================

The Public Sector Case Analytics App is specifically designed to analyze public-sector service cases and provides prebuilt dashboards and metrics for measuring organizational effectiveness, caseworker performance, service trends, and operational outcomes. This makes it preferable to creating a custom Salesforce reporting implementation.

More importantly, Salesforce documents exactly how the template handles case duration when an organization does not already maintain its own duration field. During Public Sector Case Analytics configuration, administrators can identify an existing duration field if one exists. If no case-duration field is tracked, CRM Analytics uses its own formula , calculating duration from the case opened and closed dates. For cases that remain open, the calculation uses the current date.

Consequently, Bobahaven does not need to introduce a custom duration field merely to obtain trend reporting. Options A and B add unnecessary data-model customization and would primarily benefit future records unless additional historical transformation were implemented. Option C similarly creates a custom reporting solution despite the presence of a purpose-built analytics template.

Study Guide Reference: Agentforce Public Sector – Product-Specific Systems Knowledge; CRM Analytics for Public Sector; Public Sector Case Analytics; case-duration metrics and prebuilt analytics dashboards.

Salesforce requires users who configure or use Action Plans to have the appropriate Action Plans permission set . Salesforce's Public Sector Action Plans documentation explicitly identifies the required user permission as the Action Plans permission set and directs administrators to assign it through the user's Permission Set Assignments.

The scenario isolates the problem to one newly onboarded inspector while every existing inspector can access the same feature. That strongly indicates a user-specific permission assignment rather than an organization-wide configuration problem. If Person Accounts weren't enabled and were genuinely required, the impact would affect the implementation generally rather than only one inspector.

Likewise, "Enable Notes" isn't the feature permission controlling Action Plans. Action Plans have dedicated access requirements covering objects such as Action Plan, Action Plan Template, Document Checklist Item, and Recurrence Schedule, together with the Action Plans feature permission where appropriate.

A completely disabled Salesforce user would be unable to log in to Salesforce at all, not merely unable to access Action Plans. The wording indicates the inspector is successfully using Salesforce but lacks access to this particular capability.

Therefore, checking and assigning the Action Plans permission set is the precise troubleshooting action.

Study Guide Reference: Public Sector Solution Product Configuration – Action Plans; user access; Action Plans Permission Set; inspection-user configuration.

================

Volunteer Management for Community is the permission-set license intended for external community users who participate in the Volunteer Management experience. The constituent in this scenario isn't an internal emergency-management administrator; the person is an external volunteer who must access a digital experience and sign up for volunteer projects.

Public Sector's user-access architecture separates feature entitlement from the base Experience Cloud user license. Permission-set licenses extend the capabilities of the underlying Salesforce user license and must correspond to the Public Sector product functionality the user needs. Salesforce's Public Sector permissions documentation confirms this general architecture: users require the appropriate Public Sector permission sets and associated permission-set licenses for the features they consume.

For this specific legacy Volunteer Management implementation, the relevant external entitlement is Volunteer Management for Community . This enables the community-side functionality necessary for volunteers to interact with volunteer projects rather than granting internal emergency-response administration.

Option A relates to broader Community Response capabilities rather than the specific volunteer-user entitlement. Option B is generic Public Sector community access and doesn't, by itself, grant Volunteer Management functionality. Option D is aligned with internal Emergency Response functionality rather than the community volunteer persona.

Study Guide Reference: Public Sector Solution Product Configuration – Volunteer Management; Community Response; Experience Cloud user access; Permission Set Licenses.

================

Public Complaint and Case are the native Public Sector objects designed for this separation of external reporting from internal investigation. A Public Complaint records the concern submitted by a constituent, including health, safety, behavior, or well-being issues. Salesforce supports Public Complaint intake and subsequently allows staff to create a separate Case associated with the complaint when investigation or ongoing case management is required.

This architecture satisfies an important data-model requirement: the initial complaint and the internal investigative Case remain separate records but are related. Salesforce also provides the ComplaintCase junction object internally to associate complaints and Cases; this does not mean that "Complaint Case" is the principal constituent-facing object, making option D incorrect.

Using two Case record types would collapse two different Public Sector concepts into the generic Case object and discard purpose-built complaint functionality. Creating a custom complaint object would likewise duplicate capabilities already supplied by the Public Sector data model and increase maintenance.

The Public Complaint model also supports scenarios where a reporting party doesn't need to be treated as the subject of the investigative Case, which is particularly appropriate for anonymously submitted public concerns.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Public Complaints; ComplaintCase; Case Management; constituent complaint intake and investigations.

================

Public Sector Inspection Management provides the native framework for investigating regulatory complaints through Visits, inspections, and Action Plans . Salesforce explains that agencies perform inspections both for license and permit applications and when members of the public report compliance concerns. Visit records identify the location, account, inspector, purpose, and regulatory context of an inspection.

The Visit can be created from a license or permit application and linked through its context to the applicable application, thereby preserving the connection between the investigation and the underlying construction authorization. Salesforce's current documentation explicitly supports creating Visits from application records and associating them with inspection types.

Action Plans provide the repeatable task framework used by inspectors. They contain assessment tasks, signatures, checklists, and other required inspection work so that investigators follow a standardized process. Salesforce also documents Action Plan usage for Public Complaint investigations.

Business Rules Engine is unnecessary merely to determine whether a complaint is valid, and directly linking generic Case records is not the core LPI complaint-and-inspection architecture.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Inspection Management; Public Complaints; Visits; Permit Applications; Action Plans; regulatory compliance investigations.

================

The requirement is straightforward operational reporting rather than advanced analytical modeling, so standard Salesforce Reports and Dashboards provide the lowest-cost and lowest-complexity solution. A custom dashboard can consolidate multiple approval metrics—pending application count, aging, application duration, and longest-pending items—into a single visual view.

The second requirement is that approvers see the information when they log in . Salesforce supports adding Dashboard and Report Chart components directly to a Lightning Home page through Lightning App Builder. A customized Home page can then be activated for the appropriate user context, including assignment by profile.

That makes A superior to B. A dashboard provides the requested summary , whereas a report primarily presents rows of data. More importantly, Lightning Home page activation supports profile-based assignment; a role isn't the appropriate activation mechanism expressed in option B.

CRM Analytics would be technically capable of presenting approval analytics, but it introduces additional licensing, datasets, configuration, and operational overhead without providing a material advantage for the relatively simple requirement. Salesforce already supplies native approval user-interface capabilities and Home page support for approval work.

Therefore, a standard custom Approvals dashboard placed on an Approver-profile Home page satisfies the requirement while minimizing customization and cost.

Study Guide Reference: Agentforce Public Sector Implementation Strategies and Best Practices – Reports and Dashboards; Lightning Home Pages; approval monitoring; user-profile page assignment.

================

Intelligent Document Automation (IDA) directly addresses the conversion of paper-driven government processes into structured digital workflows. Salesforce describes IDA as a mechanism for simplifying and centralizing document management while reducing manual data entry. In Public Sector, it can extract and store data from paper or handwritten forms into digital Salesforce records such as Business License Applications and Individual Applications.

IDA supports PDF and image-based documents, creates Received Document records, allows relevant pages to be processed, uses OCR-based extraction through Intelligent Form Reader, and enables reviewers to compare extracted data against the original scanned document. The resulting information can then participate in downstream Salesforce workflows.

This matches both aspects of the requirement: digitizing files and automating the processing associated with those files. Business Rules Engine performs calculations and repeatable policy decisions but does not digitize paper. Generic workflows automate record-based processes but do not provide the document ingestion, OCR, document classification, or extracted-data mapping capabilities required. "Smart Forms" is not the appropriate Public Sector document-processing solution for the described legacy-paper migration.

IDA therefore supplies the specialized document layer needed to modernize a twenty-year-old paper-intensive environment.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge; Intelligent Document Automation; Intelligent Form Reader; Received Documents; OCR; digital application processing.

================

Volunteer Management provides capabilities for coordinating volunteer demand, registrations, assignments, projects, shifts, and volunteer activity. Salesforce's official Work.com documentation describes Volunteer Management as supporting volunteer projects at scale and explicitly states that volunteers can sign up for volunteer projects through a community experience and update the time spent on volunteer activities . This directly validates option C.

The package also maintains volunteer capacity and registration information associated with volunteer work. Volunteer-management records track shift requirements and registered resources so that changes in a shift—including cancellation—can be reflected in the volunteer counts. This supports option A's requirement to keep registered-volunteer and volunteer-demand figures synchronized.

Salesforce's volunteer data architecture similarly includes volunteer shifts, volunteer hours, volunteer counts, and "Volunteers Still Needed" information, demonstrating that capacity and participation tracking are integral functions of volunteer management.

Automatic reimbursement claiming is not a standard Volunteer Management capability described for this package. Likewise, a volunteer chatbot is not one of the core Volunteer Management features represented by the question.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge; Emergency Program Management; Volunteer Management; volunteer projects, shifts, registrations, capacity, and volunteer-hour reporting.

================

Intelligent Form Reader is the appropriate capability because it is specifically designed to extract structured information from uploaded documents through optical character recognition and then use that extracted information to create, update, or verify Salesforce record data. Salesforce documentation explicitly describes a validation scenario in which a person's birth date stored in Salesforce is compared against the birth date extracted from a scanned passport. This directly matches the requirement in the question.

For identity documents such as driver's licenses and passports, Intelligent Form Reader can use document types, extraction templates, field mappings, and Amazon Textract capabilities to identify values such as date of birth. The extracted field can then be mapped to the corresponding Salesforce field and used as part of an automated verification process.

Content, Attachments, and Files provide mechanisms for storing or associating documents, but none independently performs OCR-based extraction and validation of document data. They can participate in document storage, but they do not satisfy the stated automation requirement.

Study Guide Reference: Agentforce Public Sector – Product-Specific Systems Knowledge; Intelligent Form Reader; document extraction, OCR, document types, field mappings, and identity-document verification.

================

The lifecycle begins with Plan , where the grantmaker defines the funding program, objectives, eligibility, funding availability, and program structure. The organization then Engages prospective grantseekers by publishing and communicating the funding opportunity. Eligible grantseekers subsequently Apply , after which the grantmaker conducts the formal Review process and determines which applications receive an Award . The award then enters the Manage stage, covering requirements, disbursements, progress reporting, compliance, and performance monitoring, followed by formal Close Out .

This sequence aligns with Salesforce's Grants Management architecture. Salesforce Trailhead describes the lifecycle operationally: the grantmaker creates and publishes Funding Programs, a grantseeker applies by creating a Funding Request, verification and reviews occur, requirements are processed, and successful applications proceed to disbursement and continuing management.

Salesforce's Grantmaking material likewise separates application decisions from the subsequent Funding Award, then uses the award as the central record for post-award disbursements, requirements, expenditure tracking, progress reporting, and eventual completion.

Options C and D put lifecycle stages in an illogical order. Option A is structurally invalid because it places Apply before planning and repeats Apply.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Grants Management lifecycle; Funding Programs; applications; reviews; awards; post-award management; closeout.

================

The lowest-customization Public Sector architecture is to reuse the prebuilt Emergency Service Request flow and deploy the constituent experience through the preconfigured Emergency Response Management digital-experience template .

Emergency Response Management is designed to accelerate deployment of emergency programs and constituent-service workflows. Its digital experience provides the public-facing channel through which citizens and businesses can obtain emergency information and submit requests for assistance or services. Using the purpose-built template prevents the agency from recreating emergency-specific navigation, pages, and constituent processes from a generic Experience Cloud template.

The Emergency Service Request flow provides the intake layer. It captures the basic information needed for an emergency request and creates the corresponding Salesforce records through the configured Emergency Response architecture. This provides a declarative alternative to developing a custom request workflow.

A Help Center template is primarily designed for knowledge and customer-support self-service and would require additional configuration to reproduce Emergency Response functionality. Creating a custom Case record type and relying on a generic Contact Support Form similarly duplicates functionality already supplied by the solution and introduces unnecessary technical debt.

The Set 3 source shows C and D as the selected combination for this item.

Study Guide Reference: Agentforce Public Sector Implementation Strategies and Best Practices – Emergency Response Management; Emergency Service Requests; Experience Cloud; preconfigured emergency-response digital experiences.

An unauthenticated Experience Cloud site backed by Salesforce Knowledge is the most efficient architecture for publishing frequently requested licensing and permitting information to the general public. Salesforce supports Knowledge articles in Experience Cloud and allows appropriately configured guest users to access publicly available articles without authenticating. This directly supports constituent self-service while reducing repetitive contact-center inquiries.

This approach also minimizes implementation and maintenance overhead because the agency can maintain its authoritative articles directly in Salesforce Knowledge and expose them through the Experience Cloud presentation layer. Salesforce specifically notes that an Experience Cloud site can function as a public knowledge base for unauthenticated users without requiring community licenses simply for public article access.

Option A introduces an unnecessary CMS integration and outbound API synchronization layer. Option B similarly adds unnecessary integration complexity through Lightning Out. Option D forces constituents to authenticate merely to read general application-process information, adding friction and potentially requiring additional license considerations.

The architectural best practice is therefore to keep public informational content openly accessible while reserving authentication for personalized records, applications, and protected constituent data.

Study Guide Reference: Agentforce Public Sector Implementation Strategies and Best Practices – Experience Cloud, Salesforce Knowledge, constituent self-service, guest-user access, and public information delivery.

================

Salesforce Shield is the strongest match because it is an integrated security, compliance, monitoring, encryption, and auditing suite rather than a single-purpose platform feature. Salesforce identifies Shield capabilities including Event Monitoring, Field Audit Trail, and Shield Platform Encryption , with current Shield offerings also including Data Detect.

Event Monitoring provides granular visibility into user activity and data access, allowing agencies to identify who accessed data and how it was used. Field Audit Trail extends historical field-change retention and supports regulatory, governance, auditing, and forensic requirements. Shield Platform Encryption protects sensitive data at rest while preserving substantial Salesforce application functionality. Salesforce explicitly positions Shield as supporting regulatory compliance and governance requirements.

Setup Audit Trail is useful for tracking administrative configuration changes but does not provide the broader data-access monitoring and encryption capabilities required by the scenario. Classic Encryption is much narrower. Standard Field History Tracking provides basic historical changes but lacks Shield's extended retention and comprehensive auditing functionality.

Salesforce Shield does not itself constitute ISO 27001 certification; rather, it provides technical controls and audit evidence that can support an organization's compliance program.

Study Guide Reference: Agentforce Public Sector Implementation Strategies and Best Practices – security architecture, regulatory compliance, Salesforce Shield, Event Monitoring, encryption, and auditing.

================

Grants Management and Outbound Funds Module provide the Salesforce-native funding architecture represented by this scenario. Salesforce states that Grants Management uses the Outbound Funds Module data model , which includes Funding Programs, Funding Requests, Reviews, Requirements, Disbursements, and related financial-tracking entities.

The grantseeker's submitted application is represented by a Funding Request . Review records capture the reviewers' status and feedback, while Disbursement records represent funds that have been made or are scheduled to be made to the recipient. Salesforce's Outbound Funds documentation specifically states that the module manages Funding Requests and outgoing funds and can create disbursements for expenditures.

For more detailed expenditure accounting, the Outbound Funds data model includes GAU Expenditure , which connects a Disbursement to a General Accounting Unit and identifies which allocation or accounting category funded the disbursement. This supports audit scenarios in which expenditures need to be distinguished among categories such as mortgage arrearage and utility assistance.

FinancialForce Accounting is an external accounting solution and is not required by this Public Sector design. Nonprofit Success Pack can extend certain GAU functionality, but selecting NPSP alone would not replace the Grants Management/Outbound Funds framework specified by the scenario.

Study Guide Reference: Agentforce Public Sector - Product-Specific Systems Knowledge – Grants Management; Outbound Funds Module; Funding Requests; Disbursements; GAU Expenditures.

================