Salesforce Certified OmniStudio Developer Practice Test Questions, Exam Dumps

Practice Exams:

View All

Certified OmniStudio Developer Salesforce Practice Test Questions and Exam Dumps

Question 1

A developer is working on an OmniScript that provisions trial orgs for customers. There's a text block in the OmniScript that uses a merge code to show the newly created trial org ID. The current text is as follows:
"Welcome to Salesforce!
Your ID is %Details:Customer|0:ID%"
However, during testing, the developer notices that the ID is not being displayed. The data JSON is structured appropriately to include this value.

What adjustment should the developer make to the merge code so that the ID displays correctly?

A. To %Details:Customer|n:ID%
B. To $Details:Customer|0:ID$
C. To %Details:Customer|1:ID%
D. To %%Details:Customer|0:ID%%

Correct Answer : D

Explanation:

When working with OmniScripts in Salesforce, merge codes are used to inject values from the data JSON into text fields such as text blocks, emails, or script elements. These merge codes follow a specific syntax so the system can accurately locate and render the required value from the structured data.

Let’s first break down the original merge code:
%Details:Customer|0:ID%
This is attempting to access the ID of the first object in the Customer array under Details. That part of the syntax — accessing an array element using the |0: delimiter — is correct. However, the reason it is not rendering the value correctly has to do with merge code delimiters used in OmniScript.

In OmniScripts, merge codes must be enclosed by double percent signs (%%). A single percent sign is insufficient for rendering; instead, it might just display the text as-is, not process it as a merge tag. Therefore, the merge code needs to be written as:
%%Details:Customer|0:ID%%
This tells the system to look into the data JSON, find the Details node, then the Customer array at index 0, and finally extract the ID property.

Let’s now evaluate the other options:

A. %Details:Customer|n:ID%
This is syntactically incorrect. The character n is not a valid index or supported placeholder for accessing array elements in OmniScript merge codes. The system expects numeric indices when targeting elements in an array.
B. $Details:Customer|0:ID$
This uses the wrong delimiter entirely. OmniScript merge codes do not use dollar signs. While other Salesforce tools (like formulas or Apex strings) sometimes use $, OmniScript strictly requires percent signs for merge codes.
C. %Details:Customer|1:ID%
This option assumes the ID is at index 1 in the array. If the data is at index 0 as the original question suggests (Customer|0), then shifting to index 1 will not retrieve the correct data and will likely return undefined or null. Unless there's an explicit reason to fetch the second object in the array, this would be incorrect.
D. %%Details:Customer|0:ID%%
This is the correct and complete syntax. It maintains the accurate path into the JSON and uses the double percent signs required for OmniScript merge tags to render the value properly.

In summary, the issue wasn't in the structure of the path but in the syntax for rendering. Merge codes must be wrapped with double percent signs (e.g., %%...%%) in OmniScript to be recognized and rendered at runtime.

Therefore, the correct answer is: D.

Question 2

A developer is designing an OmniScript and needs to access multiple fields from a Salesforce record in order to use that data within the script.

Which OmniScript element is designed specifically to retrieve data from Salesforce records in this way?

A. Lookup
B. HTTP Action
C. Select
D. DataRaptor Extract Action

Correct Answer : D

Explanation:

When developing OmniScripts in Salesforce (especially within the Salesforce Industries or Vlocity framework), one of the most common tasks is to retrieve and manipulate Salesforce data. This typically involves getting data from Salesforce objects such as Accounts, Contacts, Cases, or custom objects and using that data dynamically in the user interface or process flow.

The correct tool for retrieving multiple fields from Salesforce records in OmniScript is the DataRaptor Extract Action element.

Let’s break down what each of the provided options does and why D is the correct answer.

