AP-222 Salesforce Accredited Agentforce 360 for Public Sector Professional Questions and Answers

A secure constituent grant-application architecture should combine record-level privacy, authenticated access, and automated bot protection. Setting the external organization-wide defaults for application records to Private establishes a restrictive baseline. External users receive access only through explicit sharing mechanisms rather than being able to discover other applicants ' records. Salesforce consistently recommends restrictive external sharing for sensitive constituent data.

Grant application OmniScripts should also be hosted on Experience Cloud pages configured to Require Login. Authentication ensures that sensitive application information, supporting documentation, and application-status data are associated with a verified external user instead of being exposed through anonymous access. CAPTCHA provides a separate security control focused on automated form abuse. It helps distinguish human submissions from automated bots and reduces the risk of bulk fraudulent or spam applications. These controls address different threat surfaces and should therefore be implemented together rather than treated as alternatives. A public search page for application reference numbers does not prevent spam and can introduce unnecessary disclosure risk. Similarly, application protection should not rely solely on generic spam checking when authentication, restrictive record sharing, and CAPTCHA can be applied directly to the grant application experience.

Study Guide References: Grants Management Security; Experience Cloud Authentication; External OWD; CAPTCHA; OmniScript Security; Constituent Data Privacy.

An OmniStudio Integration Procedure is the appropriate orchestration layer because the transaction requires information from multiple sources and several server-side processing steps. Salesforce describes Integration Procedures as declarative server-side processes that can retrieve, transform, and send information between Salesforce and external systems, perform REST API calls, apply conditional processing, and execute several actions within a single server request.

In this scenario, the Integration Procedure can retrieve the base permit fee from the external system, retrieve the site or address information and applicable discount from the Salesforce custom object, apply the required processing logic, and return the resulting fee to the calling application experience. Salesforce explicitly recommends Integration Procedures when data must be accessed from multiple data-source types or when processing cannot be handled by a simple single-object extraction. A Data Mapper is optimized for comparatively focused Salesforce data operations and transformations. An OmniScript controls the guided user interaction, while a FlexCard primarily presents information and actions. Neither replaces the server-side orchestration required to combine external fee information with Salesforce data.

Study Guide References: OmniStudio Integration Procedures; External Data Integration; Data Mappers; OmniScripts; Licensing and Permitting Fee Processing.

Emergency Response Management provides a purpose-built Public Sector architecture for rapidly exposing emergency services to constituents. The appropriate implementation combines the preconfigured ERM digital-experience template with the prebuilt Emergency Service Request flow.

The template provides a starting point tailored to emergency-response scenarios rather than requiring the agency to assemble a generic portal from the ground up. Using the packaged experience reduces implementation time, preserves alignment with the Public Sector data model, and simplifies maintenance. The Emergency Service Request flow supplies the guided intake process through which a constituent can provide the basic information required for an emergency request. Public-facing Salesforce flows can be embedded in Experience Cloud so external users can submit information through a structured digital process. Creating a custom Case record type and adapting a generic support form would duplicate available emergency-response functionality. Likewise, the Help Center template is primarily designed for knowledge and support use cases rather than emergency program intake.

Study Guide References: Emergency Response Management; Emergency Service Request; Experience Cloud; Emergency Digital Experience; Public-Sector Emergency Intake.

Inspection Action Plan Templates are associated with individual Visit records because the tasks, assessments, regulatory checks, and signatures are performed during a specific onsite inspection. Salesforce ' s current configuration guidance instructs administrators to create the inspection template with Target Object = Visit and an inspection execution Action Plan type. In current Salesforce terminology, this is represented as Assessment Execution; the question uses the corresponding Visit Execution terminology.

The template can contain Assessment Task Definitions, which group the assessment indicators that inspectors evaluate. Those indicators can be associated with regulatory codes, enabling the inspector to understand which legal or regulatory requirement corresponds to each checklist item. This preserves traceability between what is inspected and the regulation being enforced. Salesforce also allows a Signature Task to be added directly to the inspection Action Plan Template. The signature task can be marked required and used to capture acknowledgement at the completion of the inspection. Targeting Business License Application would be inappropriate because the Action Plan represents the work conducted during the physical Visit, even though that Visit originates from or relates to a Business License Application.

Study Guide References: Inspection Visits; Action Plan Templates; Visit/Assessment Execution; Assessment Task Definitions; Regulatory Codes; Signature Tasks.

