An app builder needs to deploy a new account detail page layout from sandbox to
production.
Which three components should an app builder include in the Change Set to ensure it
deploys successfully and visually as expected?
Choose 3 answers
A. Detail page layout
B. Custom fields
C. Custom actions
D. Lightning App Builder
E. System administrator profile
Explanation:
Deploying a Lightning record page (often referred to as a "detail page layout" in the context of Lightning Experience) requires deploying all its dependent components to ensure it works correctly in the target org.
Why A is Correct:
The Detail page layout (officially called a Lightning Page) is the primary component you intend to deploy. This is the core item that must be included in the Change Set.
Why B is Correct:
If your page layout contains any custom fields, those fields must also be deployed. If the custom fields do not exist in the production org, the page layout will fail to load or will show errors for those missing fields. The deployment of the page layout will likely fail during validation if its dependent fields are missing.
Why C is Correct:
If you have added any custom actions (like an update record action) to the page's publisher layout, those actions must be deployed. The page layout references these actions. If they are missing in production, those specific components will not appear or function on the page.
Why D is Incorrect:
Lightning App Builder is the tool used to create and edit Lightning Pages. It is not a deployable component itself; it is a feature of the Salesforce platform. You deploy the output of the tool (the Lightning Page), not the tool.
Why E is Incorrect:
While profile settings control who can see the page layout, the System Administrator profile itself is not a component you include in a Change Set to make the page layout deploy or render correctly. Profile visibility for the page is handled by the page's assignment (which is part of the page deployment) or by permission sets. You do not deploy entire profiles for this purpose.
Reference:
Salesforce Help - "Change Sets Overview" and "Deploy Lightning Page Resources". The key principle is that when deploying any component, you must also deploy all its dependencies—the other metadata components it relies on to function. For a Lightning Page, this includes the fields, actions, and any other custom components placed on it.
Accounts at Universal Containers are currently readable by all users but editable only by
their owners. Management wants to designate some Accounts as VIP Accounts. Only
Account owners should have read access to these VIP accounts.
Which two actions should an app builder take to meet the requirements?
(Choose 2 answers)
A. Implement a sharing rule.
B. Configure a permission set.
C. Set up an Account Team.
D. Change organization-wide defaults.
Explanation:
Universal Containers currently has Accounts set with Organization-Wide Defaults (OWD) as Public Read Only, meaning all users can read all Accounts, but only owners can edit them. The requirement is to restrict VIP Accounts so that only their owners have read access (and, by extension, edit access, as owners already have edit rights). This involves modifying access controls to limit visibility for specific Accounts. Below is a concise analysis:
A. Implement a sharing rule (Correct):
A criteria-based sharing rule can be used to grant read access to VIP Accounts only to their owners. Since the OWD is Public Read Only, a sharing rule can override this for VIP Accounts (identified by a field, e.g., VIP_Account__c = true) to ensure only owners have access. This requires first setting the OWD to Private (see option D) to restrict general access, then using the sharing rule to reinforce owner-only access.
Steps: Create a sharing rule for Accounts where VIP_Account__c = true, sharing with the owner (or a public group containing only the owner, if needed).
Reference: Salesforce Help - Sharing Rules
B. Configure a permission set (Incorrect):
Permission Sets control object-level, field-level, or app permissions, not record-level access. They cannot restrict read access to specific records like VIP Accounts for non-owners. Permission Sets are better suited for granting additional access, not limiting it based on record criteria.
Reference: Salesforce Help - Permission Sets
C. Set up an Account Team (Incorrect):
Account Teams allow specific users (e.g., team members) to be granted access to Accounts, but they are designed to expand access, not restrict it to only the owner. Setting up an Account Team would not prevent other users from reading VIP Accounts if the OWD is Public Read Only.
Reference: Salesforce Help - Account Teams
D. Change organization-wide defaults (Correct):
To ensure only Account owners have read access to VIP Accounts, the OWD for Accounts must be changed to Private. This restricts all users except owners (and those with higher hierarchy access or sharing rules) from reading any Accounts. Then, for non-VIP Accounts, a sharing rule can restore Public Read Only access, while VIP Accounts remain restricted to owners.
Steps: Set Account OWD to Private in Setup > Security > Sharing Settings, then create a sharing rule for non-VIP Accounts (e.g., VIP_Account__c = false) to grant read access to all users.
Reference: Salesforce Help - Organization-Wide Defaults
Recommended Approach:
Change the OWD for Accounts to Private to restrict read access to owners only.
Create a criteria-based sharing rule for non-VIP Accounts (e.g., VIP_Account__c = false) to grant read access to all users, restoring the original Public Read Only behavior for non-VIP Accounts.
Optionally, create a sharing rule for VIP Accounts to explicitly reinforce owner-only access, though the Private OWD may suffice if no additional sharing is needed.
Notes:
Assumes a custom field (e.g., VIP_Account__c) exists to identify VIP Accounts.
If role hierarchy grants access to managers, ensure VIP Accounts are not inadvertently shared; adjust hierarchy or use manual sharing if needed.
This approach maintains edit access for owners while restricting read access for VIP Accounts.
References:
Salesforce Trailhead: Data Security
Salesforce Help: Sharing Rules
An app builder created multiple custom fields, page layouts, and reports in the sandbox
and added them to a change set was deployed to production, the reports were NOT
deployed.
What should the app builder do?
A. Move the reports to the Untried Public Reports folder and add them to a new change set.
B. Move the reports from the Unfiled Public Reports folder and add them to a new change set
C. Recreate the reports in production. Reports are not supported in change sets
D. Add the reports to an unmanaged package and install the unmanaged package into production.
Explanation:
Why:
Reports stored in My Personal/Private or Unfiled Public Reports can’t be deployed via change sets. To deploy them, first move/copy each report to a different report folder (e.g., a shared/custom public folder), then add them to a new change set and deploy again.
Why not the others
A. “Untried Public Reports” isn’t a thing, and putting reports in Unfiled Public Reports is exactly what prevents deployment.
C. Incorrect—reports are supported in change sets; they just must be in a deployable folder.
D. Possible but unnecessary and not the standard sandbox→prod path; packaging is overkill here and adds complexity. The recommended fix is to move them to a proper folder and use a change set.
Cloud Kicks has a sales rep who is stating that their Contact is unavailable for other users
to see within Salesforce.
In which three ways can an app builder troubleshoot this issue?
(Choose 3 answers)
A. Create an Account Sharing Rule to give the users access to all records.
B. Confirm whether Default Organization-Wide Sharing Settings provide access to the Account.
C. Review the Contact record and ensure it is linked to an Account.
D. Verify the users with the issue have access to the Contact object.
E. Create a new Contact and have the users try again.
Explanation:
The issue is that a sales rep reports that their Contact is unavailable for other users to see in Salesforce. This suggests a visibility problem, likely related to sharing settings, object access, or record relationships. An app builder needs to troubleshoot using methods that align with Salesforce’s security and access model. Below is a concise analysis of each option:
A. Create an Account Sharing Rule to give the users access to all records (Incorrect):
Creating a sharing rule to grant access to all Account records is overly broad and does not specifically address the issue of a single Contact’s visibility. Additionally, Contact visibility is often controlled by the parent Account’s sharing settings due to the Account-Contact relationship. This action could unnecessarily expose unrelated records and is not a targeted troubleshooting step.
Reference: Salesforce Help - Sharing Rules
B. Confirm whether Default Organization-Wide Sharing Settings provide access to the Account (Correct):
Contact visibility is typically controlled by the Organization-Wide Default (OWD) settings of the parent Account due to the standard master-detail or special relationship between Accounts and Contacts. If the Account’s OWD is set to Private, users without access to the Account (via ownership, role hierarchy, or sharing rules) cannot see associated Contacts. Checking the Account’s OWD settings is a critical troubleshooting step to determine if the issue stems from restricted Account access.
Steps: Go to Setup > Security > Sharing Settings and review the OWD for Accounts and Contacts.
Reference: Salesforce Help - Organization-Wide Defaults
C. Review the Contact record and ensure it is linked to an Account (Correct):
In Salesforce, Contacts are typically linked to Accounts via a Lookup or Master-Detail relationship. If a Contact is not associated with an Account (e.g., the Account field is blank), its visibility may be restricted, especially if the OWD for Contacts is Controlled by Parent or Private. Reviewing the Contact record to confirm it is linked to an Account is a key troubleshooting step, as missing or incorrect Account linkage could prevent other users from seeing the Contact.
Steps: Open the Contact record and check the Account Name field to ensure it references a valid Account.
Reference: Salesforce Help - Account and Contact Relationships
D. Verify the users with the issue have access to the Contact object (Correct):
Users must have at least Read access to the Contact object via their Profile or Permission Set to view Contact records. If the users experiencing the issue lack object-level access, they won’t see the Contact, regardless of record-level sharing settings. Checking Profile or Permission Set permissions for the Contact object is a fundamental troubleshooting step.
Steps: Go to Setup > Users > Profiles, select the user’s Profile, and verify that the Contact object has Read access.
Reference: Salesforce Help - Profiles and Permissions
E. Create a new Contact and have the users try again (Incorrect):
Creating a new Contact to test visibility does not directly troubleshoot the issue with the existing Contact record. It may help identify whether the problem is specific to the record, but it’s not a systematic approach to diagnosing the root cause (e.g., sharing settings, object access, or Account linkage). This option is more of a workaround than a troubleshooting step and is less efficient than the other correct options.
Reference: Salesforce Help - Troubleshooting Record Access
Recommended Troubleshooting Steps:
Check OWD Settings (B): Verify the OWD for Accounts and Contacts in Setup > Sharing Settings. Ensure the Account OWD is not Private or that Contacts are not set to Controlled by Parent, which could restrict access.
Verify Contact’s Account Link (C): Open the Contact record and confirm it is linked to a valid Account. If not, update the Account Name field or investigate why the linkage is missing.
Confirm Object Access (D): Check the users’ Profiles or Permission Sets to ensure they have Read access to the Contact object. Also, verify if they have access to the parent Account via sharing rules or role hierarchy.
Additional Notes:
If the Account’s OWD is Private, check if the users are in the same role hierarchy as the Account owner or if sharing rules grant them access.
If Contacts are set to Controlled by Parent, ensure the parent Account’s access settings allow visibility.
Use the Sharing Hierarchy (via the “Sharing” button on the Contact or Account record) to inspect why specific users cannot see the record.
References:
Salesforce Trailhead: Data Security
Salesforce Help: Troubleshooting Record Access
Universal Container's sales reps can modify fields on an opportunity until it is closed.
The sales operations team has access to modify the Post-Close Follow-up Date and Post-Close Follow-up Comments fields after the opportunity is closed. After the
opportunity is closed, the rest of the fields are read only.
How should these requirements be met?
A. Use record types with field sets and restrict editing fields using field-level security.
B. Use field-level security on page layouts to restrict editing fields.
C. Use field-level security on page layouts with record types to restrict editing fields,
D. Use field-level security to mark fields as read-only on the Sales profile.
Explanation:
This requirement involves controlling field editability based on a record's stage (open vs. closed) and the user's role (sales rep vs. sales operations). The key is that the same field (e.g., Amount) needs to be editable in one context and read-only in another. This requires a combination of tools.
Why C is Correct: This is the standard and most effective solution.
Record Types: Create two record types for the Opportunity object: "Open Opportunity" and "Closed Opportunity."
Page Layouts: Assign different page layouts to each record type.
The "Open Opportunity" layout shows all editable fields for sales reps.
The "Closed Opportunity" layout makes most fields read-only and prominently displays the two "Post-Close" fields for the sales operations team to edit.
Field-Level Security (FLS): FLS is used to ensure that the sales operations team has Edit access to the "Post-Close" fields, while the sales reps might only have Read access (if that is a requirement). FLS controls the fundamental ability to see and edit a field at the object level.
Automation (Workflow/Process Builder/Flow): An automated process (not listed in the answers but implied as the trigger mechanism) is required to automatically change the Record Type from "Open" to "Closed" when the Opportunity stage is set to a closed stage. This is the crucial step that swaps the page layout, changing the field-level behavior for the entire record.
Why A is Incorrect: Field Sets are a developer feature used to group fields for programmatic purposes (e.g., in a Visualforce page or Lightning component). They are not a security or layout tool for declaratively controlling field editability for different user profiles. This option overcomplicates a straightforward layout and security requirement.
Why B is Incorrect: While page layouts can restrict editing by making fields read-only, this setting applies to all users viewing that layout. You cannot make a field read-only for one profile and editable for another on the same page layout. This is why you need different page layouts (assigned via record types) for the "open" and "closed" states. FLS on its own is not granular enough for this requirement.
Why D is Incorrect: Using Field-Level Security (FLS) to mark fields as read-only on the Sales profile would make those fields read-only at all times, even when the opportunity is open. This violates the requirement that sales reps can modify those fields until the opportunity is closed. FLS is a static control, not a dynamic one that changes based on the record's state.
Summary:
The solution dynamically changes the user's experience based on the record's data (its stage). This is achieved by:
Using Record Types to categorize records into "Open" and "Closed."
Using different Page Layouts for each record type to control field editability at the UI level.
Using Field-Level Security to ensure the sales operations team has the underlying permission to edit the specific post-close fields.
Using an Automation Tool to change the record type when the opportunity is closed.
Reference:
Salesforce Help - "Record Types" and "Control Field Access with Page Layouts and Record Types". The documentation explains how record types and page layouts work together to provide different user experiences for different states of the same record.
Cloud Kicks works on an annual subscription model. When a sales rep marks an
opportunity as closed won, a new opportunity should automatically be created for the
renewal. The contracts team works outside of Salesforce but also needs to be notified
about closed deals in order to initiate the contract process with the customer.
Which automation solution would meet these requirements?
A. Approval Process
B. Validation Rule
C. Process Builder
D. Workflow Rule
Explanation:
This scenario involves two automation goals:
Automatically create a renewal Opportunity when an Opportunity is marked Closed Won.
Notify an external contracts team about the closed deal.
🔹 Why Process Builder is the best fit:
It can detect field changes (e.g., Stage = Closed Won).
It can create new records, such as a renewal Opportunity.
It can invoke Apex, send email alerts, or even call outbound messages to notify external systems.
It supports multiple actions in a single process — perfect for this multi-step requirement.
❌ Why the other options don’t work:
A. Approval Process
Used for record approval workflows, not for automation based on field changes or record creation.
B. Validation Rule
Prevents users from saving records under certain conditions — it doesn’t automate actions.
D. Workflow Rule
Can send email alerts or outbound messages, but cannot create records (like a renewal Opportunity). Also being phased out in favor of Flow and Process Builder.
🔗 References:
Salesforce Help: Process Builder Overview
Trailhead: Automate Business Processes with Process Builder
Universal Containers has created two custom objects called Seminars and Attendees.
Organization-wide defaults for these objects have been set to Private. Universal Containers
wants to set up a new Junction object between these custom objects. A select group of
users should be able to edit records in the Junction object.
Which two steps should an app builder take to configure the proper security?
A. Set Sharing Settings to Road Only on both Master-Detail relationship fields.
B. Create owner-based sharing rules that give Read access to the master objects.
C. Sat lookup filters on both Junction object relationship field.
D. Create an owner-based sharing rule that gives Road action to the junction object.
Explanation:
A. Set Sharing Settings to Read Only on both Master-Detail relationship fields:
When a user is given edit access to a junction object record, they will inherit access from the master records. To allow a user to edit the junction record while only providing read access to the master records, you need to set the "Sharing Settings" option on the master-detail relationship field to "Read Only". This prevents a user who has edit permission on the junction object from also gaining edit access to the master records.
D. Create an owner-based sharing rule that gives Read action to the junction object:
With the junction object's OWD set to Private, only the record owner and users higher in the role hierarchy have access by default. To give a select group of users (not just the owner) the ability to edit the junction records, you must first give them at least Read access via a sharing rule. Once they have Read access, and their profile permissions grant Edit access, they can edit the junction records. This sharing rule can be based on the owner of the junction records.
Why other options are incorrect
B. Create owner-based sharing rules that give Read access to the master objects:
While users need at least Read access to the master objects (Seminars and Attendees) to interact with the junction object, creating sharing rules for the master objects is not sufficient to grant edit access specifically on the junction object. The question asks how to secure access to the junction object for editing, which requires a sharing rule on the junction object itself.
C. Sat lookup filters on both Junction object relationship field:
Lookup filters are used to restrict the records that can be selected in a lookup relationship. They do not control or grant record-level access for security purposes.
Cloud Kicks is implementing an approval process for opportunities that requires managers
to approve all opportunities above $50,000 before they can be
marked as Closed Won.
Which two delivery methods can a manager utilize to respond to approval requests in the
Salesforce mobile app?
(Choose 2 answers)
A. Home Screen
B. In-App Notification
C. Record Detail
D. Navigation Menu
Explanation:
Cloud Kicks requires managers to approve opportunities exceeding $50,000 before they can be marked as Closed Won, and the approval process must be accessible via the Salesforce mobile app. In Salesforce, approval requests can be responded to in specific ways within the mobile app. Below is a concise analysis of each option:
A. Home Screen (Incorrect):
The Home Screen in the Salesforce mobile app displays key metrics, tasks, or quick actions but does not provide a direct interface for responding to approval requests. While it may show notifications or tasks related to approvals, managers cannot take action (approve/reject) directly from the Home Screen.
Reference: Salesforce Help - Salesforce Mobile App
B. In-App Notification (Correct):
In-App Notifications in the Salesforce mobile app alert users to pending approval requests. Managers can tap on an approval notification, which directs them to the approval request details, where they can approve or reject the request. This is a primary method for responding to approvals in the mobile app, providing a quick and direct way to act on notifications.
Reference: Salesforce Help - Respond to Approval Requests in the Salesforce Mobile App
C. Record Detail (Correct):
The Record Detail page for an Opportunity in the Salesforce mobile app displays the approval request if one is pending. Managers can navigate to the Opportunity record, view the approval section, and take action (approve/reject) directly from the record’s detail page. This is a standard method for handling approvals in the mobile app.
Reference: Salesforce Help - Approvals in Salesforce Mobile
D. Navigation Menu (Incorrect):
The Navigation Menu in the Salesforce mobile app allows users to access objects, apps, or other features but does not provide a direct interface for responding to approval requests. While managers can navigate to the Opportunity object or an Approvals tab (if configured), the actual approval action occurs on the Record Detail page or via In-App Notifications, not directly in the Navigation Menu.
Reference: Salesforce Help - Salesforce Mobile Navigation
Recommended Approach:
In-App Notification: Managers receive a push notification or in-app alert for pending approval requests. Tapping the notification takes them to the approval interface to approve or reject the Opportunity.
Record Detail: Managers can navigate to the Opportunity record in the mobile app, locate the approval request section, and take action directly on the record.
Additional Notes:
Ensure the approval process is configured in Setup > Approval Processes to trigger for Opportunities with an amount exceeding $50,000.
Verify that managers have the necessary permissions (via Profile or Permission Set) to approve/reject requests.
The Salesforce mobile app must be properly configured to display notifications and allow approval actions.
References:
Salesforce Help: Approvals in the Salesforce Mobile App
Salesforce Trailhead: Approval Processes
Universal containers wants to ensure that they are accepting clean data from their users and verify that important fields are entered. What should an app builder recommend to meet this requirement?
A. Update the important fields to be required on the page layout
B. Make a formula field to check the format of the important fields
C. Create a workflow rule to check the fields are formatted correctly
D. Configure a validation to require a field for a specific record type
Explanation:
Why:
Validation rules are designed to verify data before save and block the save when the data doesn’t meet your standards—perfect for enforcing both required fields and format checks (e.g., ISBLANK(), REGEX()). You can also scope the rule to specific record types (e.g., RecordType.DeveloperName = "Enterprise"), so the requirement only applies where needed.
Why not the others
A. Required on page layout:
Only enforces entry when that specific page layout is used; it doesn’t consistently enforce requirements across all entry points (API/imports/automations). It also doesn’t validate format.
B. Formula field:
Formula fields are calculated and read-only; they can’t enforce input or block saves.
C. Workflow rule:
Workflow automates after a record is saved; it can’t stop a bad save. Use validation rules to prevent the save instead.
References:
Salesforce Help: Validation Rules (verify data before save, apply to new/updated records).
Salesforce Help: Make a custom field required (page-layout requirement is layout-specific).
Sales reps at Cloud Kicks (CK) forget to submit for approval when CK needs orders
reviewed before close won. CK wants to automatically submit opportunities into the Secure
Commitment Stage to eliminate manual submission.
Which three features would meet the business requirements?
(Choose 3 answers)
A. Workflow
B. Process Builder
C. Apex
D. Chatter action
E. Flow
Explanation:
The business requirement is to automatically start an approval process when an Opportunity reaches a certain stage ("Secure Commitment"), eliminating the need for manual submission. This is a classic automation scenario.
Why B is Correct (Process Builder):
Process Builder is a powerful, declarative automation tool that can be triggered when a record is created or edited. A process can be built on the Opportunity object to fire when the Stage is changed to "Secure Commitment." Its immediate action can be to Submit for Approval, launching the predefined approval process. This is a standard, out-of-the-box action in Process Builder.
Why C is Correct (Apex):
Apex code (a trigger) can be written on the Opportunity object. The trigger would detect when the Stage field is updated to "Secure Commitment" and then use the Approval. ProcessSubmitRequest method to programmatically submit the record to its approval process. This is a fully customizable and powerful code-based solution.
Why E is Correct (Flow):
A record-triggered flow is the modern successor to Process Builder for automation. It can be configured to run when an Opportunity is created or updated and its stage equals "Secure Commitment." Within the flow, you can use the Submit for Approval element to achieve the exact same result as Process Builder. Salesforce is increasingly directing users to use Flow for this type of automation.
Why A is Incorrect (Workflow):
Workflow Rules are a legacy automation tool. Their available actions are limited to:
New Task
Email Alert
Field Update
Outbound Message
Workflow Rules cannot submit a record for approval. This critical functionality was added in the more modern tools like Process Builder and Flow.
Why D is Incorrect (Chatter Action):
A Chatter Action is a button or link in the Chatter publisher that lets users perform quick actions, like posting a message or updating a record. It is a manual user interface component, not an automation tool. It does not help automatically trigger an approval process.
Summary:
The three features capable of automatically submitting a record for approval based on a criteria change are the modern automation tools: Process Builder, Apex, and Flow.
Reference:
Salesforce Help:
"Start an Approval Process with Process Builder"
"Use Apex to Submit Records for Approval"
"Submit for Approval Element in Flow"
Sales reps at Universal Containers use Salesforce on their mobile devices. They want a
way to odd new contacts quickly and then follow up later to complete the additional
Information necessary.
What mobile solution should an App Builder recommend?
A. Customize the mobile menu to move Contacts to the top.
B. Build a global action to create Contacts.
C. Add a compact layout to Contacts.
D. Use Path and set pre-defined values
Explanation:
Sales reps need a fast and efficient way to add new Contacts on mobile, with the ability to fill in additional details later. This calls for a solution that’s:
Quick to access
Streamlined for minimal input
Mobile-optimized
✅ Global Actions are perfect for this:
They allow users to create records from anywhere in the Salesforce mobile app.
You can design the action layout to include only essential fields, making it fast to complete.
Reps can later edit the Contact record to add more details.
Global actions appear in the publisher layout, making them easy to access on mobile.
❌ Why the other options don’t work:
A. Customize the mobile menu
This only changes navigation order — it doesn’t streamline record creation.
C. Add a compact layout
Compact layouts affect record display, not how records are created.
D. Use Path and set pre-defined values
Path is used for guiding users through stages (like Lead or Opportunity), not for quick record creation.
🔗 References:
Salesforce Help: Global Actions
Trailhead: Customize the Salesforce Mobile App
Cloud Kicks has five years of sales data and would like to track when customers made their first purchase. How should an app builder use a roll-up summary to meet the requirements?
A. Create a new roll-up summary field called First Order Date, using Type MIN on the Opportunity Close Date with a filter where IsWon = TRUE.
B. Create a new date field called First Order Date, create a new Workflow to set the date, and roll up the value with a filter where IsWon = TRUE.
C. Create a new roll-up summary field called First Order Date, using Type SUM on Opportunity Close Date.
D. Create a new date field called First Order Date, then create a roll-up summary to update the field using Type MIN.
Explanation:
Roll-up Summary Field: A roll-up summary field is designed to aggregate data from a set of related detail records and display the result on the master record. In this case, you can create a roll-up summary field on the Account object (the master) to summarize data from the related Opportunity records (the details).
MIN Function: The MIN function is used to find the earliest date in a set of date fields. By applying MIN to the Opportunity Close Date, the roll-up summary will return the date of the earliest successful purchase.
Filter IsWon = TRUE: This filter is crucial. It ensures that only Won opportunities are included in the calculation, so the roll-up summary only considers actual purchases and ignores opportunities that were lost or are still in progress.
Why other options are incorrect
B. Create a new date field called First Order Date, create a new Workflow to set the date, and roll up the value with a filter where IsWon = TRUE: A workflow rule cannot perform a roll-up summary. This approach is incorrect because it mixes two different functionalities in an unworkable way.
C. Create a new roll-up summary field called First Order Date, using Type SUM on Opportunity Close Date: You cannot use SUM on a date field. The SUM type is used for number fields, not dates.
D. Create a new date field called First Order Date, then create a roll-up summary to update the field using Type MIN: This describes a two-step process that is unnecessary. The roll-up summary field itself is the field that will store the date. You don't need to create a separate date field and then have the roll-up summary update it. The roll-up summary field is a dedicated field type.
| Page 5 out of 25 Pages |
| Previous |