A. Lookup
The Lookup element in OmniScript is typically used to look up values from static datasets or for cross-referencing picklist values and similar datasets. It is not designed for querying live Salesforce data such as records from the Account or Contact objects. While the name might imply data retrieval, it is limited in scope and not used for full record data pulls from Salesforce. Therefore, A is incorrect.
B. HTTP Action
The HTTP Action element is used to make HTTP requests to external systems or APIs. This is extremely useful for integrations outside of Salesforce, such as calling out to a third-party payment gateway or external database. While technically you could set up a Salesforce REST endpoint and use HTTP Action to retrieve data, this is not best practice when working within Salesforce. For internal Salesforce data access, the platform provides more efficient tools like DataRaptors. So B is not appropriate here.
C. Select
The Select element is a user input control—it creates a dropdown menu that allows the user to choose from a set of values. It does not interact with data sources or retrieve Salesforce records on its own. While it may display values that come from a data source, it is not the element responsible for the data retrieval. As such, C does not meet the requirement described in the question.
D. DataRaptor Extract Action
This is the correct answer. DataRaptors are the key tool in the OmniStudio framework for interacting with Salesforce data. Specifically, the Extract type of DataRaptor is designed to retrieve data from Salesforce objects. You can define a DataRaptor Extract to query a specific Salesforce object, filter it by criteria (e.g., Account ID), and retrieve many fields from the record. The result is structured as JSON and can be mapped into the OmniScript’s Data JSON structure.
By placing a DataRaptor Extract Action element into your OmniScript, you can invoke the configured DataRaptor to run and return data from Salesforce that your OmniScript can use in subsequent steps—whether it's displaying it in UI elements, passing it to another integration, or using it in logic branches.

In summary, although there are multiple elements available for specific purposes in OmniScript, when it comes to retrieving many fields from a Salesforce record, the clear and purpose-built solution is the DataRaptor Extract Action.

Question 3
A developer is building an OmniScript that uses a Type Ahead Block to let users search for and select a contact. The goal is to display the selected contact’s FirstName, LastName, and BirthDate after making a selection. The underlying DataRaptor used in the Type Ahead works correctly and retrieves the correct contact data. However, when previewing the OmniScript, after selecting a contact from the search results, the text fields for FirstName, LastName, and BirthDate remain empty. Based on the scenario and the exhibit,

What is the most likely reason that these fields are not showing the fetched data?

A. Use Data JSON is not selected in the properties of the Type Ahead Block.
B. The Typeahead Key is not in the correct format.
C. Lookup Mode is not selected in the properties of the Type Ahead Block.
D. FirstName, LastName, and BirthDate are not placed inside the Type Ahead Block.

Correct Answer : D

Explanation:

When working with Type Ahead Blocks in OmniScript, the key objective is to allow users to search and select from a dataset (e.g., a list of contacts), and then populate related fields based on the selected record. The most common use case is to search for a contact or account, then display associated information like the contact’s first and last name or other personal details.

Let’s look at how this works under the hood. A Type Ahead Block wraps around UI elements and is linked to a DataRaptor Extract that fetches records matching the user’s input. When a record is selected, its values are mapped to the OmniScript’s Data JSON structure, and any fields inside the Type Ahead Block can be automatically populated using this data.

In this scenario, the developer confirms that the Type Ahead's DataRaptor works and correctly fetches contact data. The issue occurs at the display level, where the expected fields (FirstName, LastName, BirthDate) do not show the selected contact’s information. The root cause is most likely structural — that is, a problem with how fields are arranged within the OmniScript layout.

Let’s evaluate each of the options:

A. Use Data JSON is not selected in the properties of the Type Ahead Block
This setting determines whether to use the data returned from the DataRaptor directly in the OmniScript’s JSON structure. However, in most use cases, this setting is enabled by default or doesn't directly affect whether fields inside the Type Ahead Block get populated. More importantly, if the DataRaptor is returning data and the selection is recognized, the issue lies elsewhere. So this is not the best explanation.
B. The Typeahead Key is not in the correct format
The Typeahead Key is used to display the search label (e.g., showing the full name in the dropdown results). If the key format were wrong, the search or display in the dropdown might fail, but that would not prevent the fields from being populated once a record is selected. So while this could cause issues with the dropdown list, it doesn't directly relate to the failure of populating fields.
C. Lookup Mode is not selected in the properties of the Type Ahead Block
Lookup Mode is used to control behavior for searching records, but like Option B, it typically affects the behavior of the search interaction, not the binding or display of selected values in UI fields. If the search works and the developer can select a contact, Lookup Mode is likely functioning correctly. Therefore, this is not the root cause of the field population issue.
D. FirstName, LastName, and BirthDate are not placed inside the Type Ahead Block
This is the correct answer. OmniScript depends on component hierarchy and data binding. Fields that are meant to be auto-populated from the selected Type Ahead result must be placed inside the Type Ahead Block. If they are placed outside, they won't be automatically linked to the selected result’s data structure in the Data JSON. As a result, even though the data is fetched and the contact is selected, the fields remain blank because they are not bound to the selected record’s data.