Salesforce ' s DocuSign integration provides a packaged electronic-signature lifecycle for contract documents. Salesforce explicitly documents that the integration can send a contract document for review and signatures, track the signed document and update the contract record status, and automatically invalidate a pending signature document when a newer contract document supersedes it.

These features maintain transactional integrity throughout the signature process. Sending the document initiates the controlled signature workflow. Status tracking keeps Salesforce synchronized with the state of the DocuSign envelope and enables the contract record to reflect completion. Automatic invalidation prevents a signer from executing an outdated document version after a newer authoritative version is generated. An additional Salesforce approval process is not required simply to invalidate the superseded signature document because that behavior is already part of the supported eSignature lifecycle. Similarly, changing contract contents during the signing process is not one of the standard DocuSign capabilities represented here. Document changes should occur through the controlled document revision and regeneration process before a new signature request is issued.

Study Guide References: DocuSign Integration; Electronic Signatures; Contract Documents; Signature Tracking; Superseded Document Invalidation.

Grants Management and the Outbound Funds Module provide the Salesforce funding data model and grant-management capabilities required to manage applications, awards, disbursements, and expenditure tracking.

Salesforce documents that Grants Management leverages the Outbound Funds Module data model. A Funding Request represents the application for funding and is the primary record through which the grantmaker evaluates and administers the applicant ' s request. Outbound Funds Module provides the underlying framework for tracking funding requests and outgoing funds such as grants and scholarships. Salesforce ' s feature comparison also shows that Grants Management and Outbound Funds support management of Disbursements against Funding Requests. Expenditure management can associate disbursements with accounting allocations, allowing the organization to categorize how awarded funding was used. This structure supports Foodvania ' s requirement to distinguish categories such as mortgage arrearage and utility assistance while retaining an auditable relationship back to the funding request and award. Grants Management supplies the richer grantmaker workflow—including application, review, requirements, portal, and grant lifecycle functionality—while the Outbound Funds architecture provides the foundational outgoing-funds records.

Study Guide References: Grants Management; Outbound Funds Module; Funding Request; Disbursement; Expenditure Tracking; Grant Review and Award Management.

Public Sector distinguishes between organizations and individual constituents through its account model. Salesforce explicitly recommends Business Accounts for businesses and Person Accounts for individual people. Person Accounts combine relevant Account and Contact information into a single constituent record and are intended for individuals applying for licenses, permits, programs, benefits, grants, and government services.

Because the agency is intentionally implementing its regulatory program in phases, it can first configure the business-oriented data model and processes for business constituents. Business Accounts and related Contacts support organizational applicants and associated representatives. When the agency is ready to extend services to individual private constituents, it can introduce the Person Account model and configure the corresponding individual application experiences. A Household Account is not the primary model for an individual constituent. Salesforce ' s relationship model uses Person Accounts to represent individual people and can optionally associate those people with business-account-based household structures when the business requirement calls for household modeling. Implementing both constituent models immediately would also contradict the agency ' s stated phased rollout objective and unnecessarily expand the first release scope.

Study Guide References: Public Sector Data Model; Business Accounts; Contacts; Person Accounts; Constituent Modeling; Phased LPI Implementation.

Public Sector provides a standard Business Regulatory Authorization Type Dependency model specifically for representing prerequisite and dependent licenses or permits. The administrator defines the first required authorization as the Parent Business Regulatory Authorization Type and the subsequent authorization as the Dependent Business Regulatory Authorization Type.

This configuration allows the agency to model relationships such as a business license that must be obtained before a fire permit, operating permit, or other dependent authorization. The standard data model should be used instead of recreating dependency logic with custom objects or hard-coded OmniScript conditions. Salesforce also provides the Permit component for displaying permits associated with a particular business type. In the Licenses and Permits Experience Cloud experience, constituents can view the licenses and permits required for their business type together with dependency information. This approach minimizes custom development and ensures that changes to permit dependencies are maintained declaratively in regulatory configuration data rather than embedded in presentation logic. It also keeps the Experience Cloud implementation aligned with the standard Public Sector regulatory data model.

Study Guide References: Business Regulatory Authorization Type; Authorization Dependencies; Business Types; Permit Requirements; Licenses and Permits Experience Cloud.

Business Rules Engine (BRE) is designed for high-volume, policy-driven decisions in which applications must be evaluated against defined conditions and consistently classified, qualified, prioritized, or assigned calculated outcomes.

