Free Salesforce-Accredited-Agentforce-360-for-Public-Sector-Professional Practice Test Questions (2026)

Explanation:

This scenario requires a server-side process that can simultaneously check an external system for permit fees and query a Salesforce custom object for address-based discounts in a single transaction. The question tests knowledge of which OmniStudio component orchestrates multiple data sources and server-side actions. Integration Procedures are designed exactly for this purpose: calling external APIs via HTTP actions while retrieving Salesforce data via Data Mapper actions, all in one server round trip.

✔️ Correct Option:

B. Integration Procedure.
An Integration Procedure is a declarative, server-side process that executes multiple actions in a single server call. It can simultaneously make an HTTP call to the external permit fee system and run a Data Mapper Extract against the custom object storing address-based discounts. This eliminates round trips and enables the combined fee calculation to be performed server-side before returning results to the user interface.

❌ Incorrect Options:

A. FlexCard.
FlexCards are UI components designed to display contextual information on record pages. While a FlexCard can use an Integration Procedure as its data source, it cannot itself orchestrate external API calls or complex multi-source data retrieval. It is a presentation layer, not a processing engine.

C. DataRaptor.
DataRaptors (now called Data Mappers) are specialized tools for reading, transforming, or writing Salesforce data. They handle specific data operations but cannot call external systems via HTTP or orchestrate multiple actions in a sequence. A DataRaptor alone cannot meet the dual requirement of external API call plus Salesforce query.

D. OmniScript.
OmniScripts are guided, step-by-step user interaction flows for collecting information and completing business processes. They are client-side guided experiences, not server-side data orchestration engines. While an OmniScript can call an Integration Procedure to perform backend work, the OmniScript itself is not the feature that handles external integrations and multi-source data retrieval.

🔧 Reference:
🔗 Get to Know Omnistudio Integration Procedures – Salesforce Trailhead → Confirms Integration Procedures handle multiple data sources (Salesforce and external) and execute multiple actions in a single server call.

🔗 Get Started with Integration Procedure Designer – Salesforce Trailhead → Confirms Integration Procedures are built with drag-and-drop elements to define server-side logic and data integration declaratively.

Explanation

The requirement is to streamline electronic signatures for grant agreements with minimal custom development.
Agentforce Public Sector provides DocuSign eSignature capabilities that can be configured for document signing.
The GenericDocuSign/sendEsignature OmniScript is specifically designed to send generic documents for eSignature.
It can send documents associated with standard or custom Salesforce objects to recipients through DocuSign.
This approach uses existing configuration and OmniStudio functionality rather than requiring custom Apex code.
Therefore, option C directly addresses the requirement with less coding.

🟢 Correct Option

C. Set up the DocuSign integration electronic Signature and use Omniscript GenericDocuSign/sendEsignature to send the document to related parties
This option uses the available DocuSign eSignature integration together with the prebuilt GenericDocuSign/sendEsignature OmniScript. Salesforce documentation states that this OmniScript sends one or more generic documents to DocuSign for electronic signatures and supports documents associated with standard or custom objects. This provides a configuration-based approach for sending grant agreements to the required parties, reducing the need for custom Apex development and helping streamline the document-signing process.

🔴 Incorrect Options

A. Set up the DocuSign integration electronic Signature and use Omniscript GenericDocuSign /ObtainEsignature to send the document to related parties
The issue is the specified OmniScript. Salesforce documents GenericDocuSign/sendEsignature as the OmniScript used to send generic documents for eSignature. The proposed ObtainEsignature OmniScript is therefore not the documented Generic DocuSign option for this requirement.

B. Install and Configure the DocuSign managed package for Salesforce and send the document envelope from the flow using apex action
This approach introduces Apex into the solution, which conflicts with the requirement to use the available toolset with minimal coding. The documented GenericDocuSign/sendEsignature OmniScript already provides functionality for sending generic documents for eSignature without requiring this custom Apex-based approach.

D. Install and Configure the DocuSign managed package for Salesforce and send the document envelope from the flow using standard DocuSign actions
Although a Flow-based DocuSign solution can support electronic signatures, this option relies on installing and configuring a separate managed package rather than using the available GenericDocuSign OmniScript capability. The documented Public Sector/Industries approach provides a more direct configuration-based path through OmniScript.