To summarize:

Type Ahead Blocks fetch and return a record's data.
Fields that should receive and display this data must be within the block so they inherit the data path.
If the fields are placed outside, no automatic data mapping occurs.

Therefore, based on this functionality and the described behavior, the most accurate explanation is that the fields are not inside the Type Ahead Block, which is why they fail to receive and display the selected record’s data.

The correct answer is: D.

Question 4

An OmniScript is designed to display data retrieved through an Integration Procedure that connects to an external API. However, when previewing or using the OmniScript, no data appears—all expected data from the API is missing.

Which two issues could explain this behavior? (Choose two.)

A. The API url is not allowlisted in Salesforce.
B. The JSON sent from the Integration Procedure Action does not match any of the Original Input for the Integration Procedure.
C. The OmniScript has no active version.
D. The Integration Procedure Preview Input Parameters do not match the JSON sent from the OmniScript.

Correct Answer : A, D

Explanation:

In Salesforce OmniStudio (formerly Vlocity), OmniScripts often depend on Integration Procedures (IPs) to retrieve or transform data—especially when dealing with APIs or backend services. If your OmniScript is not showing any data returned from the API via the Integration Procedure, the issue could lie in several places: platform security configurations, data mapping, or version control.

Let’s analyze each answer choice carefully and identify which two are most likely to cause all API data to be missing.

A. The API url is not allowlisted in Salesforce
This is correct. Salesforce enforces security controls that prevent unauthorized or unapproved external calls. If an Integration Procedure calls an external API, the destination URL must be explicitly allowlisted in Salesforce’s Remote Site Settings (for synchronous calls via HTTP) or Named Credentials (for more secure, token-based calls).
If the API is not allowlisted, the call will be blocked, and the Integration Procedure will receive no data—leading to the OmniScript rendering with missing data. No error might even display in the UI unless proper error handling is implemented.
B. The JSON sent from the Integration Procedure Action does not match any of the Original Input for the Integration Procedure
This is incorrect. While a mismatch in JSON structure can lead to data not being retrieved or processed correctly, this specific option misstates how Integration Procedures function. Integration Procedures are designed to accept flexible input, and they do not require the Original Input to be matched exactly. The Original Input is mostly for documentation and testing in the IP designer, not for strict matching in runtime operations. A mismatch may affect logic within the IP (e.g., filters or conditions), but it would not completely block the data unless misconfigured internally.
C. The OmniScript has no active version
This is incorrect. If an OmniScript has no active version, it simply cannot be deployed or previewed at all. The user would receive an error like “OmniScript has no active version” or would be unable to access the script entirely. However, in the scenario, the OmniScript does load, but data is missing—this implies that the script is active and deployed, but the backend data isn't making it through.
D. The Integration Procedure Preview Input Parameters do not match the JSON sent from the OmniScript
This is correct. Integration Procedures often contain logic elements like DataRaptors, Conditional Actions, or Response Transforms that rely on input parameters to function correctly. If the OmniScript sends a JSON structure that doesn't match what the Integration Procedure expects (e.g., missing required keys, incorrect nesting), the procedure may execute incompletely or return no data at all.
Even if the procedure technically runs, if it doesn’t receive the correct input, none of its branches may execute, and the Response could be empty—leading to the OmniScript appearing to load with no data.

Summary of correct answers:

A is correct because external APIs must be allowlisted, or Salesforce will block the request entirely.
D is correct because mismatched JSON inputs from the OmniScript to the Integration Procedure can cause it to return no data if required input is missing or malformed.

Therefore, the correct answers are: A, D.

Question 5

An Integration Procedure includes an HTTP action that performs a REST API call and receives a JSON response. This response must be transformed into a specific XML format before being passed as input to another external web service.

How should the developer configure the Integration Procedure to accomplish this transformation?

A. Use a DataRaptor Transform to convert JSON to XML
B. Use a Remote Action that calls the XMLStreamReader class
C. Use a DataRaptor Extract and check the XML checkbox on the Output JSON Path
D. Use a Remote Action that calls the XMLStreamWriter class

Correct Answer : D

Explanation:

When building Integration Procedures in Salesforce OmniStudio, developers often have to interact with multiple external systems using different data formats. REST APIs typically return data in JSON, while older systems or certain enterprise platforms may require input in XML format. This requires a conversion step between JSON and XML.