BRE separates business policy from procedural automation through Decision Matrices and Expression Sets. Decision Matrices store structured rule tables, thresholds, and output mappings, while Expression Sets orchestrate calculations, conditions, matrix lookups, and final decisions. Salesforce specifically documents Business Rules Engine for determining applicant eligibility and benefit amounts based on defined criteria such as income and household size. This architecture is appropriate for grant qualification because administrators can change eligibility thresholds or decision criteria declaratively without rewriting Apex. The rules can also be tested before activation, versioned, and integrated with Decision Explainer when reviewers need transparency into why a particular application received a result. Flow is well suited to process orchestration, but it is not the specialized decision-rule framework represented here. Apex Trigger would require custom development, and Process Builder is not the preferred architecture for complex policy evaluation.

Study Guide References: Business Rules Engine; Decision Matrices; Expression Sets; Grant Eligibility; Application Qualification; Declarative Decision Automation.

A standardized eligibility and prioritization solution requires three complementary layers: structured applicant intake, declarative rule data, and executable decision logic. An OmniScript provides the guided application experience through which the grant seeker supplies the information required for eligibility assessment and prioritization. OmniScripts support multi-step questions, validations, conditional presentation, and integration with downstream rule processing.

A Decision Matrix stores decision data such as thresholds, categories, eligibility conditions, or scoring mappings. An Expression Set orchestrates the logic: it consumes application data, invokes the appropriate decision matrices, evaluates expressions, and returns eligibility or prioritization results. Salesforce ' s Business Rules Engine architecture uses Decision Matrices and Expression Sets together for declarative decision processing. A closely related Public Sector eligibility workflow is explicitly configured by customizing an OmniScript, creating a Decision Matrix, building an Expression Set, and then activating the experience. This architecture separates frequently changing policy data from the constituent-facing form and from executable rule orchestration, which improves maintainability and auditability. Web-to-Lead is designed to capture leads, while Web-to-Case creates service cases. Neither provides the purpose-built guided application and Business Rules Engine integration required for eligibility-based grant prioritization.

Study Guide References: OmniScript Designer; Business Rules Engine; Decision Matrices; Expression Sets; Grant Eligibility and Prioritization.

Salesforce Entitlement Management applies service-level processes to supported service records, particularly Cases. An Entitlement Process defines the service timeline, while Milestones represent required service steps such as response or resolution deadlines. Salesforce confirms that entitlement processes for this pattern run on Cases and can enforce milestone-based service levels.

The requirement is explicitly proactive management. Milestone Warning Actions are therefore essential because they execute when a milestone is approaching violation. Salesforce supports actions such as email alerts, tasks, field updates, flows, and outbound messages before an SLA deadline is missed. Violation Actions, by contrast, execute after the milestone has already been breached. Bobahaven can use Cases to operationally track applications requiring service intervention, associate them with the appropriate entitlement process, and configure milestones representing expected approval-response times. Warning actions can alert owners or supervisors while enough time remains to intervene. The alternatives that trigger escalation only after an SLA breach are reactive rather than preventive. Furthermore, standard entitlement processes are designed around supported service records such as Cases rather than being attached directly to Public Sector application objects in the manner proposed by the other options.

Study Guide References: Service Cloud Cases; Entitlements; Entitlement Processes; Milestones; Warning Actions; SLA Management and Escalation.

The grant lifecycle begins by planning the funding program and defining the objectives, available funding, eligibility criteria, requirements, and program structure. The organization then engages prospective grantseekers by publishing funding opportunities and communicating the requirements of the program.

The apply stage captures funding requests and supporting documentation from grantseekers. Next, the organization reviews applications through eligibility verification, requirements, due diligence, review assignments, scoring, and related decision processes. Salesforce Grants Management uses objects such as Funding Program, Funding Request, Requirement, Review, and Disbursement to support these activities. After review, successful applicants proceed to the award stage. The organization then manages the grant through requirements, disbursements, progress reporting, and continued interaction with the grantee. Finally, the funding relationship is closed out after final requirements, reporting, financial reconciliation, and completion activities have been satisfied. Accordingly, the correct sequence is Plan → Engage → Apply → Review → Award → Manage → Close Out.

Study Guide References: Grants Management Lifecycle; Funding Programs; Funding Requests; Reviews; Awards; Disbursements; Post-Award Management and Closeout.

