AP-222 Questions and Answers

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.

Grants Management requires a modern Lightning and Experience Cloud architecture rather than a Salesforce Classic-only implementation. Salesforce ' s Grants Management installation requirements specify the appropriate Grants Management entitlement together with Customer Community Plus Login licensing and Lightning Experience enabled in the org. Digital Experiences and My Domain are also part of the broader installation prerequisites.

Customer Community Plus is required because grantseekers need authenticated access to richer application records and sharing capabilities than a basic high-volume customer community provides. Lightning Experience is necessary for the modern Grants Management application, components, workflows, and administrative experience. In the implementation model represented here, Chatter is also enabled to support Salesforce collaboration capabilities used alongside Grants Management processes. Web-to-Lead does not provide the grant application architecture; grant applications are modeled using Grants Management funding records and Experience Cloud processes rather than sales leads. Basic Customer Community licensing also does not satisfy the specified Grants Management portal entitlement. The consultant should therefore transition the relevant staff to Lightning Experience, provision the appropriate Customer Community Plus licensing for external grantseekers, and enable Chatter as part of the solution prerequisites.

Study Guide References: Grants Management Installation; Lightning Experience; Customer Community Plus; Chatter; Experience Cloud Grantee Portal.

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.

An OmniScript provides the declarative guided interview required to gather the constituent ' s city, county, annual business volume, building size, and other relevant attributes. OmniScripts support step-based data collection, validation, conditional questions, and integration with Public Sector records and Business Rules Engine.

A Decision Matrix is the appropriate mechanism for determining the recommended license from those inputs. Salesforce defines Decision Matrices as lookup structures that match input values to a rule row and return configured output values. Because business users can maintain matrix conditions independently from the user interface, Decision Matrices are especially useful when thresholds change frequently. Salesforce specifically supports invoking a Decision Matrix directly from an OmniScript. The OmniScript passes defined JSON input values to the matrix and receives the matching result, which can then be presented immediately to the constituent. This pattern also aligns with Public Sector fee and policy automation, where Salesforce recommends separating the guided digital experience from configurable business-rule logic. Omni-Channel is a work-routing capability, Einstein AI is unnecessary for deterministic policy rules, and custom LWC/Apex development would undermine the requirement for business-maintainable declarative rules.

Study Guide References: OmniScripts; Business Rules Engine; Decision Matrices; Declarative Eligibility and Recommendation Rules; Licensing and Permitting.

Volunteer Management provides structured functionality for organizing volunteer opportunities, shifts, registrations, and volunteer participation. A core requirement of volunteer coordination is maintaining accurate staffing information as assignments and shifts change. Consequently, volunteer-capacity information such as registered volunteers and remaining staffing requirements is maintained as shift participation changes, including when scheduled work is canceled.

Salesforce ' s current Volunteer Management documentation confirms the broader functional model: organizations can create volunteer opportunities, define shifts and required staffing, allow volunteers to browse and register for opportunities through Experience Cloud, and track the hours contributed by volunteers. Salesforce also explicitly identifies Experience Cloud capabilities that let volunteers register for roles and enable organizations to track volunteer hours. This makes volunteer project registration and time reporting native elements of the volunteer-management lifecycle. Expense-reimbursement processing is not one of the defining Volunteer Management capabilities described for this scenario, and a volunteer chatbot is not the core package feature being tested. The operational emphasis is on volunteer recruitment, scheduling, shift coverage, participation, and service-hour tracking.

Study Guide References: Emergency Response Management; Volunteer Management; Volunteer Projects; Volunteer Shifts; Volunteer Registration and Hours Tracking.

An Action Plan Template can standardize the recurring work required for each Business License Application while also including a Document Checklist Item for the applicant ' s driver ' s-license image.