In this case, the Integration Procedure receives a JSON response from a REST API and must convert it into a specific XML structure before sending it to a second external web service. To achieve this, a transformation process that outputs XML must be inserted between the HTTP action and the next external call.

Let’s analyze each answer choice in detail:

A. Use a DataRaptor Transform to convert JSON to XML
This is incorrect. While DataRaptor Transforms are powerful tools for data mapping, their primary function is to transform JSON to JSON within Salesforce. OmniStudio’s native DataRaptor Transform does not support XML output. It cannot directly convert JSON to XML, nor can it format data to match complex XML schemas required by external systems. Therefore, this option would not fulfill the XML transformation requirement.
B. Use a Remote Action that calls the XMLStreamReader class
This is also incorrect. The XMLStreamReader class is used to read or parse XML data, not generate it. In this scenario, the goal is to convert JSON to XML, not to read XML data. This class is typically used when ingesting XML into Salesforce, not when preparing it to be sent out. Thus, this tool would be useful in a different use case — reading XML responses — but not for generating XML.
C. Use a DataRaptor Extract and check the XML checkbox on the Output JSON Path
This is incorrect and based on a misunderstanding. DataRaptor Extracts are used to pull data from Salesforce objects and return it in JSON format. There is no “XML checkbox” on the Output JSON Path settings. Even if such an option existed, DataRaptors do not support output in native XML format. Their core design is to extract Salesforce data into JSON structures. Therefore, this method would not help in creating an XML payload.
D. Use a Remote Action that calls the XMLStreamWriter class
This is the correct answer. The XMLStreamWriter class allows developers to programmatically generate well-structured XML documents. A Remote Action in OmniStudio enables you to execute custom Apex code, where you can implement the logic to construct the XML using XMLStreamWriter. This gives full control over the XML format, allowing you to meet strict schema requirements from external web services.

In the Integration Procedure:

The HTTP Action fetches the initial data in JSON.
A Remote Action is added next in the IP flow.
The Remote Action invokes an Apex class/method where XMLStreamWriter is used to map the JSON data into the required XML structure.
The resulting XML is then sent to the second external service via another HTTP Action.

Using XMLStreamWriter ensures precision, flexibility, and compliance with strict XML formatting needs, which no native OmniStudio element currently provides.

When you need to convert JSON to a specific XML structure within an Integration Procedure, the only reliable way is to write custom logic using XMLStreamWriter inside a Remote Action.

Therefore, the correct answer is: D.

Question 6
A developer has built a FlexCard that includes five states. Four of those states have conditions attached to them. During testing, sample data is used that results in two of those state conditions evaluating to true. Given this situation,

How can the developer determine which of the matching states will actually be displayed in the FlexCard?

A. The first state with a true nested condition, regardless of sequence in the FlexCard canvas, will display.
B. The first state with true conditions sequenced closest to the top of the FlexCard canvas will display.
C. The first state with a true AND condition, regardless of sequence in the FlexCard canvas, will display.
D. The state sequenced first in the FlexCard canvas will display.

Correct Answer : B

Explanation:

FlexCards, a core component of Salesforce OmniStudio, are UI building blocks designed to present summarized information. A single FlexCard can contain multiple states, and each state can be configured to show under certain conditions using conditional logic. This gives developers the flexibility to render different content or layouts based on the context of the data being presented.

In this question, the developer has created five states in a FlexCard. Four of those states have conditional logic, and when test data is used, two of the state conditions evaluate to true. The key question here is: how does the FlexCard determine which of the multiple true-condition states to display?

Let’s understand how FlexCard state evaluation works.

How State Rendering Works in FlexCards:

When multiple states exist in a FlexCard:

Each state is evaluated in the order it appears (from top to bottom) on the FlexCard canvas.
Once a true condition is found, the FlexCard will stop evaluating further states and render only the first matching state.
Even if more than one state's condition evaluates to true, only the first (in sequence) is displayed.
If no conditions are true, then the default state (usually the one with no condition) is displayed.

Let’s break down each option:

