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

Before an initial OmniStudio package installation, Salesforce requires the organization to prepare both the browser environment and the Salesforce org.

First, the browser and Salesforce environment must satisfy the published minimum requirements. Salesforce specifies supported browser requirements, JavaScript availability, minimum system resources, a supported Salesforce edition, and the necessary OmniStudio entitlement. Second, the org must have Orders enabled. Third, email deliverability must be configured with the access level set to All email. These settings are part of Salesforce ' s explicit pre-installation checklist. The preparation procedure is intended to avoid package-test and runtime failures caused by missing Salesforce platform dependencies. Salesforce also notes that Enhanced Email is normally enabled and that OmniStudio package testing uses functionality related to the EmailMessage object. Person Accounts can be an important Public Sector prerequisite when the agency needs to represent individual constituents, but Person Accounts are not a universal OmniStudio package installation prerequisite. Similarly, enabling Assets is not one of the specified package preparation requirements. The proper sequence is therefore to validate the supported browser and platform environment, enable Orders, and ensure Salesforce email deliverability is configured for All email before beginning installation.

Study Guide References: Prepare to Install OmniStudio; OmniStudio Package Prerequisites; Enable Orders; Email Deliverability; Browser and Platform Requirements.

Emergency Hotspots and Global Emergency View are the preconfigured analytical dashboards identified for the Emergency Response Management solution in the supplied Agentforce Public Sector material. These dashboards are intended to give emergency-management teams rapid situational insight without requiring administrators to design an analytics application from the ground up.

The Emergency Hotspots capability focuses on identifying geographic or operational areas where emergency-intake demand is increasing. Salesforce ' s Emergency Response analytics documentation confirms that the analytics application is designed to identify hotspots in which emergency requests are increasing so resources can be allocated quickly. The Global Emergency View complements that localized perspective by giving decision-makers a higher-level consolidated view of emergency operations, supporting prioritization and resource allocation across the response program. This type of packaged analytics is valuable during an active incident because agencies need operational visibility immediately rather than after a lengthy custom dashboard-development cycle. Visits is primarily an operational record type rather than the named packaged emergency dashboard in this scenario. Emergency Requests Overview is also not one of the two dashboard names identified by the supplied curriculum question.

Study Guide References: Emergency Response Management; Analytics for Emergency Response Management; Emergency Hotspots; Global Emergency View; Emergency Intake Analytics.

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.

Business Rules Engine separates reusable lookup logic from procedural rule execution. Decision Matrices contain business-rule lookup tables with defined input and output columns. When supplied with input values, the matrix searches for the applicable row and returns its configured output. Salesforce describes Decision Matrices as useful for implementing complex rules in a systematic and readable manner.

Expression Sets orchestrate more sophisticated decision logic. They can execute calculations, conditional branches, aggregations, constants, variables, and matrix lookups. An Expression Set can therefore call a Decision Matrix at the appropriate point in a licensing or eligibility process and use the returned value in subsequent calculations or decisions. Salesforce specifically documents Expression Sets calling Decision Matrices and consuming the output corresponding to the matching matrix row. This architecture allows policy data and procedural calculations to be maintained independently. For example, a licensing fee table can be maintained in a Decision Matrix while an Expression Set calculates intermediate values, invokes the matrix, and produces the final fee. The other options reverse these functions or mischaracterize the data interface. Decision Matrices do not perform the broader sequence of calculations attributed to Expression Sets.

Study Guide References: Business Rules Engine; Expression Sets; Decision Matrices; Licensing Business Rules; Declarative Decision Automation.

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.

FlexCards are designed to present contextual information at a glance and expose relevant actions that users can execute directly from the card. Salesforce defines a FlexCard as a configurable information block that combines pertinent data with links or actions for processes within a specific context.

This makes option B a valid use case. A FlexCard can retrieve and display information from one or more configured data sources and summarize complex or related data into a concise, quick-glance user interface. Salesforce also documents FlexCards as presenting contextual data and actions together. Option D is also appropriate because FlexCards support numerous actions. Administrators can configure them to launch an OmniScript, navigate to another page or application, display a flyout, trigger data operations, or initiate other supported processes. A homepage FlexCard can therefore provide shortcuts into commonly used workflows. A multi-page questionnaire is more appropriately implemented with an OmniScript, whose primary purpose is guided interaction. Likewise, although FlexCards can support actions and data updates, complex inline tabular editing and calculation is not the primary use case represented here.