Employee Experience and HR-service processes commonly use the Case object to represent sensitive employee requests, including HR, workplace, and employee-support matters. Because these cases can contain confidential personal or employment information, the appropriate baseline sharing model is to restrict access and then selectively grant it to authorized personnel.

Salesforce ' s Employee Concierge configuration explicitly sets the organization-wide default for the Case object to Private. This establishes the most restrictive standard access level and ensures that unrelated users don ' t automatically gain visibility into HR cases. Organization-wide defaults form the foundation of Salesforce record-level security. When Case is Private, the record owner and users who receive access through appropriate sharing mechanisms, queues, role hierarchy behavior, teams, or administrative privileges can access the case as configured. This supports least-privilege handling of employee information. Mirroring the organization chart into the role hierarchy could unintentionally widen access to confidential cases and does not itself secure HR data. Disabling approval processes has no direct relationship to record confidentiality. Likewise, the key security control required here is establishing Private OWD rather than relying on a hierarchy configuration as the primary protection.

Study Guide References: Employee Experience for Public Sector; HR Service; Case Security; Organization-Wide Defaults; Least-Privilege Record Access.

An Action Plan Template targeted at Account is the appropriate configuration because Grants Management due diligence is performed against the grantseeking organization represented by the Account record. Salesforce explicitly recommends using Action Plans on Accounts to define due-diligence steps, required tasks, and documentation that must be collected and verified.

The Action Plan Template acts as the reusable blueprint. It can include Tasks for activities such as validating organization details and Document Checklist Items for collecting statutory or financial documentation. When the template is published, grant managers can instantiate separate Action Plans against an Account, allowing multiple due-diligence processes to proceed in parallel while retaining their own tasks, ownership, deadlines, and verification records. Salesforce specifically supports Account as the target object when creating Grants Management due-diligence Action Plan Templates. An individual Action Plan is an execution instance rather than the reusable configuration requested in the scenario. Path is designed to guide records through stages, and Support Processes control Case status values; neither provides the structured task-and-document framework required for organizational due diligence.

Study Guide References: Grants Management; Due Diligence; Action Plan Templates; Accounts; Tasks; Document Checklist Items; Verification Checks.

Shield Platform Encryption and Event Monitoring provide complementary controls for protecting and monitoring sensitive information such as protected health information.

Platform Encryption protects sensitive Salesforce data at rest while preserving critical application functionality. Salesforce specifically identifies Platform Encryption as a capability that can help organizations address requirements associated with storing PHI, personally identifiable information, confidential data, and other sensitive information. Organizations retain control over encryption keys and can determine which supported fields and data categories are encrypted. Event Monitoring addresses the monitoring and audit side of the security model. It captures detailed information about user activity and system interactions, including who accesses Salesforce data, when access occurs, and the context of that activity. These event records can support security investigations, threat detection, compliance monitoring, and integration with external security platforms such as SIEM solutions. Together, these tools provide defense in depth: encryption protects sensitive PHI stored within the platform, while Event Monitoring supplies visibility into access and usage. Field Audit Trail is valuable for long-term field-change retention, and Setup Audit Trail tracks administrative configuration changes, but the pair explicitly aligned to PHI protection in the supplied scenario is Platform Encryption and Event Monitoring.

Study Guide References: Salesforce Shield; Platform Encryption; Event Monitoring; Protected Health Information; Public Sector Security and Compliance.

Intelligent Form Reader is the Public Sector capability designed to extract structured information from scanned forms and identity documents. It combines document processing and OCR-based extraction so data contained within a driver ' s license, passport, or other submitted document can be interpreted and mapped to Salesforce data.

Salesforce ' s Intelligent Document Automation architecture allows agencies to take paper or scanned documents and extract information into digital application records. This reduces manual transcription and allows reviewers to validate submitted information against the source document. For identity verification scenarios, the configured extraction process identifies fields such as name or date of birth from the document and maps those fields to the appropriate target Salesforce record. The resulting value can then be compared with information supplied in the application. Salesforce Files, Attachments, or Content can store the driver ' s license or passport, but storage does not perform document interpretation, OCR extraction, or field mapping. Intelligent Form Reader supplies the intelligence layer required to turn the uploaded document into structured information that can participate in validation.

Study Guide References: Intelligent Form Reader; Intelligent Document Automation; OCR and Data Extraction; Identity Documents; Application Field Mapping.

