DEX-403 Practice Questions

A Roll-Up Summary Field (RUSF) on a master object cannot reference a formula field on the detail object if that formula has certain characteristics. Specifically, a formula field is ineligible for roll-up aggregation if it includes a cross-object field reference (i.e., it references fields on an object other than the detail record itself). This is because the roll-up calculation is confined to the master-detail relationship.

Furthermore, formula fields that use dynamic date/time functions, such as NOW() or TODAY(), are also prohibited. The values from these functions change automatically over time without a DML event on the record, which is incompatible with the trigger-based recalculation mechanism of RUSFs.

A. A cross-object workflow updating a source field does not inherently disqualify the formula. The validity depends on the formula's content, not how its inputs are updated.

C. The CASE() function is a standard logical function used for conditional logic and is fully supported in formula fields that are eligible for roll-up summaries.

1. Salesforce Help Documentation, "Roll-Up Summary Field": Under the section "Notes on creating roll-up summary fields," the documentation explicitly states, "You can't use...cross-object formula fields...in the field to be aggregated column." This directly supports option B.

2. Salesforce Help Documentation, "Considerations for Roll-Up Summary Fields": This document clarifies the limitations, stating, "A roll-up summary field can’t reference a formula field that references a dynamic date function, such as DATEVALUE, NOW, or TODAY." This directly supports option D.

3. Salesforce Help Documentation, "Formula Operators and Functions": The description for the NOW() function explains that it returns the current date and time, which is a dynamically changing value. This inherent volatility is the reason it cannot be used in RUSFs, which require a stable value that only changes upon a record save.

The fundamental principle of Salesforce's record-level security model is to start with the most restrictive setting and then grant wider access as needed. The requirement that VIP Accounts are only readable by their owners dictates that the Organization-Wide Default (OWD) for the Account object must be set to 'Private'. This action establishes the most restrictive baseline.

Once the OWD is Private, all accounts become visible only to their owners. To fulfill the second requirement—making non-VIP accounts readable by all users—a criteria-based sharing rule must be created. This rule will identify all accounts that are not marked as VIP and grant read-only access to a public group that includes all users.

B. Configure a permission set.

Permission sets grant object-level permissions (e.g., the ability to read Accounts) but do not control which specific records a user can see.

C. Set up an Account Team.

Account Teams are used to grant additional access to a single Account for a specific group of users, not for applying a broad access rule to all non-VIP accounts.

1. Salesforce Help Documentation, "Organization-Wide Sharing Defaults": This document states, "Organization-wide sharing settings specify the default level of access that users have to each others’ records... For the most restrictive access, set the default to Private." This supports the necessity of changing the OWD to 'Private' (Option D) to meet the VIP account requirement.

2. Salesforce Help Documentation, "Sharing Rules": This resource explains, "Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules give particular users greater access by making automatic exceptions to your org-wide sharing settings." This directly supports using a sharing rule (Option A) to open up access for non-VIP accounts after the OWD has been restricted.

3. Trailhead, "Data Security" Module, "Control Access to Records" Unit: This module outlines the record access control hierarchy, emphasizing that OWDs are the first and most critical step. It clarifies that after setting a restrictive OWD, you use tools like sharing rules to grant wider access based on specific criteria, which is the exact pattern required by the scenario.

Web-to-Case is the standard Salesforce feature designed specifically to address this requirement. It generates an HTML form that can be embedded directly into a public-facing website. When a visitor submits the form, a new case record is automatically created in the Salesforce org. This provides a simple, declarative way to capture customer support requests from a website without requiring visitors to log in.

A. Outbound message: This is an integration tool used to send information from Salesforce to an external system when a record is created or updated, not to capture information from a website.

C. Screen flow: While a screen flow can be exposed on a website (e.g., via an Experience Cloud site), it is a more complex solution. Web-to-Case is the purpose-built, simpler feature for this specific use case.

D. Email-to-case: This feature creates cases from inbound emails sent to a designated address. It does not involve a form on a public website for case submission.

1. Salesforce Help: Set Up Web-to-Case.

Quote: "Gather customer support requests directly from your company’s website and automatically generate new cases with Web-to-Case."

Section: "Web-to-Case"

2. Salesforce Help: Web-to-Case Guidelines and Limitations.

Quote: "Web-to-Case lets you capture cases from your own website... Salesforce creates a case and prepopulates the case fields using the information your customer entered."

Section: "Web-to-Case Guidelines and Limitations"

3. Salesforce Help: Email-to-Case.

Quote: "Email-to-Case... automatically create cases and auto-populate case fields when customers send messages to the email addresses you specify."

Section: "Email-to-Case"