Study Guide References: OmniStudio FlexCards; Contextual Information; Data Sources; FlexCard Actions; OmniScript Launching; Quick-Glance User Experiences.

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.

Public Sector provides a dedicated Public Complaint object for recording concerns submitted by constituents and a separate Case object for managing the organization ' s investigation and response. This separation aligns directly with the requirement to distinguish external complaint intake from internal casework.

Salesforce ' s complaint-management architecture uses the Public Complaint record to capture the reported incident, reporter information, and associated supporting details. Public Sector can then create a separate Case related to that complaint so case managers can prioritize the matter, assign caseworkers, investigate the concern, and track follow-up activity. Salesforce ' s investigative case-management documentation also identifies the Public Complaint as the intake record created when a constituent submits a concern and supports subsequent case creation and proceedings based on that complaint. Using Case record types for both external intake and internal investigation would collapse two distinct business concepts into one object. A custom complaint object is unnecessary because Public Sector already provides the appropriate standard industry object and its relationships.

Study Guide References: Complaints Management; Public Complaint; Investigative Case Management; Case; Experience Cloud Complaint Intake; Constituent Reporting.

The emergency-response digital experience requires the Public Sector constituent model, web-based request intake, and the packaged Emergency Response functionality.

Person Accounts support individual constituents interacting with the agency and allow the organization to represent residents as people rather than business organizations. Web-to-Case provides web-originated request intake so constituents can submit service requests that become Salesforce records for routing and processing. The Emergency Response Management managed package supplies the purpose-built Public Sector emergency-response components and processes required by the solution. Salesforce describes Emergency Program Management as enabling agencies to publish emergency-program information and allow constituents and businesses to submit applications and requests for assistance through an Experience Cloud site. It supports services such as emergency assistance, building-access permits, and other crisis-related programs. Salesforce also identifies Emergency Program Management as a core Agentforce Public Sector functional area for mobilizing resources, processing emergency-service applications, communicating status, and managing volunteers. Email-to-Case addresses requests arriving by email rather than the specified web-based experience. The unmanaged package is not the standard packaged deployment model represented by this implementation.

Study Guide References: Emergency Program Management; Emergency Response Management; Person Accounts; Web-to-Case; Experience Cloud Emergency Services.

Decision Matrices are the appropriate Business Rules Engine component when a licensing process must map a combination of defined inputs to a corresponding result such as an application fee. Salesforce defines a Decision Matrix as a lookup table containing user-defined input and output columns. At runtime, the matrix evaluates supplied input values, finds the matching row, and returns the configured output.

For a sporting-event licensing process, the inputs can represent attributes such as license type, event classification, location, capacity, duration, or other fee-determining criteria. The output column can contain the applicable fee. An Expression Set or OmniStudio process can invoke the matrix during application processing and use the returned amount to populate or calculate the application ' s fee. This design keeps regulatory fee schedules outside procedural automation. When the government agency changes a fee or threshold, administrators can update the Decision Matrix rather than modifying Flow, Process Builder, or custom code. Workflow Field Updates and Process Builder are general automation mechanisms and do not provide the structured multi-input lookup model that Business Rules Engine provides.

Study Guide References: Business Rules Engine; Decision Matrices; Licensing Fee Configuration; Expression Sets; Declarative Regulatory Calculations.

Person Accounts allow Salesforce to represent an individual person using the Account data model rather than requiring the individual to be modeled as a conventional business Account with a separate Contact. Salesforce implements Person Accounts by combining Account and Contact behavior into a single record experience while retaining the underlying Account foundation.

This model is particularly appropriate in Public Sector because agencies commonly serve individual constituents as well as businesses. A private resident applying for a permit, license, benefit, or government service can be represented as a Person Account, while businesses continue to use Business Accounts. Salesforce confirms that enabling Person Accounts creates distinct Account record types for business accounts and person accounts. Therefore, the statement that Person Accounts do not support record types is incorrect. Person Accounts also cannot simply be disabled after activation. Salesforce states that enabling Person Accounts fundamentally changes the organization ' s data model and that the feature cannot be disabled once enabled. The model does not combine Opportunity and Contact fields. Its design combines Account and Contact characteristics to create a person-centric Account representation suitable for organizations that interact directly with individuals.

