Accredited Professional Certification AP-222 Salesforce Study Notes

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.

Visual Studio Code together with Salesforce Developer Experience (DX) is the documented deployment mechanism for Lightning Web Components contained in Public Sector process packages. Salesforce ' s current Public Sector deployment procedure explicitly states that after importing process packages, administrators use Visual Studio Code and Salesforce DX to deploy the package ' s Lightning Web Components into the target Salesforce org.

The deployment workflow involves creating a Salesforce DX project in Visual Studio Code, importing the Lightning Web Components downloaded with the Public Sector process package, authenticating the target org, and then deploying the source metadata. This is required because the Lightning Web Component portion of the process package is Salesforce metadata and must be deployed through the developer tooling workflow. Change Sets can migrate many Salesforce configuration components between related orgs, but they are not the prescribed mechanism for installing these downloaded Public Sector process-package LWCs. The ANT Migration Tool is likewise not the documented deployment workflow for these components. Visual Studio Code without the Salesforce DX tooling also does not provide the complete project, authentication, metadata, and deployment framework required by the published Public Sector procedure.

Study Guide References: Public Sector Process Library; DataPacks/Process Packages; Lightning Web Components; Visual Studio Code; Salesforce DX Deployment.

Decision Explainer provides the explainability framework required to expose how Business Rules Engine calculations and determinations were reached. After a prioritization Expression Set and its supporting Decision Matrix have been configured, the rule must be integrated with Decision Explainer so that execution metadata and decision details are captured. Salesforce specifically states that integrating Business Rules Engine with Decision Explainer makes business rules available so Public Sector reviewers can access decision logs.

The Decision Explainer Log History component must then be added to the appropriate application Lightning record pages. This component displays each decision ' s timestamp, Expression Set name, and version, and allows reviewers to inspect variables, values, and formulas that contributed to the determination. Finally, reviewers require the appropriate Decision Explainer access. Salesforce identifies Decision Explainer Service Access as the permission needed to use Decision Explainer entities. A custom Screen Flow or Apex trigger is unnecessary because the platform already provides native logging, explainability entities, and the Lightning component.

Study Guide References: Business Rules Engine; Expression Sets; Decision Matrices; Decision Explainer; Decision Explainer Log History; Public Sector User Access.

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.