Action Plan Templates serve as reusable blueprints containing Tasks, Document Checklist Items, or a combination of both. Salesforce documentation explicitly describes these templates as structures for defining repeatable work and required supporting documentation. Public Sector ' s Intelligent Document Automation guidance further confirms that Document Checklist Items can be incorporated into Action Plan Templates and are automatically created in Action Plans generated from those templates. This architecture maps cleanly to the scenario. Tasks can represent the background check, entry of results into the external system, recommendation preparation, and submission for approval. The driver ' s-license upload is represented by a Document Checklist Item associated with the required document type. The resulting Action Plan gives reviewers a consistent operational checklist while still allowing application-specific work to be managed where required. Option C contradicts the documented ability to add Document Checklist Items to Action Plan Templates. The other restrictive statements do not reflect the flexibility of Action Plans for managing and extending operational work.

Study Guide References: Action Plans; Action Plan Templates; Tasks; Document Checklist Items; Business License Application; Intelligent Document Automation.

Decision Explainer is the Public Sector capability used to provide transparency into calculations performed by Business Rules Engine. Salesforce describes it as a collection of setup objects that helps users understand why a business rule produced a specific result. This is particularly important in government processes where eligibility, benefits, fees, or prioritization decisions must be explainable and auditable.

Salesforce specifically identifies individual and business application fees, unemployment benefits, and housing loan eligibility checks as Public Sector examples where Decision Explainer can provide insight into Business Rules Engine calculations. Decision Explainer works with Expression Sets and their execution data so authorized users can examine the variables and calculations contributing to a determination. This capability supports transparency in benefits administration because reviewers can trace a calculated result rather than treating automated policy decisions as a black box. The same architecture is applicable to fee calculations and eligibility checks because these processes commonly use Decision Matrices and Expression Sets to evaluate constituent information against government policy.

Study Guide References: Decision Explainer with Public Sector; Business Rules Engine; Expression Sets; Application Fee Calculations; Benefit and Eligibility Decisions.

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.

Partner Central is the Experience Cloud template designed for partner and channel-management scenarios. Salesforce specifically identifies Partner Central as supporting lead distribution, lead monitoring, deal registration, partner onboarding, channel programs, and collaborative marketing capabilities. Salesforce documentation states that organizations can use Partner Central to implement lead distribution and deal registration and manage channel-sales relationships without constructing those functions from the ground up.

Deal registration is particularly relevant because Partner Central includes predesigned components and processes for partner-submitted deals, including Quick Create capabilities, lead and deal list views, approval workflows, and channel-conflict management. The template also supports partner recruitment and onboarding as well as marketing initiatives such as campaigns and market-development activities. Help Center is primarily intended for customer self-service and knowledge delivery, while Customer Account Portal focuses on customer account interaction. Neither is optimized for partner relationship management and channel-selling workflows. Partner Central therefore aligns directly with the agency ' s requirement to manage external associates as channel partners.

Study Guide References: Experience Cloud; Partner Central; Partner Relationship Management; Lead Distribution; Deal Registration; Channel Marketing.

Public Sector includes native configuration for automatically creating Regulatory Code Violation records from inspection assessment results. Salesforce ' s current terminology identifies the relevant field as Assessment Question Status on the Inspection Assessment Indicator record.

The administrator configures the applicable failure status—such as Fail—to indicate that the result represents a violation. When an inspector selects that configured result during inspection execution, Public Sector automatically creates the corresponding Regulatory Code Violation record. Salesforce explicitly includes Configure an Assessment Question Status to Automatically Create a Violation as part of standard Inspections Setup. This declarative configuration keeps regulatory behavior within the standard inspection model. Assessment Indicator Definitions define what inspectors evaluate, Assessment Task Definitions group indicators into inspection activities, and Inspection Assessment Indicators capture the actual results. The status configuration determines when those results generate violations. A custom Flow is unnecessary because the platform already provides the required automation. Similarly, Action Plan Templates determine the inspection workload but do not independently control the conversion of a failed result into a violation.

Study Guide References: Inspections Setup; Inspection Assessment Indicator; Assessment Question Status; Regulatory Code Violation; Assessment Indicator Definitions.