Study Guide References: Person Accounts; Public Sector Constituent Data Model; Account and Contact Model; Licensing and Permitting Constituents; Person Account Enablement Considerations.

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 configuration should begin by turning on Document Checklist functionality, because Intelligent Document Automation uses document checklist items to organize, associate, and manage documents received for application-processing workflows. Salesforce ' s documented Document Type setup procedure explicitly requires enabling Document Checklist before creating the relevant document structure.

The consultant must then create a Document Type representing the Business License Application. Document types define the category of incoming information and provide the structure required for document extraction and transformation. Finally, the intake officer must receive the appropriate permissions and permission sets. Salesforce specifies the Document Checklist and Intelligent Document Workspace permissions for users who work with documents and forms and also requires appropriate object-level access to objects such as Received Document and Received Document Type. This is the configuration layer that allows document-processing access to be limited to the intended users. Document types are configured through Salesforce ' s Document Type functionality, not Notes and Attachments. The resulting architecture supports controlled document intake, checklist management, structured extraction, and review of business license applications.

Study Guide References: Intelligent Document Automation; Document Checklist; Document Types; Intelligent Document Workspace; User Access and Permission Sets.

Salesforce Knowledge combined with a public, unauthenticated Experience Cloud site provides the most direct self-service architecture for this requirement. Salesforce Knowledge centralizes permit and licensing guidance in managed articles, while Experience Cloud can expose approved Knowledge content directly to guest users. Salesforce explicitly supports making Knowledge articles available to unauthenticated users when the appropriate article visibility, guest-user access, and sharing configuration are established.

This architecture minimizes integration overhead because the agency does not need to maintain outbound API synchronization with a separate CMS or develop a Lightning Out implementation. It also avoids imposing an unnecessary authentication step on constituents who merely need general process information before starting an application. Articles can be updated centrally in Salesforce and surfaced immediately through the digital experience according to publication and visibility settings. An authenticated site is appropriate when information is constituent-specific or access must be restricted, but general licensing instructions, FAQs, prerequisites, and application guidance can be exposed publicly. This lowers call-center demand while preserving Salesforce as the authoritative content-management location.

Study Guide References: Experience Cloud for Public Sector; Salesforce Knowledge; Guest User Access; Public Self-Service; License and Permit Digital Experiences.

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.

DocuSign is the eSignature provider integrated with the Salesforce Industries contract and document-signature framework used by this Public Sector implementation pattern. Salesforce documentation states that Salesforce Contracts uses DocuSign to support electronic signatures and that a DocuSign integration and active DocuSign account are required for the supported eSignature workflow.

The integration provides a complete signature lifecycle. Documents can be sent for review and signature, the signed contract can be tracked, the contract record status can be updated, and an unsigned contract document can automatically be invalidated when a newer version supersedes it. Salesforce also provides OmniStudio-based DocuSign functionality for sending documents generated from supported objects. The GenericDocuSign/sendEsignature OmniScript can initiate an electronic-signature transaction and the related envelope components can expose signature status. This packaged integration reduces the amount of custom development required compared with building a bespoke electronic-signature integration through APIs, custom Apex, or custom UI components. Adobe Sign, Conga, and eSignLive are not the provider identified by the Public Sector/Industries eSignature implementation represented in this scenario.

Study Guide References: eSignature Technologies; DocuSign Integration; Salesforce Contracts; OmniStudio eSignature; Contract Document Signing and Status Tracking.

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.

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.

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.

A Funding Program represents the overall strategic or thematic initiative through which an organization offers funding. In this scenario, the Department of Disaster Assistance has authorization to establish a funding initiative for government agencies affected by qualifying disasters. The program itself therefore needs to hold the program-level context, objectives, requirements, and supporting material that prospective applicants use when determining whether and how to apply.