Reference
⇒ Salesforce Help — Generic Documents for DocuSign eSignature — Confirms how GenericDocuSign/sendEsignature is used to send documents for electronic signatures.

⇒ Salesforce Help — OmniStudio and DocuSign — Confirms the relevant OmniScript and eSignature integration capabilities.

Explanation:

This question tests the architectural prerequisites for deploying Grants Management and Experience Cloud portals within Public Sector Solutions. To allow external organizations to apply for community grants through a portal, external portal access must be provisioned. Public Sector Solutions components, standard OmniStudio digital interactions, and Grants Management features are natively built for the modern Lightning Experience environment rather than Salesforce Classic. Furthermore, enabling Chatter is a baseline technical prerequisite for internal and external collaboration, feed tracking, and lifecycle updates on grant application records.

✅ Correct Option:

✅ A. Customer Community Licenses
Customer Community licenses are required to grant external applicants authenticated access to the Experience Cloud portal. This enables external users from applicant organizations to securely log in, submit grant applications, upload required documentation, and track application status online.

✅ C. Migrate Users to Lightning Experience
Public Sector Solutions and Grants Management rely on Lightning Web Components (LWCs), FlexCards, and modern user interface frameworks that are unsupported in Salesforce Classic UI. Migrating internal staff to Lightning Experience ensures full functional compatibility and operational support for packaged grant management components.

✅ E. Enable Chatter
Enabling Chatter is a mandatory foundational prerequisite for Public Sector Solutions and Grants Management. Chatter enables feed tracking, record-level collaboration, automated system notifications, and document discussion threads required across grant application evaluation and approval workflows.

❌ Incorrect options:

❌ B. Enable Web-to-Lead
Web-to-Lead is a lightweight lead capture mechanism designed for basic CRM sales pipelines. Grants Management in Public Sector Solutions handles complex relational data—such as Funding Opportunities, Individual Applications, and Accounts—via Experience Cloud portal forms rather than simple Web-to-Lead forms.

❌ D. Customer Community Plus Licenses
While Customer Community Plus licenses offer advanced features like delegated administration and role-based sharing, standard Customer Community licenses fully satisfy the baseline requirement for external grant applicants accessing portal forms. Recommending Plus licenses as a mandatory prerequisite introduces unnecessary licensing costs when standard community access is sufficient.

🔧 Reference:
→ Grantmaking in Public Sector – Salesforce Documentation confirms platform requirements, UI dependencies, and community portal licensing patterns for managing grants.

Explanation

This question tests how the Employee data model connects to the Public Sector data model so one person can be both a constituent and an employee.

Public Sector Solutions represents constituents as person accounts, so employee records must tie back to that same record. The Individual object serves as the shared link between the two.

✅ C. PersonAccount -- > Individual < -- Employee.
The Individual object acts as the common record that ties a person's data together across models. Linking the Employee record to an Individual, which is also linked to the person account, lets one person be treated as both a constituent and an employee. This gives the Public Sector data model and the Employee data model a shared, supported connection point without altering either model.

❌ A. User -- > Individual < -- Custom employee object
This path links the Employee to a User record instead of the person account. The requirement is to connect employees to the person account so Public Sector features can use the constituent record. A User is an internal login record, not a person account, and a custom employee object is not the standard Employee object.

❌ B. Contact -- > Individual < -- Employee
Contact links to Individual, but the requirement specifies the person account. Although a person account contains contact fields, the standard Public Sector model and Employee model connect through the PersonAccount record itself. Using a plain Contact would separate employees from the account-based constituent record that Public Sector features rely on.

❌ D. PersonAccount-- > User-- > Employee
This option chains the person account to a User and then to the Employee. User records represent internal logins for licensed users, not the shared identity record that connects data models. Routing through User would make constituent data depend on user provisioning and does not use the Individual object, so it is incorrect.

Reference
🔗 Employee to Person Account Field Mapping - Salesforce Help → confirms that employee records are linked to person accounts through the related person field.

Explanation:

This question tests knowledge of the prerequisite features required to support the Individual Application object in Grants Management for Public Sector. The scenario involves scholars applying for grants as individuals rather than organizations. The Individual Application object in Grantmaking is designed to track applications from individual applicants, which requires the Person Accounts feature to properly model these individuals in Salesforce.