4. Salesforce Help: Outbound Messages.

Quote: "An outbound message sends information to a designated endpoint, like an external service. Outbound messages are configured in Setup."

Section: "Outbound Messages"

A namespace is a unique, globally-recognized identifier that is automatically prepended to all components within a managed package (e.g., namespaceMyCustomObjectc). Its primary function is to ensure that the package's components are distinct from any customizations in a subscriber's organization or components from other packages. This prevents naming collisions and conflicts, which is essential for the package to be installed and upgraded reliably across different Salesforce orgs. Using a namespace is a mandatory step for creating a managed package for distribution.

A. Description: This is a text field used for informational purposes to describe the package's contents and has no functional role in preventing component conflicts.

B. Allow sharing: This setting relates to granting programmatic access to Apex classes within the package via Apex sharing rules, not preventing component name conflicts.

C. Help setting: This feature allows a developer to specify a URL for a custom help page for the package, which aids users but does not resolve technical conflicts.

1. Salesforce AppExchange Partner Documentation, ISVforce Guide: In the "About Namespaces" section, it states, "A namespace makes your managed package’s components distinct from the components of any other package or any customizations in a subscriber’s org... Without a namespace, you can’t upload a managed package." (See Chapter: "Architect Your Solution", Section: "Develop Your App", Subsection: "About Namespaces").

2. Salesforce Help & Training, Register a Namespace Prefix: "A namespace prefix is a globally unique, 1 to 15-character alphanumeric identifier that distinguishes your package and its contents from other packages in your customer's org... The namespace prefix is automatically prepended to all components in your managed package."

3. Apex Developer Guide: In the section "Namespaces and Managed Packages," it clarifies, "All your custom objects, fields, Apex code, and so on, are associated with your namespace... This prevents conflicts between your components and customer components." (See Chapter 2: "Writing Apex", Section: "Namespaces and Managed Packages").

The core requirement is to archive large data volumes to reduce Salesforce data storage while retaining the ability to report, query, and look up the archived information.

Big Objects are a native Salesforce solution designed specifically for storing and managing massive datasets (billions of records) on the platform. Data stored in Big Objects does not count against the organization's standard data storage limits, directly addressing the storage issue. They are accessible via Async SOQL for queries and can be included in custom UIs, fulfilling the accessibility requirement for large-scale data.

External Objects, via Salesforce Connect, allow data to be stored in an external system (e.g., Heroku Postgres, AWS). This data does not consume Salesforce storage. However, it remains seamlessly accessible within the Salesforce UI for reports, global search, SOQL queries, and lookups, behaving much like a standard custom object.

B. Custom objects: Storing archived data in another custom object would still consume the same standard data storage, failing to solve the problem of nearing storage limits.

C. Related objects: This is a general term describing an object's relationship, not a specific storage type or archiving solution that would reduce data storage consumption.

1. Salesforce Developer Documentation, Big Objects Implementation Guide, "Get Started with Big Objects": "Use Big Objects to store and manage a massive amount of data on the Salesforce platform. You can archive data from other objects or bring in massive datasets from outside systems... Big object data doesn’t count against your org’s data storage limits." This source confirms that Big Objects are intended for archiving and do not consume standard storage.

2. Salesforce Help, Salesforce Connect, "Salesforce Connect": "Salesforce Connect is a framework that enables your users to view, search, and modify data that’s stored outside your Salesforce org... Instead of copying the data into your org, external objects let you access the data in real time... The external data isn’t stored in Salesforce, so Salesforce Connect doesn’t consume your org’s storage." This source validates that External Objects use external storage while remaining accessible.

3. Salesforce Help, Reports, "Report on External Object Data": "When you create a report that includes an external object, Salesforce runs a search query on the external system. The results are reflected in the report." This confirms the reporting capability of External Objects.

4. Salesforce Developer Documentation, SOQL and SOSL Reference, "Querying Big Objects": "You can query big objects using SOQL or Async SOQL... Use Async SOQL to run queries on big objects." This confirms the query capability for Big Objects, which is essential for the requirement.

To allow users to approve or reject records directly from their Chatter feed, a system administrator or app builder must enable this functionality globally. This is accomplished by navigating to the Chatter Settings page in Setup and selecting the "Allow Approvals" checkbox. Once enabled, approval requests for which the user is an approver will appear as posts in their Chatter feed, allowing them to take action directly from the feed, which is ideal for mobile users.

A. Chatter Feed Tracking: This feature is used to post automatic updates to a record's Chatter feed when specific fields are changed, not to enable approval actions.

B. Object Settings: Object settings manage configurations specific to an object, such as fields and page layouts, but do not control the global integration of approvals into Chatter.