Salesforce defines a Funding Program as a thematic or strategic program that an organization champions and funds. Programs can exist in parent-child hierarchies, allowing a broad disaster-assistance initiative to contain more specific regional or purpose-based programs. Salesforce also supports attaching files to a Funding Program so supporting information can be made available to grantseekers. A Funding Request, by contrast, represents an individual application for money submitted against a Funding Program. It captures the applicant ' s specific request rather than defining the funding initiative itself. A Business License Application belongs to licensing and permitting workflows and does not model grant programs.

Study Guide References: Grants Management; Outbound Funds Data Model; Funding Program; Funding Request; Program Requirements and Supporting Files.

Grants Management provides the complete grantseeker portal capability required for this scenario. Salesforce describes Grants Management as enabling organizations to launch a portal where grantseekers can discover funding opportunities, apply for funding, view application status, and submit ongoing progress information for awarded grants.

The portal is implemented through Experience Cloud using the Grantee Portal template. Salesforce states that this preconfigured template provides a place where applicants can view available Funding Programs, submit applications, and manage their applications after submission. The Grants Management workflow also supports application materials and attachments, allowing supporting documentation to be incorporated into the funding-request process. Although Grants Management uses the Outbound Funds Module data model underneath its grantmaking functionality, Salesforce distinguishes the products functionally. Grants Management provides enhanced portal capabilities, application workflows, self-registration, application mapping, review workspaces, Action Plans, and other grantmaker functionality beyond the basic Outbound Funds foundation. Foodvania therefore does not need to design a separate relief portal around the underlying Outbound Funds Module. Grants Management supplies the packaged portal experience required for external recipients to apply, provide supporting information, and monitor application status.

Study Guide References: Grants Management; Grantee Portal; Experience Cloud; Funding Programs; Funding Requests; Grantseeker Application Management.

Business Rules Engine provides three principal rule-building components represented by these options: Decision Matrices, Decision Tables, and Expression Sets.

A Decision Matrix is a structured lookup table that matches supplied input values to a row and returns the corresponding output. It is well suited to deterministic mappings such as fee schedules, eligibility thresholds, and prioritization categories. A Decision Table is a more flexible lookup mechanism that can read rules from Salesforce records, custom objects, custom metadata, or CSV-based sources and evaluate multiple inputs to return one or more applicable outputs. An Expression Set is the calculation and orchestration layer. Expression Sets can contain variables, constants, conditions, calculations, aggregations, and lookup steps and can call Decision Matrices or Decision Tables as part of a broader business rule. Salesforce describes the main BRE architecture as Expression Sets together with lookup tables, where Decision Matrices and Decision Tables comprise the lookup-table capabilities. Decision Trees and Expression Maps are not identified as core Business Rules Engine modules in this architecture.

Study Guide References: Business Rules Engine; Decision Matrices; Decision Tables; Expression Sets; Lookup Tables; Automated Policy Decisions.

Emergency Response Management for Public Sector is designed to support rapid intake, triage, resource coordination, constituent engagement, and emergency-program execution. The ERM managed package supplies the purpose-built emergency-response functionality and associated Public Sector components required by this implementation pattern. Salesforce ' s Emergency Response Management documentation describes the solution as supporting residents, communities, agencies, emergency requests, and resource allocation during emergency situations.

Person Accounts provide the appropriate Salesforce representation for individual constituents who interact directly with a government organization rather than through a business account. This allows individual residents to participate naturally in emergency-service processes while businesses continue to use the appropriate business-account structure. Web-to-Case provides a standardized web-based intake mechanism for external requests. Submitted constituent information can be converted into Salesforce Case records and subsequently routed into the agency ' s service-management processes. Email-to-Case is intended for email-originated requests and is therefore not the prerequisite for the specified digital web experience. Similarly, the unmanaged ERM package is not the deployment option used for the standard packaged emergency-response solution.

Study Guide References: Emergency Response Management for Public Sector; Community Response; Person Accounts; Web-to-Case; Public Sector Digital Experience Configuration.

Configuring regulatory authorizations in Agentforce Public Sector depends on defining the regulatory framework that describes who issues the authorization, what authorization is required, and what type of business requires it. Those requirements are represented by Regulatory Authority, Regulatory Authorization Type, and Business Type.