Agentforce Public Sector provides the Public Complaint object specifically for constituent-reported concerns and the Case object for subsequent internal investigation and follow-up. This separation supports the requirement to maintain external complaint intake independently from the agency ' s internal investigative work.

A Public Complaint can represent information submitted through an Experience Cloud site by either authenticated or anonymous users. After intake, authorized staff can create or associate a separate Case to manage investigation activities, ownership, status, work assignments, findings, and follow-up actions. Salesforce ' s Public Sector common-layer architecture distinguishes constituent intake records from operational case-management records, allowing the agency to retain the original complaint while independently managing the investigation. Using Case record types for both purposes would collapse two distinct business concepts into one object. A custom complaint object would also duplicate functionality already supplied by the Public Sector data model and increase maintenance effort. The standard Public Complaint plus Case model therefore provides cleaner data separation, supports anonymous/public intake, and gives internal staff an appropriate record for managed investigation.

Study Guide References: Public Complaint; Case Management; Experience Cloud Complaint Intake; Investigative Case Management; Public Sector Common Data Model.

Person Accounts must be enabled when Public Sector processes need to represent individual constituents, such as scholars applying personally for research or grant programs.

A Person Account represents an individual using Salesforce ' s Account architecture while combining person-oriented Account and Contact characteristics. This model allows Public Sector applications to associate government processes with an individual constituent without forcing the person into a traditional business-account structure. Employee Experience and broader Public Sector functionality use person-centric records extensively for applications, benefits, grants, licenses, cases, and related services. The Individual Application object is designed to represent an application submitted by an individual. Person Accounts supply the constituent identity model that supports that relationship. Salesforce Flow may automate parts of the process, but it does not replace the required person data model. A custom application object is unnecessary because Individual Application already exists, and Product Schedule is unrelated to constituent grant applications. Because Person Accounts materially change the Salesforce account model, their enablement should be planned deliberately during Public Sector implementation.

Study Guide References: Person Accounts; Individual Application; Grants Management; Constituent Data Model; Individual Applicants.

Action Plans provide the standard Public Sector mechanism for organizing, assigning, tracking, and completing repeatable groups of activities. Salesforce describes Action Plans as collections of tasks or checklist items that support repeatable business processes, with individual tasks capable of carrying an owner, priority, and deadline. This structure allows multiple reviewers, inspectors, caseworkers, and other employees to collaborate while retaining visibility into work status and accountability.

For inspections specifically, Public Sector uses Action Plan Templates to define the tasks required for a particular type of inspection visit. Templates can include assessment task definitions, required activities, task sequencing, and signature tasks. Published templates can then generate standardized action plans for individual visits, producing consistent inspection execution across teams. OmniStudio is suited to guided user interactions and integration orchestration, Business Rules Engine evaluates declarative decision logic, and Data Mappers/DataRaptors handle data transformation and persistence. None serves primarily as the collaborative task-management framework for inspection execution. Action Plans directly satisfy both requirements: automated creation of repeatable inspection work and coordinated execution by internal teams.

Study Guide References: Action Plans; Action Plan Templates; Inspection Visits; Assessment Tasks; Public Sector Inspections.

A secure external-user sharing model starts with Private external organization-wide defaults. Salesforce explicitly recommends configuring external OWD as Private whenever possible so authenticated Experience Cloud users cannot see records that they do not own or that have not otherwise been shared with them.

After establishing this restrictive baseline, Sharing Sets provide the controlled mechanism for granting external users access to the particular Accounts, Cases, Contacts, applications, and other records associated with their own Account or Contact relationships. Salesforce specifically documents this pattern for external and high-volume community users. This design follows least privilege: nothing is exposed by default, and the site user receives only the application and service records required for their own interaction with the agency. Traditional sharing rules can be useful for external users with roles, but they are not the universal mechanism for high-volume Experience Cloud users. Sharing Sets are purpose-built for these relationship-based external access scenarios. Hidden is not an available organization-wide default record-access level. Salesforce documents external access values such as Private, Public Read Only, Public Read/Write, and Controlled by Parent where applicable.

Study Guide References: Experience Cloud Security; External Organization-Wide Defaults; Sharing Sets; Customer Community; Grants Application Security.

Public Sector provides three purpose-built Lightning components for the Visit record page: Inspection Details, Inspection Actions, and Inspection Tab Container. Salesforce documents these components as part of the standard inspection experience used by inspectors, compliance officers, and caseworkers.

