Free Salesforce Accredited Agentforce Health Professional Practice Test Questions

Explanation

In Salesforce Health Cloud (specifically within Integrated Care Management), Action Plan Templates are configured to handle structured, repeatable sequences of care tasks, including dependent intervention tasks.

Why Action Plan Templates (Option D):
Action Plans allow administrators and care coordinators to define repeatable sets of tasks with specific dependencies, deadlines, and task owners. When managing complex care plans or patient interventions, Action Plan Templates support dependent tasks, meaning a subsequent task can be automatically scheduled or triggered only after a predecessor task is completed.

Why Other Options Are Incorrect:

Intervention Templates (Option A): These are not the correct mechanism for handling automated task sequencing and dependency logic out of the box in this context.

Care Plan Task Templates (Option C): These are not the correct mechanism for configuring dependent task sequencing in this scenario.

Industry Template Library (Option B): This is a repository for prebuilt industry content, but the feature used to build and configure the actual structure of dependent tasks is the Action Plan Template.

References
Salesforce Help: Create Dependent Intervention Tasks with Action Plan Templates
Salesforce Health Cloud Implementation Guide – Integrated Care Management

Explanation

To customize the out-of-the-box Advanced Patient Card in Salesforce Health Cloud to display the Category, SubjectID, and Date for active Clinical Alerts, the developer should create a customized card configuration and retrieve the required Clinical Alert data.

B. Create and activate a new child card.
Create a child card to display the additional Clinical Alert information and activate it so the configuration can be used.

C. Clone the parent card.
Clone the existing parent card to preserve the original configuration while allowing customization of the Advanced Patient Card.

D. Create a DataRaptor to extract necessary data.
Configure a DataRaptor Extract to retrieve the Clinical Alert fields required for display, including Category, SubjectID, and Date.

Why the Other Options Are Incorrect

A. Change the child card state to show active.
Card states control conditional display behavior; they are not a substitute for creating the customized card and configuring its data source.

E. Define session variables to control visibility of clinical data.
Session variables can support contextual behavior, but they are not required simply to retrieve and display the specified Clinical Alert fields.

References

Salesforce Trailhead — Adapt the Patient Card in the Console
Explains how to customize patient card information.

Salesforce Developers — Clinical Alert Data Model
Documents Clinical Alert fields, including SubjectId, category, status, and dates.

Exam Tip
For this question, remember the three steps: clone the parent card, create and activate a child card, and create a DataRaptor to extract the required data.

Explanation

Why B Is Correct
In Health Cloud, each timeline’s appearance is controlled by its own Timeline View Configuration record, which you manage in the Health Cloud - Lightning Admin app. Orientation (horizontal or vertical) is a property of that configuration, so the administrator opens the configuration for each relevant timeline and changes the orientation to vertical. The change then applies wherever that timeline is shown.

Why the Other Options Are Incorrect

A. There is no single global toggle in Setup that flips all timelines to vertical.
Orientation is set per timeline configuration, not org-wide.

C. Enabling Timeline and building a new timeline from scratch
This is the process for setting up a timeline for the first time. The request is to change the appearance of existing timelines, so creating and activating a new one is unnecessary rework.

D. There is no Custom Metadata setting that controls the orientation of all timelines.
The setting lives on the Timeline View Configuration.

Reference
Health Cloud Timeline setup, specifically Timeline View Configuration in the Health Cloud - Lightning Admin app.

Explanation

In the OmniStudio FlexCard Designer, element-level appearance changes are handled through two routes:

B — Field Style
Each element (like a Field) has a Style panel where you can directly set styling properties such as the font family (e.g., Times New Roman) and text color (e.g., red). This is the standard, no-code way to apply formatting to an individual element.

D — Write Custom CSS
FlexCards support custom CSS, so a designer can target the element (using its element name or ID as a selector) and apply more advanced or precise styling beyond what's exposed in the Style panel.

Why the Other Options Are Wrong