The Decision Matrix is the first configuration point to inspect when applications are being placed into incorrect prioritization categories. A prioritization matrix typically contains the combinations of input criteria—such as income, household characteristics, program criteria, application attributes, or calculated scores—and maps them to corresponding priority outputs.

Salesforce defines a Decision Matrix as a lookup table in which input values are matched against configured rows and the corresponding output values are returned. If a threshold, range, row, input mapping, rank, or output value in that table is configured incorrectly, otherwise valid application data can produce the wrong prioritization result. The administrator should therefore inspect the matrix version used by the active rule, confirm that the expected input columns contain the correct values, validate boundary conditions and ranges, and verify that each matching row returns the intended prioritization output. Expression Sets can invoke the matrix, but when the process is executing and the observed problem concerns an incorrect mapped priority, the underlying matrix is the most plausible source of incorrect policy data. Decision Explainer can provide additional runtime transparency where configured, but the configuration element directly representing prioritization lookup rules is the Decision Matrix.

Study Guide References: Business Rules Engine; Decision Matrices; Application Prioritization; Matrix Versions; Input/Output Rule Validation.

A Screen Flow provides the most flexible declarative experience for simplifying Visit creation. Instead of requiring users to navigate through related lists and manually populate every field, the flow can present only the fields required for the specific inspection process, prepopulate known values, apply validation, derive contextual values from the originating application, and create the Visit record automatically.

Salesforce ' s standard inspection documentation confirms that Visits are normally created from the Visits related list on a license application or public complaint and require information such as location, account, context, visit type, schedule, and inspector. A Screen Flow can streamline that sequence into a guided interaction launched directly from the application page. Flow is particularly appropriate because the requirement is user-interface simplification and record creation rather than custom programmatic processing. The flow can receive the application ' s record ID as context, retrieve related information, display the appropriate input controls, and create the Visit. Moving a related list does not eliminate manual data entry. A predefined action can prepopulate static or predictable fields, but a Screen Flow provides significantly greater control over conditional fields, validation, lookups, and multi-step creation logic.

Study Guide References: Inspection Management; Visit Creation; Salesforce Flow; Screen Flow; Business License Application; Individual Application.

Grants Management provides a dedicated Funding Request collaboration capability that allows applicants to invite other people to participate in completion of a Funding Request. Salesforce documents an Allow Funding Request Collaborators configuration specifically for this purpose.

A grantseeker can invite a collaborator using an email invitation containing a secure, time-sensitive link. After accepting the invitation, the collaborator can access the Funding Request according to the configured sharing model and assist with completing the application. Salesforce ' s Manage Collaborators component includes the automation needed to invite and manage collaborators and to control their Funding Request access. Salesforce also provides a sample Grants Management flow that sends Funding Request collaborator invitations and can be customized for organizational branding and communication requirements. This capability is preferable to handling collaboration through ordinary email because it keeps collaboration connected to the grant application, applies controlled access, and supports auditable application participation. A custom Requires Collaboration field provides no collaboration functionality, and an application feed is not the purpose-built mechanism for granting stakeholders controlled access to the Funding Request.

Study Guide References: Grants Management; Funding Request Collaboration; Invite Collaborators; Manage Collaborators; Grants Portal Sharing.

The appropriate relationship pattern is Person Account → Individual ← Employee. In the relevant employee-model architecture, the Individual record provides the common person-centric relationship layer through which Employee information can be associated with another Salesforce representation of the same person. Salesforce ' s Work.com data-model documentation describes Employee records being associated with Individual records and synchronization mechanisms that maintain the Individual relationship as employee information is created or updated.

Public Sector uses Person Accounts to represent individual constituents. A Person Account combines the Account and Contact representation into a single constituent-facing record and is the recommended Public Sector model for individual people applying for licenses, permits, benefits, grants, or government services. Consequently, when the Employee data model must coexist with the Public Sector constituent model, the Individual relationship provides the bridge between the Employee representation and the Person Account representation. Routing the association through User would incorrectly make the Salesforce user identity the integration point, and using Contact would not satisfy the scenario ' s explicit requirement to connect the employee model with a Person Account.