Inspection Details displays key Visit information such as location, scheduled time, person to visit, address, and inspection type. Inspection Actions provides operational controls such as Start Visit and End Visit and displays elapsed inspection time. Inspection Tab Container organizes inspection work into tabs for Tasks, Notes, and Details and can display a progress ring showing completion status. These components are specifically designed to reduce navigation and give inspectors the information and actions needed directly on the Visit page. Salesforce ' s standard Visit Lightning record-page configuration explicitly instructs administrators to place these inspection components on the page. Inspection Calendar and Inspection Dynamic Dashboards may support broader scheduling or analytical use cases, but they are not the three built-in Visit execution components identified for conducting an inspection.

Study Guide References: Inspection Management; Visit Lightning Record Page; Inspection Details; Inspection Actions; Inspection Tab Container.

Decision Explainer works with Business Rules Engine to provide an understandable record of how automated policy calculations and determinations were produced. This is especially valuable in public-sector use cases such as benefit eligibility, funding decisions, loan qualification, and regulatory fee calculation, where reviewers need transparency into the values and logic that generated an outcome.

Business Rules Engine supports automated determination of eligibility for public programs, including unemployment insurance, small-business loans, licenses, and other government benefits. Its core components—Expression Sets and Decision Matrices—evaluate input criteria and calculate outcomes. Decision Explainer can then be integrated with those rules so authorized reviewers can access decision logs and understand the calculation path. Education loan eligibility checks represent an eligibility-oriented rule in which applicant information is evaluated against defined qualification criteria. Individual and business application fees represent a calculation-oriented rule in which multiple factors determine the resulting fee. Both are appropriate Decision Explainer patterns because the underlying Business Rules Engine result benefits from a transparent explanation of inputs, conditions, and calculated outputs. Generic Person Loan or Car Loan labels do not correspond to the specified Public Sector Decision Explainer use cases represented here.

Study Guide References: Decision Explainer; Business Rules Engine; Eligibility Decisions; Application Fee Calculations; Expression Sets; Decision Matrices.

For implementations using the OmniStudio managed-package runtime, Tracking Service captures detailed interaction and performance information about OmniStudio components. Salesforce describes the Tracking Service as an event-tracking capability that records actions performed by users and can be used to identify process-improvement opportunities.

A directly relevant example is measuring how long users take to complete individual steps in an OmniScript. If one stage of a licensing application consistently requires substantially more time than expected, the implementation team can inspect the interaction data and determine whether the step contains unnecessary fields, confusing navigation, inefficient integrations, or another processing bottleneck. Tracking information can also capture events from Integration Procedures and Cards and store the results for analysis. Salesforce ' s managed-package architecture combines Tracking Service with OmniAnalytics to analyze user interaction and component performance. For OmniStudio standard runtime, Salesforce now provides OmniAnalytics rather than the legacy managed-package Tracking Service, so runtime architecture should be considered during implementation. Event Monitoring is a broader Salesforce security/activity product, while Field History Tracking records changes to Salesforce fields. Neither provides the same process-level OmniStudio interaction timing.

Study Guide References: OmniStudio Tracking Service; OmniAnalytics; OmniScript Event Tracking; Integration Procedure Tracking; Process Profiler; Performance Optimization.

Document processing for a Business License Application requires Document Checklist functionality, an appropriate Document Type, and controlled user permissions. Salesforce ' s current Public Sector configuration guidance first directs administrators to turn on Checklist Items with Attachments under Document Checklist Settings. This activates the document-checklist framework used to associate required documents with applications.

The administrator then creates an appropriate Document Type, such as Business License Application, so submitted documents can be categorized and used consistently in document-management and extraction workflows. Salesforce ' s Intelligent Document Automation documentation likewise identifies Document Types and Document Checklist Items as core components for managing documents received from constituents. Access must then be restricted to the intended intake officer. Salesforce directs administrators to assign the Document Checklist license and corresponding permission set to users who work with application documents. Object, field, and application-form permissions should be limited according to the intake officer ' s responsibilities. Notes and Attachments is not the Document Type framework used by Intelligent Document Automation. The secure configuration therefore combines Document Checklist enablement, a purpose-defined Document Type, and the appropriate permission assignments.

Study Guide References: Intelligent Document Automation; Document Checklist Settings; Document Types; Application Forms; Document Permissions and Access Control.