D. Approval Process Settings: This area is for configuring the logic of a specific approval process (e.g., entry criteria, steps, actions), not for enabling the Chatter user interface for all approvals.

1. Salesforce Help, Article: Let Users Approve or Reject Records from Chatter.

Reference: The article explicitly states the required steps: "From Setup, enter Chatter in the Quick Find box, then select Chatter Settings. Select Allow Approvals." This directly confirms that the setting is located in Chatter Settings.

2. Salesforce Help, Article: Considerations for Approvals in Chatter.

Reference: This document outlines the prerequisites and behavior of the feature, reinforcing that it's a global setting. It notes, "To let users approve records in Chatter, enable approvals in Chatter on the Chatter Settings page in Setup."

An Apex before delete trigger is the correct and most robust solution among the choices provided. This trigger executes before a record is deleted from the database. A developer can write logic within this trigger to query for any related Opportunity records where the IsClosed field is false. If the query returns one or more records, the trigger can use the .addError() method on the Account record being deleted. This action cancels the deletion operation and displays a custom error message to the user, effectively enforcing the business rule regardless of whether the deletion was initiated from the UI, a list view, or an API call.

B. Create a validation rule on the Account object.

Validation rules are designed to enforce data integrity during record creation and updates (save operations). They do not execute when a record is deleted.

C. Remove the delete button on the account layout.

This is a superficial UI change. It does not prevent users from deleting records through other means, such as from list views, reports, or via API tools.

D. Remove the Delete permission from the Sales Rep profile.

This is an incorrect solution because the scenario states the Sales Operations team deletes accounts. Furthermore, it is not conditional; it would prevent deletion of all accounts, not just those with open opportunities.

References:

1. Apex Developer Guide - Triggers: The official guide explicitly describes the use case for before delete triggers. It states, "You can use triggers to perform tasks that can’t be done by using the point-and-click tools in the Salesforce user interface... For example... preventing the deletion of a record if it’s in a certain state." The .addError() method is the standard mechanism to prevent a DML operation within a trigger.

Reference: Salesforce Apex Developer Guide, "Trigger Syntax" and "Trigger Context Variables" sections.

2. Salesforce Help - Triggers and Order of Execution: The official documentation on the order of execution for DML operations clearly shows that validation rules are part of the "save" procedure but are NOT part of the "delete" procedure. The delete procedure involves before delete and after delete triggers, but no validation rules.

Reference: Salesforce Help, Article ID 000323235, "Triggers and Order of Execution".

3. Salesforce Help - Validation Rules: This documentation defines the purpose of validation rules. It states, "Validation rules verify that the data a user enters in a record meets the standards you specify before the user can save the record." This confirms their scope is limited to insert and update operations.

Reference: Salesforce Help, Article ID 000328373, "Validation Rules".

4. Salesforce Security Guide - Object Permissions: This guide details how object-level permissions work. The "Delete" permission is a blanket control for an object and does not allow for the record-level conditional logic required by the scenario.

Reference: Salesforce Security Guide, "Object Permissions" section.

The core requirement is to perform an "upsert" operation: insert new records and update existing ones based on a key from an external system. The standard Salesforce mechanism for this is to use a field with the "External ID" attribute. This attribute designates a field as a unique record identifier from a system outside of Salesforce.

Data Loader is the appropriate tool for regular data integration tasks, as it is specifically designed to use an External ID field to match records and perform upsert operations efficiently. This combination directly prevents duplicate record creation while ensuring existing records are correctly updated.

A. Use the Import Wizard and match on the tracking number.

The Import Wizard is less suitable for regular, automated data pushes from an application compared to Data Loader. While it can match on an External ID, Data Loader is the more robust tool for this integration scenario.

C. Use the Import Wizard and match on the Salesforce ID.

The external shipping application would not have the Salesforce Record ID for new records, making it impossible to use this ID as the matching key for an upsert operation that includes creating new records.

D. Create a duplicate match rule and use Dataloader.

A duplicate rule is designed to block or report the creation of duplicate records. It does not facilitate the "update" part of the requirement; it would simply cause the data load to fail for existing records, not update them.

1. Salesforce Help & Training - Upsert Records: "Upsert combines insert and update into a single call. Upsert uses a record's ID or an external ID field to determine whether to create a new record or update an existing one." This document explicitly links the upsert operation with an External ID.

Source: Salesforce Developer Documentation, Bulk API Developer Guide, "Upsert Records".

2. Salesforce Help & Training - Data Loader Guide: "Use the upsert operation to both insert and update records at the same time. To use this operation, you need to specify an external ID field or the ID field to be used for matching."