A — Setup Panel
The Setup panel handles component-level configuration like data source bindings, sessions, and record IDs — not visual styling of individual elements.

C — Field Properties
The Properties panel defines what the element is and shows — the field label, data binding (which field from the data source it displays), etc. It controls content and behavior, not fonts and colors.

Key Takeaway for the Exam
In FlexCard Designer, remember the panel separation — Setup = data/component configuration, Properties = element content and behavior, Style = visual formatting. For appearance changes, think "Style panel first, custom CSS for anything more advanced."

Explanation

Health Cloud provides FHIR APIs that allow external systems (like a local hospital) to read, write, and update patient data using open standards. In FHIR, a patient's medical condition is represented by the Condition resource. The Health Cloud Clinical API supports the Condition resource, making it the appropriate method for sharing this specific clinical information.

Why the Other Options Are Incorrect

B. Leverage the MedicalCondition Integration Procedure
OmniStudio Integration Procedures are used for server-side data orchestration within Salesforce, not for exposing data to external systems via a standard healthcare interoperability protocol.

C. Use the FHIR Patient API through DataRaptor
The Patient API retrieves demographic information, not clinical conditions. DataRaptor is a data mapping tool, not the mechanism for external API access.

D. Expose the MedicalCondition object through an Apex class
This is a custom development approach. It bypasses standard FHIR interoperability and requires the external hospital to adapt to a proprietary interface, which is not the recommended best practice.

References

Salesforce Help: FHIR APIs on Health Cloud
Confirms that the inbound API library compliant with HL7 FHIR allows external systems to read, write, and update data directly into Health Cloud data models.

Salesforce Help: Support for Clinical Data in Health Cloud
States that the clinical data model is built to match the FHIR specification, and HealthCondition represents detailed information about conditions recognized by a clinician.

Explanation

In Health Cloud, patients and members must be modeled as Person Accounts.
A Person Account combines Account and Contact fields into a single record that represents an individual person (not an organization).
This creates a strict 1-to-1 relationship between the Account and Contact records behind the scenes.
Because a Person Account represents a standalone individual, the Parent Account field must remain blank (Person Accounts are not placed in an account hierarchy the way business accounts are).

Official Salesforce Documentation
“In Health Cloud, always model your patients or members as person accounts. You can’t fully use Health Cloud functionality if you don’t model your patients and members as person accounts.”

Why the Other Options Are Incorrect

A. Ensure the Parent Contact object is blank
There is no standard “Parent Contact” field or object requirement for patients or members.

D. Ensure the Account is the Parent to Household Accounts
Households are modeled as separate Account records (Household record type) that are related to the patient’s Person Account via the Account Contact Relationship object. The patient Person Account itself is not required to be the parent of the Household Account.

References
Salesforce Help: Set Up Person Accounts to Represent Health Cloud Members and Patients
Salesforce Help: Types of People in Health Cloud
Salesforce Help: Enable Person Accounts for Use in Health Cloud

Explanation

In Salesforce Health Cloud, patient care is coordinated through the Care Team. Care Team member roles define the level of access that team members have, including Read Only or Read/Write access to information associated with the patient's care plan. Create Roles for Care Team Members states that roles determine access to patient information and can be configured with read-only or read/write permissions.

Because the organization's Organization-Wide Default (OWD) for patient access is Private, access is not granted automatically. The administrator must add the respiratory therapist to the patient's Care Team and assign the appropriate access level.

Why the Other Options Are Incorrect

A. Add the respiratory therapist to the patient's Account Team and grant Read or Read/Write access as needed.
Incorrect. While Account Teams are a Salesforce feature, Health Cloud's out-of-the-box patient care access model is centered on Care Teams, not Account Teams.

B. Add the respiratory therapist to the patient's Account Team and default access will be automatically granted.
Incorrect. Access is not automatically granted simply by adding someone to an Account Team, especially with OWD set to Private.

C. Add the respiratory therapist to the patient's Care Team and default access will be automatically granted.
Incorrect. Care Team membership alone does not imply automatic access. The appropriate role and access level must be assigned.