A. The first state with a true nested condition, regardless of sequence in the FlexCard canvas, will display.
This is incorrect. While nested conditions may exist within a state's logic, the FlexCard engine does not prioritize "nested conditions" over others. It uses a linear, top-down sequence and evaluates the condition as a whole. The sequence in the FlexCard canvas still determines which is selected first.
B. The first state with true conditions sequenced closest to the top of the FlexCard canvas will display.
This is correct. FlexCard state evaluation follows a top-down approach. When more than one state’s condition evaluates to true, the FlexCard renders the first matching state as ordered in the canvas. This allows developers to control state precedence by positioning the most specific or preferred state higher in the sequence.
C. The first state with a true AND condition, regardless of sequence in the FlexCard canvas, will display.
This is incorrect. The FlexCard does not prioritize conditions based on logical operators such as AND or OR. It only cares whether the entire condition evaluates to true, and it picks the first one (in order) that does so. The presence of an AND condition does not give that state any higher priority.
D. The state sequenced first in the FlexCard canvas will display.
This is partially true, but it misses a critical point: only if its condition is true. If the first state has no condition or the condition is false, it will be skipped. The system doesn't default to the first state unless no other conditionally valid states are found. So while order is important, it’s only relevant among states with true conditions.

FlexCard condition evaluation is linear and strictly follows the sequence defined in the FlexCard canvas. This allows developers to control state precedence by moving more important or likely states to the top. Once a condition evaluates to true, the FlexCard will stop evaluating further states and render that one. This behavior ensures performance and clarity in which state appears.

Therefore, the correct answer is: B.

Question 7

A developer is creating a DataRaptor Load that will be used in an Integration Procedure supporting an OmniScript. According to best practices,

How should the developer configure the Input JSON to ensure compatibility and minimize errors?

A. Build the Input JSON node by node in an editor.
B. Build the Input JSON node by node in the DataRaptor Designer.
C. Copy the Input JSON from the OmniScript {Data} modal.
D. Copy the Input JSON from the DataRaptor Action Debug node.

Correct Answer : C

Explanation:

When building a DataRaptor Load that will be used within an Integration Procedure (IP), and that IP is itself called by an OmniScript, it's critically important that the Input JSON structures align properly across all components. Mismatches between JSON formats can lead to mapping failures, data not being loaded, or runtime errors. That’s why following best practices for setting up your input JSON is essential.

Let’s look at each option and identify the one that aligns best with established development guidelines for OmniStudio/Vlocity DataRaptors.

A. Build the Input JSON node by node in an editor
This is not recommended. Manually creating the JSON structure "node by node" in a general-purpose editor like Notepad or VS Code is prone to human error. You might mislabel keys, forget nesting levels, or miss a required field. This method doesn't leverage the existing working data structure already being generated by the OmniScript and is thus inefficient and error-prone.
B. Build the Input JSON node by node in the DataRaptor Designer
Although the DataRaptor Designer has a JSON input panel, this approach still involves manually constructing the JSON structure, which introduces the same risk of human error as in option A. Additionally, the Designer doesn't "know" what the OmniScript is sending, so any guesswork about structure, field names, or nesting could result in mismatches. While this tool is useful for testing once JSON is available, it's not the best starting point.
C. Copy the Input JSON from the OmniScript {Data} modal
This is the correct and recommended best practice. When you preview or run the OmniScript, you can open the {Data} modal, which shows the actual JSON structure that the OmniScript is sending at runtime. This structure reflects all user input, merge fields, and intermediate values collected up to that point.
By copying the JSON from here:

You ensure that the structure passed to the Integration Procedure is exactly what the DataRaptor Load will receive.
You avoid issues with incorrect node names or nesting.
You get a real-time, accurate snapshot of the data context.

This approach dramatically reduces the chance of mapping errors and makes it much easier to build your Input JSON Paths correctly inside the DataRaptor Load.
D. Copy the Input JSON from the DataRaptor Action Debug node
This is useful for debugging after the DataRaptor has already been run, but it’s not ideal for initial setup. The Debug node shows what was actually passed in a previous run, and while that might help troubleshoot, it's less reliable than copying directly from the OmniScript’s runtime data context. Also, it requires that you've already wired everything together and successfully executed the action once, which might not be possible early in development.

The best practice is to build your Input JSON for a DataRaptor Load using the exact JSON structure the OmniScript is sending, and the most accurate way to obtain that structure is from the OmniScript’s {Data} modal during a preview or test run. This ensures compatibility across components, avoids mapping errors, and aligns with Salesforce’s recommended development process.

Therefore, the correct answer is: C.

Question 8

A developer has built a DataRaptor Load that correctly inserts Contact records using firstName and lastName as inputs. The DataRaptor works when previewed on its own. The developer then integrates it into an Integration Procedure, where a Set Values element is used to provide those inputs. However, when previewing the Integration Procedure, an error appears: “Required fields are missing: [Last Name]”.

