Explanation:

The Monitor tab in the Automation App, formerly known as Flow Monitor, is the correct tool for troubleshooting failed record-triggered flows in production. It displays a list of flow interviews (executions), including those that have failed, and provides detailed error messages, the specific element where the failure occurred, and input/output variable values for each run. The App Builder can review these failed interviews without requiring users to reproduce the error, as the system automatically logs each execution. This gives full visibility into intermittent failures, allowing the App Builder to diagnose issues such as missing field values, invalid references, or permission errors directly from the Monitor interface.

❌ Why Other Options Are Incorrect

A. Review the Flow Interview records in Setup to inspect paused interview variable values – This is incorrect because the Flow Interview object is primarily used for paused interviews, such as those waiting for a time trigger or a platform event. The question specifies that the flow is failing intermittently, not pausing. Failed interviews are not stored as Flow Interview records; they appear in the Monitor tab with error details. Paused interviews would not help diagnose the type of failure described here.

C. Use the Apex Replay Debugger against the flow – This is incorrect because the Apex Replay Debugger is a developer tool designed for debugging Apex code using debug logs. It is not compatible with flows and cannot be used to inspect flow variable values or element failures. Flows have their own debugging and monitoring tools, making this option irrelevant.

D. Open the flow in Flow Builder and run Debug with the "Run flow as another user" option enabled – This is incorrect because the Debug option in Flow Builder is used during development and testing in sandbox environments, not for troubleshooting production failures. Debugging with the "Run as another user" option would simulate a single run and cannot reproduce intermittent issues that occur randomly with different data sets. It also does not provide historical error data for past failures, which is what the App Builder needs to review.

📚 References

Salesforce Help – Monitor Flows – Explains that the Monitor tab displays flow executions, including failed, paused, and completed interviews, with detailed error information and execution details.

Explanation:

A before-save record-triggered flow is the most efficient and reliable solution because it updates the `Stage_Last_Changed__c` field in the same transaction before the record is saved to the database. By using the `$Record` global variable and the `ISCHANGED()` function to detect when `StageName` changes, the flow can conditionally assign today's date to the custom date field. This approach requires no additional DML operations, avoids recursion issues, and ensures the timestamp is always accurate and up-to-date. Before-save flows are the recommended declarative tool for field updates that need to happen immediately upon record save.

❌ Why Other Options Are Incorrect

B. A scheduled path on an after-save record-triggered flow that updates Stage_Last_Changed__c to today's date one hour after the change
– This is incorrect because the requirement is to stamp the date whenever the StageName changes, not one hour later. A scheduled path would introduce an unnecessary delay and could result in an incorrect timestamp if the record is updated again within that hour. Additionally, the field would not reflect the actual time of the stage change, which defeats the purpose of the requirement.

C. An approval process on Opportunity that uses Update Records to set Stage_Last_Changed__c to today's date when StageName changes
– This is incorrect because approval processes are designed for routing records for human approval, not for performing field updates based on field changes. While an approval process can include an update action, it is not triggered directly by a field change; it is triggered by submitting a record for approval. This approach is inefficient, difficult to maintain, and not the standard tool for this use case.

D. An autolaunched flow invoked from a custom button that the user clicks after editing the Opportunity StageName to update Stage_Last_Changed__c to today's date
– This is incorrect because it relies on manual user intervention, which is error-prone and inconsistent. Users may forget to click the button, resulting in inaccurate data. The requirement implies an automated solution that updates the field automatically whenever the StageName changes, without requiring any additional user action.

📚 References

Salesforce Help – Record-Triggered Flows – Explains that before-save flows run in the same transaction as the record save and can update fields on the same record without additional DML.

Explanation:

A validation rule is the correct solution because it enforces data quality at the point of record save. By creating a validation rule on the Opportunity object that checks if the `Expected_Close_Date_c` field is blank when the `StageName` equals "Qualified," the app builder can prevent users from saving the Opportunity until the expected close date is populated. This provides immediate, real-time feedback with a customizable error message, ensuring that all Opportunities entering the Qualified stage have the required information. Validation rules are the standard declarative tool for enforcing field completion based on specific conditions.

