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

Explanation:

To enforce process compliance in Case Management at DreamHouse Realty — specifically:
Preventing reversion to earlier case statuses
Ensuring certain fields are required based on specific criteria
The most effective and declarative solution is:

✅ Validation Rules
Validation Rules allow you to:
❌ Block status changes that violate business logic (e.g., reverting from "Closed" to "New")
✅ Enforce field requirements conditionally (e.g., require Resolution_Notes__c when Status = Closed)
🔐 Maintain data integrity and process consistency without writing code
These rules run before a record is saved, and if the condition is met, they display a custom error message to the user.

❌ Why the other options don’t work:
A. Workflow Rules
Can update fields or send alerts, but cannot prevent changes or enforce required fields.
B. Process Builder
Useful for automation, but doesn’t block user actions or enforce field requirements.
D. Activities Component
Displays tasks/events — not related to validation or process enforcement.

🔗 Reference:
You can explore best practices for case validation in this deep dive on Salesforce Case Validation Rules.

Explanation:

To show job applications with or without resumes, the app builder needs to use a custom report type with "Job Applications" as the primary object and "Resumes" as the secondary object.
When defining the relationship between the two objects, the app builder must select the option to include "A" records (Job Applications) "with or without" related "B" records (Resumes).
Once the custom report type is saved, the primary object cannot be changed. This means the app builder must be certain that "Job Applications" is the correct primary object before saving.

Why other options are incorrect
A. An app builder is unable to create custom report types for objects they do not have permissions for. This is a true statement in general, as an app builder needs at least "Read" access to the objects involved. However, it's not the primary consideration for creating a report that includes or excludes related records.
B. Once the report type has been deployed it is unable to be deleted. This is incorrect. A deployed custom report type can be deleted if needed.
D. 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. If a custom or external object is deleted, the associated custom report types and reports are also deleted.

Explanation:

To meet the visibility requirements for each team, we need to apply least privilege access and selective sharing:

🔒 Organization-Wide Default (OWD):
Set to Private for Accounts → ensures users only see records they own unless explicitly shared.
👥 Field Sales Team:
They should only see accounts they own → OWD Private already enforces this.
🌍 Regional Marketing Teams:
North American and European teams should see accounts in their respective regions → ✅ Use criteria-based sharing rules based on a custom field like Region__c = 'North America' or 'Europe' to share with respective public groups or roles.
🏢 Inside Sales Team:
Needs access to all accounts → ✅ Assign a profile with the "View All" permission on the Account object. This grants read access to all records of that object, regardless of ownership or sharing rules.

🔗 References:
Salesforce Sharing Rules Guide — explains how to use criteria-based sharing for regional access.
Permission Set and Profile Settings — details how "View All" works for object-level access.

Explanation:

Correct Answer:
C. The Partial sandbox is at capacity. ✅

Why this is correct:
A Partial Copy Sandbox includes data defined in the sandbox template, but it’s limited by the 5 GB of data storage or 10,000 records per selected object (whichever is less).
Since Shipping__c has 2 million rows in production, it far exceeds the 10,000 record cap for a Partial Sandbox.
Result: Only up to 10,000 rows could be copied — and if the sandbox template wasn’t set up to include Shipping, or if the object was too large, you could end up with no records at all.

Why not the others:

A. The sandbox was refreshed too early ❌
Timing of the refresh doesn’t affect whether the data is included — only the template and sandbox limits do.

B. The selected objects in the sandbox template ❌ (tricky!)
If Shipping wasn’t selected in the template, yes, it would have no data.
BUT the question says there are 2 million rows in production — this hints that it was selected, but the data volume exceeded the Partial Sandbox limit.
On the exam, “at capacity” is the better answer because that’s what explains the missing data in large-volume objects.

D. The sandbox is still populating data ❌
Once a Partial Sandbox is refreshed, the data is copied during the refresh.
You don’t have a “delayed population” issue like with some asynchronous processes.

📖 Reference:
Salesforce Help: Sandbox Types
Salesforce Help: Partial Copy Sandbox