What should the developer do to fix the issue?

A. SetValuesContactDetails should have been added to Additional Input of DataRaptor Post Action in Integration Procedure
B. The Set Values Action keys should include the DataRaptor Post Action element name path, e.g. LoadContactDetails:lastname
C. The DataRaptor Post Action in the Integration Procedure should have been executed before the Set Values Action
D. The valid field names should be added in the Domain Object Field in the DataRaptor

Correct Answer : A

Explanation:

This question addresses a common configuration issue when integrating DataRaptor Load actions within Integration Procedures (IPs), particularly when using Set Values to define input values dynamically before passing them into a DataRaptor. The fact that the DataRaptor works when previewed independently confirms that the issue lies not with the DataRaptor, but with how it is being invoked and fed data inside the Integration Procedure.

Let’s examine the situation step-by-step and then analyze each option.

What’s happening?

The DataRaptor Load is configured correctly and expects two inputs: firstName and lastName.
In the Integration Procedure, a Set Values element is used to set these two fields.
The DataRaptor Post Action is used to insert the contact.
When executing the Integration Procedure, an error occurs:
“Required fields are missing: [Last Name]”

This error indicates that the DataRaptor is not receiving the lastName value when invoked through the Integration Procedure. This typically means that the value defined in the Set Values element is not being passed properly into the DataRaptor Post Action.

How Data Passing Works in Integration Procedures:

To pass values from one element (like Set Values) to another (like a DataRaptor Post Action), the Integration Procedure must explicitly map or link the data. This is done using the “Additional Input” section of the DataRaptor Post Action element, where you define what part of the Integration Procedure’s data should be used as input.

Now let’s break down the answer choices:

A. SetValuesContactDetails should have been added to Additional Input of DataRaptor Post Action in Integration Procedure
This is correct. In Integration Procedures, the Set Values element populates a section of the JSON (e.g., SetValuesContactDetails). To pass this JSON node into the DataRaptor, you must go to the DataRaptor Post Action, open the "Additional Input" section, and add a mapping like:
Input Path: SetValuesContactDetails

JSON Node: (leave blank or set according to how the DR expects input)

Without this mapping, the DataRaptor Post Action won’t receive any values from Set Values, which leads to the error about the missing lastName. Therefore, this is the correct fix.
B. The Set Values Action keys should include the DataRaptor Post Action element name path, e.g., LoadContactDetails:lastname
This is incorrect. Set Values does not need to (and should not) reference the name of downstream elements. Instead, the Integration Procedure allows upstream elements (like Set Values) to define data that is then passed into other elements via Input Parameters or Additional Input. There is no benefit or functionality to prefixing keys with another element's name in this context.
C. The DataRaptor Post Action in the Integration Procedure should have been executed before the Set Values Action
This is incorrect. The execution order in Integration Procedures is top-down, meaning the Set Values must come before the DataRaptor Post Action so that the values are available to pass. Reversing this order would not help—it would prevent the values from being set in time.
D. The valid field names should be added in the Domain Object Field in the DataRaptor
This is unrelated. The Domain Object Field is used to help configure object mappings within the DataRaptor Designer, but it does not control data passing between an Integration Procedure and the DataRaptor. Moreover, the DataRaptor already works independently, which confirms it’s not a problem with the DataRaptor’s internal field configuration.

The problem arises because the Integration Procedure is not passing the Set Values output into the DataRaptor Post Action. To fix this, the developer must go to the DataRaptor Post Action, find the "Additional Input" section, and add the correct reference to the Set Values node. This ensures the DataRaptor receives the necessary input fields like lastName.

Therefore, the correct answer is: A.

Question 9

A developer needs to display the following information together on one FlexCard: account name, address, phone number, website, primary contact first name, contact last name, address, phone number, email. The account information must always be visible, and the contact information should only be visible as needed by the user.

What is the best approach to display the contact information on the card?

A. Set the collapsible property on the block element
B. Use a Datatable element
C. Use a conditional FlexCard State
D. Set the class="collapsible" on the block element

Correct Answer : A

Explanation:

In this scenario, the developer needs to display both account and contact information on the same FlexCard but with different visibility rules. The account information must be always visible, while the contact information should only be visible as needed by the user, typically based on user interaction (e.g., clicking or expanding the contact section). Let's break down each option to determine the best solution.