✔️ Correct Option:

A. Person Accounts.
Person Accounts must be enabled to support the Individual Application object in Grants Management for Public Sector. Person Accounts are a type of account that stores information about individual people, such as scholars, who are not associated with a business account. The Individual Application object relates to an Account record, and when the applicant is an individual, that Account must be a Person Account .

❌ Incorrect Options:

B. Salesforce Flow.
Salesforce Flow is a standard automation tool available in all Salesforce orgs and does not require special enablement. While Flow Builder can be used to create guided review processes for applications, it is not a prerequisite feature that must be enabled to use the Individual Application object .

C. Custom Object for Applications.
The Individual Application object is a standard object provided by Grants Management for Public Sector. Creating a custom object for applications would be redundant and unnecessary, as the standard object is purpose-built for tracking grant applications. No custom object enablement is required .

D. Product Schedule.
Product Schedule is not a feature related to grant application management in Public Sector Solutions. It is used in other Salesforce contexts for managing product-based schedules and has no role in enabling or supporting the Individual Application object for grants management.

🔧 Reference:
🔗 Collect and Process Individual Applications – Salesforce Trailhead → Confirms that Individual Applications relate to an Account, where a person account represents an applying individual.

Explanation:

This question tests knowledge of the built-in DocuSign polling capability provided with the Salesforce Industries/Vlocity Contract Lifecycle Management integration. Rather than building a custom integration, the implementation should use the packaged scheduler specifically intended to retrieve status updates for eSignature envelopes.

✔️ B. Use the ContractEnvelopeStatusScheduler Apex class to schedule and poll DocuSign for statuses of envelopes submitted as part of the eSignature process.
ContractEnvelopeStatusScheduler is the Apex class supplied for Vlocity Contract Lifecycle Management’s DocuSign integration. It can be scheduled to poll DocuSign for envelopes submitted through the eSignature process and update their status in Salesforce. When scheduled from the Salesforce user interface, it runs hourly. It can also be scheduled programmatically at shorter intervals, but DocuSign requires at least 15 minutes between successive polling calls. Using the packaged class avoids unnecessary custom development.

❌ A. Use the ContractDocumentStatusScheduler Apex class to schedule and poll DocuSign for statuses of envelopes submitted as part of the eSignature process.
ContractDocumentStatusScheduler is not the packaged Apex scheduler identified for polling DocuSign envelope statuses in the Vlocity Contract Lifecycle Management integration. The integration operates on DocuSign envelopes, so the supported scheduler class specifically includes Envelope in its name. Selecting a similarly named but unsupported class would not implement the required status-polling process.

❌ C. Use the ContractStatusScheduler Apex class to schedule and poll DocuSign for statuses of envelopes submitted as part of the eSignature process.
ContractStatusScheduler is not the correct packaged scheduler for this purpose. The requirement is to retrieve the status of DocuSign envelopes, not to schedule general contract-status processing. Salesforce documentation specifically identifies ContractEnvelopeStatusScheduler as the class that polls DocuSign for statuses of envelopes sent through the eSignature process.

❌ D. Use the REST API provided by DocuSign to poll the status of a particular envelope.
DocuSign REST APIs can retrieve envelope information, but direct custom API polling is not the best option when the supported Salesforce integration already provides a purpose-built scheduler. Custom REST integration introduces additional work for authentication, callouts, error handling, scheduling, rate-limit management, and Salesforce status updates. ContractEnvelopeStatusScheduler handles the expected polling workflow within the packaged eSignature integration.

🔧 Reference:
→ Salesforce Help — Scheduling a DocuSign Job to Poll for Document Signed Status
→ Confirms that ContractEnvelopeStatusScheduler can be scheduled to poll DocuSign for statuses of envelopes submitted through the eSignature process.

→ Salesforce Help — Setting Up DocuSign Integration
→ Confirms that the scheduler supports DocuSign eSignature status polling and that DocuSign polling intervals cannot be less than 15 minutes.

Explanation

Salesforce Contracts uses DocuSign to provide standard eSignature functionality.
The integration supports sending contract documents for review and electronic signatures.
It can track signed documents and update the corresponding contract status.
It can also automatically invalidate a pending contract document when a newer contract supersedes it.
These three capabilities are explicitly documented by Salesforce as available DocuSign functionality.
Therefore, A, C, and E are the three correct functionalities.