Source: Salesforce Help, Data Loader Guide, "Insert, Update, or Delete Data Using Data Loader".

3. Salesforce Help & Training - Prepare Your Data for Import: "External ID: This is a custom field that has the External ID attribute, meaning that it contains unique record identifiers from a system outside of Salesforce."

Source: Salesforce Help, Salesforce Help, "Prepare Your Data for Import".

Validation rules are the ideal declarative solution for this scenario. They can enforce complex business logic without code. To prevent a case status from reverting, a validation rule can use the PRIORVALUE() function to compare the field's previous value with the new one. To make fields conditionally required, a validation rule formula can check for specific criteria (e.g., ISPICKVAL(Status, "Closed")) and then ensure another field is not blank (e.g., ISBLANK(ResolutionNotesc)). This directly addresses both of the stated requirements in a single, efficient feature.

B. Create dependent picklist fields and set them as required.

This only controls the available values of one picklist based on another and cannot prevent status reversion or enforce requirements on non-picklist fields.

C. Use an approval process to check field criteria are met.

Approval processes are for formal record submission and locking, not for enforcing data integrity rules during routine editing across the entire case lifecycle.

D. Make the fields required on the page layout.

This makes a field universally required for all records using that layout, failing to meet the requirement for fields to be required only when specific criteria are met.

---

1. Salesforce Help Documentation, "Validation Rules":

Content: "Validation rules verify that the data a user enters in a record meets the standards you specify before the user can save the record... For example, you can have a validation rule that requires a user to enter a justification if they change an opportunity's amount by more than 10%." This supports the principle of conditional field requirements.

Reference: Salesforce Help, Article ID 000328373, "Validation Rules".

2. Salesforce Help Documentation, "Formula Operators and Functions":

Content: The PRIORVALUE(field) function is explicitly defined: "Use this function to compare a field’s value to its previous value." This is the specific mechanism required to prevent a case status from reverting to an earlier stage.

Reference: Salesforce Help, Article ID 000323229, "Formula Operators and Functions P–Z", Section: PRIORVALUE.

3. Salesforce Help Documentation, "Examples of Validation Rules":

Content: This document provides multiple examples that directly map to the requirements. For instance, the section "Enforcing a value in a field based on the value of another field" shows how to make a field required conditionally. The logic can be adapted to prevent status reversion, such as CASE(Status, "New",1,"Working",2,"Closed",3,0) < CASE(PRIORVALUE(Status), "New",1,"Working",2,"Closed",3,0).

Reference: Salesforce Help, Article ID 000328374, "Examples of Validation Rules".

Salesforce Campaigns are the standard objects designed to track and measure the effectiveness of marketing initiatives, such as an advertising buy. By creating a Campaign record for the ad buy, populating the Actual Cost field, and associating leads and opportunities with it, Universal Containers can leverage built-in Campaign statistics. These statistics automatically calculate key metrics, including Return on Investment (ROI), by comparing the value of won opportunities against the campaign's cost. Campaign Hierarchies can further aggregate statistics from multiple related campaigns, providing a comprehensive view of the overall return. This is a declarative solution an app builder would configure to meet the requirement.

A. Utilize Account Hierarchies and Roll-Up Summary fields: This approach summarizes data at the account level, not for a specific marketing initiative, and cannot directly calculate the ROI of an ad buy.

B. Run an opportunities pipeline report: An opportunities pipeline report tracks sales progress but does not attribute revenue to a specific marketing campaign, which is essential for calculating ROI.

C. Change to a public security model: Altering the entire organization's security model is a drastic measure related to data visibility, not a solution for calculating marketing ROI.

1. Salesforce Help Documentation, "Campaign Fields": This document details the standard fields on the Campaign object. It describes the ActualCost field for tracking expenses and notes that the Return on Investment (ROI) percentage is a calculated field. The formula is (AmountWonOpportunities - ActualCost) / ActualCost. This directly supports using Campaigns to calculate ROI.

2. Salesforce Help Documentation, "View Campaign Hierarchy Statistics": This page explains that campaign hierarchies allow you to group campaigns and that statistics from child campaigns roll up to the parent. It states, "Campaign hierarchy fields aggregate data for a parent campaign and all the campaigns below it in the hierarchy," which includes values for won opportunities and costs, essential for a comprehensive ROI analysis.

3. Trailhead, "Campaign Management with Salesforce" module, "Track Campaign Success" unit: This official training material explicitly states, "Campaigns in Salesforce are all about tracking. You can track your marketing efforts and see how they’re doing in real time... you can easily see how many leads you’ve generated, how much pipeline you’ve built, and how many deals you’ve closed." It further details using reports and dashboards to visualize campaign ROI.