Exam Tip
For AP-211 questions involving patient visibility and collaboration:

Care Team: Patient care collaboration model.
Private OWD: Explicit sharing or access assignment required.
Care Team Roles: Determine Read or Read/Write access.

Answer: D

Explanation

Salesforce Health Cloud uses OmniStudio components to retrieve, integrate, and display patient information from Salesforce and external systems.

B. Integration Procedures
Combine and orchestrate data from multiple sources, including Salesforce and external systems, to prepare information for display.

C. DataRaptors
Extract data from Salesforce objects and transform data into the required format. They can also load or transform data as part of an OmniStudio solution.

D. FlexCards
Present information from multiple data sources in a configurable, user-friendly interface. A FlexCard can display the combined patient information directly on a patient record page.

Together, these features allow Bloomington Caregivers to integrate patient data and display it in a unified view.

Why the Other Options Are Incorrect

A. Visualforce Pages
Can display custom Salesforce interfaces, but OmniStudio provides a more suitable declarative solution for this requirement.

E. Salesforce Flows
Primarily automate business processes and guide user interactions; they are not the intended combination of tools for this integrated data display scenario.

References

Salesforce Help — OmniStudio for Health Cloud
Describes FlexCards, Integration Procedures, and Data Mappers.

Salesforce Trailhead — Extract External Data with an Integration Procedure
Explains retrieving internal and external data through a single Integration Procedure.

Salesforce Help — Set Up a Data Source on a FlexCard
Explains how FlexCards retrieve data from Salesforce objects and external sources.

Exam Tip
Remember the three components and their roles:
FlexCards = Display data.
Integration Procedures = Orchestrate and combine data sources.
DataRaptors (Data Mappers) = Extract and transform Salesforce data.

Explanation

When implementing Discovery Framework for intake and clinical assessments in Health Cloud, several key out-of-the-box capabilities enhance assessment workflows:

FHIR Question Bank (Option B)
Discovery Framework integrates with standard data models and leverages a repository of health-related questions mapped against FHIR standards to structure clinical assessments cleanly.

Digital Signature Capture (Option C)
Allows patients or clinicians to capture secure, legally binding electronic signatures directly onto the assessment or intake forms.

Using Previously Submitted Responses (Option D)
Enables pre-population or referencing of historical answers from prior assessments for the same patient, reducing redundant data entry and streamlining longitudinal care tracking.

Why the Other Options Are Incorrect

Adding a QR Code (Option A)
This is not a core built-in functional capability directly configured as an out-of-the-box assessment feature within standard Discovery Framework setup.

SMS Assessment Completion (Option E)
This is not a core built-in functional capability directly configured as an out-of-the-box assessment feature within standard Discovery Framework setup.

References
Salesforce Help: Set Up and Configure Discovery Framework in Health Cloud
Salesforce Health Cloud Implementation Guide – Assessments and Intake Workflows

Explanation

Why C Is Correct
A Person Account is both an Account and a Contact record. If the Contact object's org-wide default (OWD) is set to anything other than Controlled by Parent, a user can get access to one half of the record and not the other. Setting Contacts to Controlled by Parent means a user's access to the Account automatically carries over to the Contact side, so they see the entire Person Account record. This is the standard Health Cloud and Person Account sharing recommendation.

Why the Other Options Are Incorrect

A. Set Private for the Contact object.
This makes the Contact half more restrictive than the Account half, which is the mismatch that causes partial access.

B. Set the OWD to Public Read Write for Account.
This overexposes patient data, which is a poor fit for healthcare privacy requirements, and it doesn't address the Contact/Account alignment.

D. Set Modify All on the Account object at the Profile level.
This is a blunt, overly permissive grant. It bypasses sharing entirely and violates the principle of least privilege.

Reference
Person Accounts sharing model, specifically the Contact OWD of Controlled by Parent, in Health Cloud implementation guidance.