Study Guide References: Public Sector Person Accounts; Employee Data Model; Individual Object; Constituent Data Modeling; Cross-Cloud Person Relationships.

The appropriate design combines authentication, bot protection, and restrictive external record access. Experience Cloud allows individual pages to be configured as Requires Login, which prevents unauthenticated visitors from accessing those pages even when other portions of the site are publicly available. Grant application OmniScripts should therefore be placed behind authenticated access when they collect or expose constituent-specific information.

CAPTCHA or reCAPTCHA adds automated abuse protection by distinguishing legitimate human submissions from bots. Salesforce documents reCAPTCHA implementations for Experience Cloud scenarios specifically to prevent automated or fraudulent form submissions. The external organization-wide default for sensitive application records should also be Private. Salesforce recommends keeping external OWD settings Private whenever possible and then opening access only through controlled sharing mechanisms. With Private external access, authenticated external users cannot automatically see other constituents ' records. A public application-reference search page would risk unnecessary information exposure and does not prevent form abuse. The combination of authentication, CAPTCHA, and restrictive sharing implements defense in depth for constituent application data.

Study Guide References: Experience Cloud Security; Requires Login; CAPTCHA/reCAPTCHA; External Organization-Wide Defaults; Grant Application Privacy; OmniScripts.

Employee Experience for Public Sector is intended to digitize government employee services by combining Public Sector functionality with a dedicated employee-facing experience. Salesforce describes Employee Experience as supporting government employees with internal processes such as benefits, grants, inspections, licensing, permitting, case management, and other employee services.

OmniStudio is particularly important when replacing complex PDF forms because OmniScripts can convert static documents into guided, multi-step digital interactions with validation, conditional logic, and data integration. Flow provides process automation around submissions, approvals, routing, notifications, and record creation. The Employee and Public Sector data models provide standardized structures for employee and government-process information rather than requiring extensive custom objects. The Employee Community supplies the secure digital environment where employees can access and complete those processes. Salesforce ' s Employee Experience model is specifically designed to expose appropriate Public Sector capabilities to employees through a unified portal. A solution based only on Flow lacks the guided-form capabilities of OmniStudio, while Apex, Visualforce, and extensive custom objects would introduce avoidable custom development and long-term maintenance.

Study Guide References: Employee Experience for Public Sector; OmniStudio; OmniScripts; Salesforce Flow; Public Sector Data Model; Employee Community.

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.

Public Sector ' s inspection and complaint capabilities are designed to maintain operational traceability from a reported concern through investigation and regulatory follow-up. Salesforce supports Public Complaint records for constituent-reported issues and allows an agency to create visits directly from complaints so inspectors can investigate concerns onsite. The complaint can also surface related visits, regulatory code violations, enforcement actions, and supporting documentation.

Consequently, the agency should configure the standard Inspections and Visits framework and associate the resulting inspection activity with the relevant permit application. Salesforce describes Public Sector inspections as the mechanism for evaluating regulatory compliance through onsite visits, standardized assessment questions, recorded findings, violations, and enforcement activity. Cases can provide the managed investigation or service record associated with the reported issue and can participate in the broader Public Sector complaint and investigative data model alongside Business License Applications, Public Complaints, Visits, and regulatory records. Linking the appropriate case and field-inspection activity to the existing permit preserves the context required by reviewers and enforcement personnel. Business Rules Engine is intended for structured rule evaluation rather than determining whether a complaint is inherently valid. Action Plans can organize repeatable work but are not the essential linkage requested here.

Study Guide References: Public Complaints; Cases; Inspections; Visits; Permit Applications; Licensing, Permitting and Inspections Data Model.

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.

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.

Standard Salesforce Reports and Dashboards provide the appropriate solution because the requirement is straightforward operational visibility rather than advanced analytical modeling. A custom dashboard can summarize each approver ' s pending applications, status, age, and other approval metrics and can be placed directly on the Lightning Home page.