Business Rules Engine supports calculations across collections of values by using Aggregate Groups and Aggregate steps within an Expression Set. This is the appropriate pattern when a single application contains multiple selected permits and each permit contributes a fee to the final amount.

Salesforce documents that an Aggregate Group executes the preceding steps once for each set of input values and then aggregates the resulting values according to the configured aggregation logic. Within the Aggregate Group, the Aggregate step can perform SUM, AVG, MAX, or MIN operations. For this licensing scenario, each selected permit can be evaluated to determine its applicable fee. The Expression Set then places the repeated evaluation inside an Aggregate Group, and an Aggregate step using SUM produces the application ' s total permit fee. A custom Lightning component is unnecessary because Business Rules Engine already provides declarative list aggregation. Permission sets are required for appropriate design or runtime access, but assigning permissions does not implement the actual multi-permit fee calculation. This configuration keeps fee policy inside Business Rules Engine, making the logic easier to maintain and reducing the need for custom code.

Study Guide References: Business Rules Engine; Expression Sets; Aggregate Group; Aggregate Step; SUM Function; Licensing and Permit Fee Calculation.

Decision Explainer provides the explainability layer for decisions generated through Public Sector business processes, including eligibility, prioritization, and other Business Rules Engine outcomes. Adding the Decision Explainer Log History component to the Lightning record page makes the interface available, but component placement alone does not grant the user access to Decision Explainer functionality or its underlying records.

Salesforce specifies Decision Explainer access permissions for users who create, use, or review explainability information. Current Public Sector documentation identifies Decision Explainer Service Access for internal users working with Decision Explainer entities and decision logs. Salesforce also provides a Decision Explainer permission set license for access to Decision Explainer functionality. Therefore, after confirming that the component is correctly placed on the application Lightning page, the administrator should validate the caseworker ' s Decision Explainer permissions. OmniStudio Admin and OmniStudio User concern OmniStudio configuration and execution, while Rule Engine Runtime enables execution of Business Rules Engine logic. Those permissions do not independently provide access to the Decision Explainer user interface and decision history.

Study Guide References: Decision Explainer; Decision Explainer Log History; Business Rules Engine Integration; Public Sector Permission Sets and Permission Set Licenses.

For administrator-controlled registration, the Contact page layout should include the Enable Customer User action. This allows an authorized internal user to manually provision an Experience Cloud login from the constituent ' s Contact record rather than permitting visitors to create their own accounts.

Salesforce ' s documented manual-registration process instructs administrators to open Contact page-layout configuration and add Enable Customer User and, where appropriate, View Customer User. An administrator then opens the participant ' s Contact record, selects Enable Customer User, and specifies the username, profile, and other required user information. Current Salesforce guidance also confirms that Manage External Users functionality includes the Enable Customer User action and that these actions appear individually on Contact layouts in Lightning Experience. Self-registration would directly contradict the requirement because it allows external visitors to initiate account creation. There is no separate standard Contact action named Register User that replaces the established external-user provisioning mechanism described here. This configuration gives the PSO controlled onboarding of grantseekers while still allowing the resulting users to authenticate to the Grants Management Experience Cloud site after their accounts are provisioned.

Study Guide References: Grants Management; Experience Cloud User Administration; Manual Registration; Contact Page Layout; Enable Customer User.

Dynamic Assessments use categories to organize Assessment Questions so that different subsets of questions can participate in conditional assessment paths. This directly supports the restaurant scenario, where specific questions need to apply to take-away businesses, dining establishments, or businesses operating under both models.

Salesforce ' s Dynamic Assessments setup sequence explicitly directs administrators to create categories for similar types of assessment questions, create the assessment questions themselves, and then add those questions to Omni Assessment Tasks. The resulting form is used in an OmniScript, where conditional logic controls which questions are shown for a particular assessment scenario. The distinction between the objects is important. An Assessment Task Definition or Omni Assessment Task represents a broader group of questions or work to be performed. An Action Plan organizes the overall repeatable inspection workflow. Assessment Indicator Definitions are used heavily in regulatory inspection assessment models, but they are not the object on which this Dynamic Assessment question categorization is being configured. By categorizing the individual Assessment Question records, the agency can reuse a broader assessment while selectively presenting only the questions relevant to the type of food outlet being inspected.

Study Guide References: Dynamic Assessments; Assessment Questions; Question Categories; Omni Assessment Tasks; OmniScripts; Conditional Assessment Logic.