How FlexCards Work:

A FlexCard is a visual component in Salesforce used to present key data in a flexible and interactive layout. It can display multiple states or blocks of information, with each state or block having conditional visibility based on factors like user interaction or data values.

In this case, we need a solution that allows contact information to be hidden initially but expandable upon user interaction, while account information remains visible.

Explanation of Options:

A. Set the collapsible property on the block element
This is correct. The collapsible property is specifically designed to meet this use case. By setting this property on a block (e.g., a block containing contact information), the contact section can be initially hidden. Users can then expand or collapse this section based on their needs. This ensures that the account information remains visible at all times, while the contact details can be revealed when necessary. This approach is simple and effective for the requirements described.
B. Use a Datatable element
This is incorrect. A Datatable element is typically used for displaying multiple records in a grid-like format, which doesn't align with the need to toggle visibility of a single section (the contact information). A datatable would be overkill for this use case, as it doesn't provide the expand/collapse functionality needed here. Additionally, it's not designed for controlling visibility of individual blocks on the FlexCard.
C. Use a conditional FlexCard State
This is partially correct but not ideal. While conditional states can change the layout or the information shown based on certain conditions, it would require more complex logic to implement toggle behavior for the contact section. You'd need to add conditions to determine when to show the contact block, which could complicate the design. Using a collapsible block is a simpler solution.
D. Set the class="collapsible" on the block element
This option is incorrect because class="collapsible" is not the recommended or standard way to create collapsible sections in FlexCards. Salesforce uses the collapsible property (as mentioned in option A) rather than relying on raw CSS classes for such functionality. Therefore, this approach wouldn't work without additional customization.

Best Approach:

The collapsible property on a block element is the most simple and effective way to meet the requirements: ensuring that the account information is always visible and that the contact information is only shown when needed. This provides a seamless user experience where the user can easily toggle visibility without complicating the FlexCard’s logic or design.

Therefore, the correct answer is: A.

Question 10

Which two fields in an Integration Procedure can use a function like CONCAT or DATEDIFF? (Choose two.)

A. In Procedure Configuration, in a Tracking Custom Data value field.
B. In a Response Action, in an Additional Input value field.
C. In a Remote Action, in an Additional Output value field.
D. In a Remote Action, In a Remote Options value field.

Correct Answer : B, C

Explanation:

Integration Procedures in Salesforce are designed to allow developers to execute complex logic and integrate multiple systems or services. These procedures allow the use of functions such as CONCAT (to combine strings) and DATEDIFF (to calculate the difference between two dates). These functions are used within specific fields in the Integration Procedure where data transformation is necessary.

Let’s break down each option to understand where these functions can be used:

A. In Procedure Configuration, in a Tracking Custom Data value field

This is incorrect. Tracking Custom Data is used to capture data specific to tracking the execution of the procedure, but it doesn't perform data transformations or complex operations like CONCAT or DATEDIFF. Functions like these are typically used where the data is actively manipulated or passed between components, not just for tracking purposes.

B. In a Response Action, in an Additional Input value field

This is correct. In Response Actions, which are part of the Integration Procedure, the Additional Input field is often used to pass data from the Integration Procedure into another system or service. In these fields, you can use functions like CONCAT to combine multiple input values or DATEDIFF to calculate differences between dates, as long as they are part of the data transformation logic. The Additional Input fields allow for data manipulation to format and pass the right information.

C. In a Remote Action, in an Additional Output value field

This is correct. The Additional Output field in a Remote Action can also use functions like CONCAT or DATEDIFF. Remote Actions are used to invoke external services or APIs, and the output of these actions can be transformed using functions to meet the specific needs of the Integration Procedure. These functions can be applied to the data in the Additional Output fields to ensure the output data is correctly formatted or calculated before it is passed back into the Integration Procedure or sent to another service.

D. In a Remote Action, In a Remote Options value field

This is incorrect. Remote Options typically deal with configuration options or settings required by the Remote Action (such as endpoint URLs or authentication credentials). These fields are not meant for data manipulation or applying functions like CONCAT or DATEDIFF. Functions are usually applied to data fields that represent the actual data being processed, not configuration options.

Functions like CONCAT and DATEDIFF are used in data transformation or manipulation within the Additional Input and Additional Output fields of Response Actions and Remote Actions. These fields allow for the necessary computation or formatting before sending data to external systems or further processing.

Therefore, the correct answers are: B and C.