🟢 A. Send a contract document for review and signatures.
DocuSign integration allows users to send a contract document to the relevant parties for review and electronic signatures. Salesforce specifically lists “Send a contract document for review and signatures” among the supported DocuSign capabilities for Salesforce Contracts. This provides the basic electronic-signature workflow needed to distribute agreements, collect signatures, and move the contract process forward without requiring custom coding for the standard signing process.

🟢 C. Automatically invalidate a contract document that is pending signatures if a new contract document supersedes it.
DocuSign integration also supports automatically invalidating a contract document that is still pending signatures when a newer contract document supersedes it. This prevents an outdated version from continuing through the signature process after a replacement contract has been generated. Salesforce explicitly identifies this automatic invalidation behavior as one of the capabilities provided through its DocuSign integration for Contracts.

🟢 E. Track the signed contract document and update the contract record status.
The integration can track the signed contract document and update the associated contract record status. Salesforce specifically lists this as a supported DocuSign capability. This keeps the Salesforce contract record synchronized with the electronic-signature process, allowing users to identify when signing has been completed and maintain the appropriate contract status without building a separate custom tracking mechanism.

🔴 B. Ability/Request to update the contents of the documents before signing by the reviewer
Salesforce's documented DocuSign capabilities include sending documents for review and signatures, tracking signed documents, and automatically invalidating superseded pending documents. They do not list a reviewer-requested capability to modify the contents of the contract document before signing. Therefore, this is not one of the three documented functionalities relevant to the question.

🔴 D. Approval process to invalidate a contract document that is pending signatures if a new contract document supersedes it.
The documented functionality is automatic invalidation when a new contract document supersedes a pending one. It does not describe a separate approval process as the mechanism for this action. Therefore, D changes the documented automatic behavior into an approval-based process and is not one of the three supported functionalities identified by Salesforce.

Reference
⇒ Salesforce Help — Workflow to Setup E-Signature for Standard and Custom Objects — Confirms that DocuSign can send contracts for review and signatures, track signed contracts and update status, and automatically invalidate pending contracts superseded by newer documents.

⇒ Salesforce Help — Setting Up DocuSign Integration — Confirms the available DocuSign eSignature capabilities for Salesforce Contracts.

Explanation:

This question tests understanding of OmniStudio FlexCard use cases. FlexCards are declarative UI components that display contextual information and provide quick actions without custom code. The question asks for two valid use cases, requiring differentiation between FlexCards and other OmniStudio tools like OmniScripts.

✔️ Correct Options:

B. A widget to aggregate complex data models for quick-glance information.
FlexCards are designed to summarize contextual information at a glance and can display data from multiple sources simultaneously. They help solve data fragmentation by providing a unified view of customer information from Salesforce objects, external APIs, and legacy systems. This makes them ideal for aggregating complex data models into a single, scannable card.

D. A homepage widget to quickly launch common processes.
FlexCards serve as the beginning and ending points for customer transactions and provide access to relevant tasks for displayed data. They can include action buttons that launch OmniScripts, Integration Procedures, or other processes directly from the card. This makes them effective as homepage widgets for initiating common workflows.

❌ Incorrect Options:

A. A widget to ask multiple pages of questions in the application form.
This describes an OmniScript, not a FlexCard. OmniScripts are guided, multi-step processes for collecting information and completing business processes, while FlexCards are primarily for displaying contextual information and quick actions.

C. A widget to perform in-line edits and calculations within a table quickly.
FlexCards display data but are not designed for complex in-line editing or calculations within tables. While they can include input elements, their primary purpose is information display and action launching, not spreadsheet-like editing functionality.

🔧 Reference:
🔗 Discover the Key Capabilities of Flexcards – Salesforce Trailhead → Confirms FlexCards summarize contextual information at a glance, display data from multiple sources, and serve as launching points for customer transactions.

🔗 Get to Know Omnistudio Flexcards – Salesforce Trailhead → Confirms FlexCards help with scattered customer data by combining data from multiple sources and displaying contextual actionable information with buttons that trigger processes.

Explanation