Salesforce supports embedding dashboards on the Home tab so that users see relevant operational information immediately after login. The Dashboard standard component can be added in Lightning App Builder and configured to display the required dashboard. The Home page can then be activated for an app-and-profile combination, which aligns precisely with assigning the custom page to the Approver profile. CRM Analytics would add licensing and administration overhead without being necessary for this operational requirement. A single report also provides less effective at-a-glance monitoring than a dashboard containing multiple approval metrics and visualizations.

Study Guide References: Salesforce Reports and Dashboards; Lightning App Builder; Custom Home Pages; Profile-Based Page Assignment; Approval Operational Reporting.

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.

The implementation requires enabling Intelligent Form Reader, configuring the extraction model, and mapping the relevant document or form information to Salesforce object fields.

Intelligent Form Reader provides the OCR capability needed to extract information from uploaded documents. Salesforce states that IFR can extract information and use it to create or update Salesforce fields or verify information already stored in the org. Identity-document processing can additionally use Amazon Textract Analyze ID. The administrator must then set up data extraction by defining the appropriate document or form type, supplying the sample document/template configuration, and identifying the information to extract. Finally, the extracted fields must be mapped to the required Salesforce target object and its fields. Salesforce explains that document fields can be mapped to target objects and record types and that extracted values are stored in the corresponding Salesforce fields. Current IFR mapping configuration also allows administrators to select target objects and map form fields declaratively from Intelligent Form Reader Setup. A DataRaptor does not perform OCR on scanned documents, and there is no separate Document-object OCR switch that replaces IFR configuration.

Study Guide References: Intelligent Form Reader; OCR; Data Extraction; Form/Document Types; Target Object Mapping; Application Field Mapping.

The standard Public Sector regulatory data model provides the Regulatory Code Assessment Indicator object for associating regulatory requirements with the indicators inspectors evaluate. Salesforce describes assessment indicator definitions as the conditions inspectors check during onsite visits and explicitly supports relating those indicators to applicable regulatory codes so inspectors can reference the governing code while evaluating compliance.

The broader regulatory data model also identifies Regulatory Code Assessment Indicator as part of the standard licensing, permitting, inspection, fee, and enforcement model. This enables organizations to model compliance requirements declaratively rather than introducing unnecessary custom junction objects or custom master-detail relationships. Using the standard relationship is important because downstream Public Sector capabilities—inspection checklists, assessment execution, regulatory-code visibility, violations, and enforcement processes—are designed around the Salesforce industry data model. Creating a custom Regulatory Code Map would duplicate standard functionality and increase maintenance and integration complexity. A direct master-detail relationship also would not represent the intended mapping architecture.

Study Guide References: Public Sector Regulatory Data Model; Regulatory Code; Assessment Indicator Definition; Regulatory Code Assessment Indicator; Inspections and Regulatory Compliance.

An Action Plan Template becomes immutable after it is published. Salesforce explicitly states that published Action Plan Templates cannot be edited or returned to Draft status.

This behavior protects the integrity of repeatable operational processes. Existing Action Plans may already have been generated from the template, and allowing administrators to alter the underlying published definition could create inconsistent inspection requirements between records created at different times. When inspection requirements change, the administrator should use the supported versioning approach: deactivate the published template if necessary, clone it to create a new template/version, modify the cloned Draft version, add or revise its tasks, checklist items, assessment content, or other configuration, and then publish the new version. Salesforce documents this same approach for application requirements and other Action Plan implementations. The absence of an Edit button is therefore expected behavior and is not resolved by adding the action to a page layout or granting additional permissions. Salesforce Support is also not required to modify the template. The same design principle applies broadly across Action Plans: all required content should be finalized before publication because the published template is treated as the controlled definition of the repeatable process.

Study Guide References: Action Plan Templates; Template Lifecycle; Draft and Published Status; Cloning Templates; Inspection Action Plans; Version Management.