❌ Why Other Options Are Incorrect

A. Page Layout
– Page layouts control the placement, visibility, and editability of fields on a record page, but they cannot enforce conditional requirements. While you can mark a field as "Required" on a page layout, this makes it required globally for all records, not conditionally based on stage. It cannot require a field only when the Opportunity enters the Qualified stage, so it does not meet the specific requirement.

C. Activity History
– Activity History is a related list that displays past activities, such as tasks and events, associated with a record. It is used for tracking interactions and does not enforce field requirements or validation rules. This option is completely unrelated to the requirement of ensuring a field is populated before a stage change.

D. Record Type
– Record types are used to define different business processes, page layouts, and picklist values for a record. While you can make fields required on a page layout associated with a record type, the requirement is still global for that record type and cannot be conditionally applied based on the stage. Record types do not support dynamic field requirements that change as the record moves through stages.

📚 References

Salesforce Help – Validation Rules – Explains that validation rules verify that data entered by users meets specified criteria before saving and can reference stage and field values to enforce conditional requirements.

Explanation:

When creating custom report types in Salesforce, the Platform App Builder must have Read access to all objects they intend to include in the report type. If the app builder does not have the appropriate object-level permissions, granted through a profile or permission set, they will not be able to select or include those objects when defining the custom report type. This is a critical consideration because it ensures that users can only create report types for objects they are authorized to access, maintaining data security and preventing report creation on restricted objects. Since Universal Containers wants to report on job applications, likely a custom object, and resumes, potentially a related object or attachment, the app builder must verify they have the necessary permissions on both objects before attempting to create the custom report type.

❌ Why Other Options Are Incorrect

A. When a custom or external object is deleted, the report type and reports remain but cause an error when the report is run – This is incorrect because when a custom object is deleted, any associated custom report types and reports that reference that object are also automatically deleted by Salesforce. They do not remain in the system to cause errors. External objects, on the other hand, can cause errors if the external data source becomes unavailable, but the report type itself is not retained after the object is deleted.

B. A primary object selection is locked once the custom report type has been saved – This is incorrect because the primary object of a custom report type can be changed after the report type has been saved, as long as no reports have been created using that report type. Once reports exist, the primary object selection becomes locked to prevent breaking existing reports. The statement is too absolute and does not reflect the actual behavior.

C. Once the report type has been deployed, it is unable to be deleted – This is incorrect because custom report types can be deleted even after deployment, provided they are not referenced by any active reports. If reports are using the report type, it cannot be deleted until those reports are either deleted or reassigned. Deployment does not make the report type permanent.

📚 References

* Salesforce Help – Custom Report Types – States that users must have Read permission on all objects included in a custom report type; otherwise, they cannot create or edit the report type.

Explanation:

Roll-up summary fields in Salesforce allow app builders to perform calculations on child records in a master-detail relationship and display the results on the parent record. The three field types that support meaningful summarized calculations are Checkbox, Currency, and Percent. Checkbox fields support the COUNT function, enabling app builders to tally how many child records have the checkbox selected, such as counting completed tasks. Currency fields support SUM, MIN, MAX, and AVG, making them useful for aggregating monetary values such as total opportunity amounts or average deal sizes. Percent fields also support SUM, MIN, MAX, and AVG, allowing calculations such as average discount rates or maximum commission percentages across child records. These field types provide useful aggregation capabilities without requiring Apex code or manual calculations.

❌ Why Other Options Are Incorrect

B. Time – Time fields are not supported in roll-up summary fields. Salesforce does not allow aggregation functions such as SUM, MIN, MAX, AVG, or COUNT on Time fields. These fields are designed to store time-of-day values and cannot be mathematically summarized.

D. Date – While Date fields are technically supported, they are restricted to MIN and MAX functions only, which find the earliest or latest date. The question specifically asks for summarized calculations, which implies numerical aggregations such as SUM, AVG, or COUNT. Since Date fields do not support these functions, they are not suitable for the type of summarized calculations described.

📚 References

* Salesforce Help – Roll-Up Summary Field Considerations – Lists supported field types, including Checkbox, Currency, Date, DateTime, Number, and Percent, and explains the aggregation functions available for each type.