This question tests the lifecycle and modification rules for Action Plan templates in Public Sector.
An Action Plan template defines the tasks and steps used to guide an inspection or other business process.
After an Action Plan template is published, its definition becomes locked and cannot be edited directly.
This behavior prevents changes to an active template from unexpectedly affecting existing action plans.
Therefore, the missing Edit button is expected behavior rather than a page-layout or permission issue.
To make changes, the appropriate approach is to create or use a new template version.

🟢 D. Once published, an Action Plan template cannot be changed.
Published Action Plan templates are locked from direct modification. Salesforce prevents changes to the template after publication because the template may already be used to generate Action Plans for inspections and other processes. This protects the consistency of existing records and prevents changes to an active template from unexpectedly altering the tasks or steps associated with previously created Action Plans. Therefore, the absence of the Edit action after publication is expected behavior rather than a permission problem.

🔴 A. Edit option needs to be added to Action Plan template page layout
The Edit action is not missing because it needs to be added to the page layout. The restriction is related to the lifecycle state of the Action Plan template. Once the template is published, Salesforce prevents direct editing, so adding an Edit action to the layout would not resolve the issue.

🔴 B. Action Plan template changes have to be requested to Salesforce support team
Published Action Plan templates do not require a Salesforce Support request simply because they cannot be edited. The limitation is part of the standard template behavior. Administrators should manage the template through the supported configuration process rather than requesting Salesforce Support to modify a published template.

🔴 C. System Administrator doesn ' t have " Edit " permissions to Action Plan template
The missing Edit action is not caused by the System Administrator lacking object permissions. The key restriction is that the Action Plan template has already been published. Salesforce locks published templates from modification, so granting additional Edit permissions would not make the Edit action available for that published template.

Reference
⇒ Salesforce Help — Action Plan Templates — Explains the Action Plan template lifecycle and the restrictions that apply after a template is published.

Explanation:

This question tests the Work.com components that can be installed to support Employee Experience for Public Sector. These capabilities help government agencies provide centralized employee self-service, HR support, knowledge access, service-request management, and personalized assistance through Salesforce.

✔️ A. Employee Workspace
Employee Workspace provides a centralized employee-facing experience where staff can locate relevant resources, complete tasks, access service information, and view employee-related content. Within Employee Experience for Public Sector, it supports a unified workspace for internal users rather than requiring employees to navigate separate apps and processes. It is an installable Work.com capability associated with Employee Experience and Employee Concierge permission and data-access components.

✔️ C. HR Service Center
HR Service Center is a Work.com capability that supports HR service delivery through structured employee cases, service requests, knowledge, queues, and agent workflows. It enables HR teams to manage and resolve employee inquiries efficiently while maintaining appropriate access controls for sensitive information. The feature is designed for employee-service operations and is included as part of the Work.com functionality that can support an Employee Experience for Public Sector implementation.

✔️ E. Employee Concierge
Employee Concierge provides a guided employee-support experience that helps staff find answers, access resources, and receive assistance through a unified digital interface. It works with Employee Workspace and related employee service capabilities to improve self-service and reduce the need for employees to search across multiple systems. Salesforce documentation includes Employee Concierge user data access and an Employee Concierge Access Group within the HR Service Center installation and permission model.

❌ B. Workplace Strategy Planner
Workplace Strategy Planner is not one of the Work.com managed packages or features installed for Employee Experience for Public Sector. This option is associated with workplace planning and operational-return strategies rather than the employee self-service and HR support capabilities tested in this question. The Employee Experience implementation focuses on employee workspace, HR service operations, and concierge-style employee support.

❌ D. Workplace Command Center
Workplace Command Center is not an Employee Experience for Public Sector installation component. It is associated with workplace operational monitoring and response use cases, such as workplace safety, site capacity, and return-to-work coordination. Although it can be part of broader Work.com offerings, it does not provide the core employee self-service, HR case management, and employee concierge capabilities required for this implementation.

🔧 Reference:
→ Salesforce Help — Enhance Employee Operations with Employee Service
→ Confirms that HR Service Center is part of Salesforce Employee Service and supports employee service operations.

→ Salesforce Help — Assign HR Service Center Permissions
→ Confirms the installation and access model includes Employee Workspace and Employee Concierge capabilities.