Salesforce defines Regulatory Authority as the agency or department responsible for defining and enforcing requirements for licenses, permits, and inspections. Regulatory Authorization Type represents a particular license or permit required for a specified activity or business. Business Type categorizes a business and its activities, enabling the authorization model to associate applicable licenses and permits with the correct class of business. Salesforce also provides Business Regulatory Authorization Type to map regulatory authorization types to business types. Inspection Type belongs to the subsequent inspection configuration process and determines the type of compliance inspection performed. Business Profile stores business-related information but is not one of the three foundational regulatory configuration entities identified here. Together, Business Type, Regulatory Authorization Type, and Regulatory Authority establish the declarative licensing framework required before license authorization processes can operate consistently.

Study Guide References: Regulatory Compliance Data Model; Regulatory Authority; Regulatory Authorization Type; Business Type; Licensing and Permitting Configuration.

The Build Your Own (LWR) Experience Cloud template is appropriate when the implementation requires very high control over page composition, styling, component behavior, performance, and brand fidelity. Salesforce describes the Build Your Own LWR template as a highly customizable Experience Cloud template based on the Lightning Web Components programming model and optimized for high-performance digital experiences.

For Bobahaven, the decisive requirement is a pixel-perfect experience based on supplied brand assets and detailed marketing guidelines. A Build Your Own site allows the implementation team to create custom Lightning Web Components and control the presentation layer at a much finer level than a preconfigured industry template. The Licenses and Permits Experience Site template can significantly accelerate a standard Public Sector implementation and is preferable when minimizing customization is the dominant goal. However, its predefined structure and styling are less appropriate when precise visual implementation is the primary requirement. LWR also provides a modern performance-oriented runtime and uses browser-native Lightning Web Component standards. The Aura-based Build Your Own option is an older architecture and does not provide the same modern runtime characteristics.

Study Guide References: Experience Cloud; Build Your Own LWR; Lightning Web Components; Digital Experience Architecture; LPI Constituent Experience.

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.

The standard architecture combines an OmniScript application form with Business Rules Engine. The OmniScript gathers the business information required to calculate the fee, such as authorization type, revenue, industry classification, or other regulatory attributes. The collected data can then be passed to Business Rules Engine for deterministic fee calculation.

Salesforce specifically documents using Business Rules Engine to calculate processing fees associated with Business License Applications. The documented configuration uses a Decision Matrix and Expression Set to determine an application fee based on information that a constituent enters in an OmniScript license application form. Decision Matrices are particularly appropriate when fee values depend on combinations of configurable business parameters. An Expression Set orchestrates calculations and matrix lookups and returns the resulting fee to the OmniScript. Salesforce confirms that Expression Sets and Decision Matrices accept JSON input from OmniScripts and return JSON output back to them. Implementing fee policy inside triggered Flows or Integration Procedures would place regulatory logic in a less appropriate layer. Integration Procedures are useful for orchestration and external integration, but Business Rules Engine is purpose-built for maintainable policy decisions and calculations.

Study Guide References: OmniScripts; Business Rules Engine; Decision Matrices; Expression Sets; Automated Application Fee Calculation; Licensing and Permitting.

The Licenses and Permits Experience Cloud site template is specifically designed for constituent-facing licensing, permitting, and inspection processes. Salesforce provides this template with preconfigured pages for assessing license or permit requirements, applying for licenses or permits, renewals, permits, complaints, applications, inspection history, and related constituent interactions.

Using this purpose-built template significantly reduces custom site development and ongoing maintenance. Public Sector also supplies dedicated components that can be added to the template ' s pages for licensing and permitting functions. These components support processes such as submitting applications, searching licenses and permits, renewing authorizations, and filing complaints. OmniStudio components such as OmniScripts can provide guided application experiences, while FlexCards can surface contextual information and actions. Maintaining these processes within a dedicated licensing-and-permitting site keeps the digital architecture aligned with the Public Sector product model rather than expanding a generic Help Center into a specialized regulatory application portal. OmniOut is principally used when OmniStudio experiences must run outside Salesforce-hosted experiences, so it is unnecessary for a standard Experience Cloud implementation.

Study Guide References: Licenses and Permits Experience Cloud Template; OmniStudio; OmniScripts; FlexCards; Constituent Digital Experiences.