Explanation:

A. IP address restrictions are set on the profile or globally for the org (✅ Correct)
Salesforce allows administrators to define allowed IP ranges:
Globally: Setup → Network Access (applies to all users).
Profile level: Setup → Profiles → Login IP Ranges (applies to users with that profile).
Users can only log in from IP addresses within the defined ranges.

C. Enforce Login IP Ranges on Every Request (✅ Correct)
By default, IP restrictions are checked only at login.
Selecting “Enforce Login IP Ranges on Every Request” ensures that users cannot access Salesforce if they move outside the allowed IP range during an active session.

❌ Incorrect Options:

B. Assign single sign-on to a permission set
Single Sign-On allows users to log in via an external identity provider.
It does not enforce IP restrictions.

D. Restrict U2F Security Keys on the user's profile
U2F security keys are used for multi-factor authentication, not IP restrictions or login hours.

Summary:
To prevent users from accessing Salesforce from outside a trusted network:
Set IP address restrictions on profiles or globally.
Enable “Enforce Login IP Ranges on Every Request” if you want active sessions to be continuously validated.
This combination ensures that users cannot log in or access Salesforce outside approved network locations.

Reference:
Salesforce Help: Restrict Login Access by IP Address
Trailhead: User Authentication & Access

Explanation:

Auto-Response Rules
Automatically send acknowledgment emails when a case is created.
Ideal for the requirement: “acknowledged immediately via email.”

Queues
Assign cases to groups of agents rather than individual users.
Cases can be automatically routed to the appropriate agent queue based on criteria (e.g., Case Reason = Installation).

Escalation Rules
Automatically escalate cases that are not resolved within a specified time.
Here, “cases still in New status after 4 hours must be escalated” is handled by an Escalation Rule.

❌ Incorrect Options:

A. Auto-response rules, Macros, Entitlements
Macros automate repetitive tasks but do not assign or escalate cases automatically.
Entitlements track service levels but are not used for assignment or acknowledgment email automation.

B. Auto-response rules, Queues, Macros
Macros cannot escalate cases automatically.

D. Auto-response rules, Entitlements, Escalation Rules
Entitlements track service contracts, not routing to agents.
While Escalation Rules handle the 4-hour escalation, the assignment to agents is better done via Queues.

Summary:
To meet the policy for Installation cases:
Auto-response rules → send acknowledgment emails immediately.
Queues → assign cases to the appropriate group of agents.
Escalation rules → escalate cases that remain in New status after 4 hours.
This combination ensures timely acknowledgment, proper assignment, and escalation.

Reference:
Salesforce Help: Auto-Response Rules
Salesforce Help: Queues
Salesforce Help: Escalation Rules

Explanation:

Why This Is Correct
Lead Assignment Rules are built to route new Leads automatically to the right owner based on criteria—such as Country, State/Province, Postal Code, or City. You can define one or more rule entries that evaluate address fields (and ranges or text matches) and then assign the Lead to a specific user or queue. Rules run at creation (and optionally on update when invoked), which is exactly when you need address-based routing.

Why Not the Others
A. Create a Formula Field
A formula field can help derive or normalize address logic (e.g., map zip codes to a region code), but it doesn’t perform assignment. You’d still need an automation (like Lead Assignment Rules) to act on the formula’s value. By itself, a formula field won’t route Leads to owners.
C. Assign with an Escalation Rule
Escalation Rules apply to Cases, not Leads. They are time-based and designed to escalate ownership or notify users after certain age thresholds, not to assign new Leads at creation.
D. Configure a Validation Rule
Validation Rules block saving records that don’t meet criteria. They don’t assign owners or route records. Using a validation rule here would only prevent Lead creation/updates—not distribute them to the correct salesperson.

✅ Bottom Line
Set up Lead Assignment Rules with criteria on address fields to route new Leads to the correct salesperson automatically at creation. If needed, add a supporting formula field to simplify complex zip/state mapping and reference it in the rule criteria.

Explanation:

✅ Why this is correct
When users encounter Flow errors, the best practice is to handle the error gracefully and guide them with clear, user-friendly messages.
In Screen Flows, you can use a Fault Connector from an element (such as “Get Records,” “Update Records,” or “Create Records”) to a Screen Element.
That screen can:
Display a custom message (e.g., “Please complete the Account Address and Industry fields before running this flow.”)
Optionally give instructions or a link to the record they need to update.
Prevent the confusing system error message from appearing.
This approach improves user experience without bypassing business logic or data quality controls.

❌ Why the others are incorrect

A. Remove validation rules:
This would weaken your data integrity and allow incomplete or invalid records—solves the symptom, not the root cause.
B. Create a permission set to allow users to bypass the error:
Permission sets control access, not data completeness or flow behavior. The problem isn’t about permissions—it’s about missing required information.
D. Uncheck the “End User Flow Errors” box in Setup:
That setting only suppresses the system-generated error emails sent to users; it doesn’t fix or explain the error. Users would still see confusing error messages in the UI.

🧠 Best Practice Tip
Always use fault connectors on flow elements that interact with records or external systems. Provide:

Clear, plain-language explanations
Specific next steps (“Update the Account record first”)
Optionally, a “Back” or “Cancel” button to exit gracefully

This makes your flows much more user-friendly and self-explanatory, especially in production environments.

Explanation:

A. Filter the component visibility with User > Profile > name = Sales User.
The requirement specifies that the component should only be visible to the "sales team," which in Salesforce is typically managed by a specific Profile (e.g., "Sales User" or "Sales Profile") or a Permission Set. Using the User's Profile is the standard, reliable way to target a group of internal users for component visibility.

B. Filter the component visibility with Form Factor = Phone.
The requirement explicitly states that the component should only show when users "are on their mobile phones." The Form Factor is the component visibility filter that allows you to specify the device type accessing the record page (Desktop, Phone, or Tablet). Setting it to Phone ensures the component is hidden on a desktop/laptop browser.

The Solution:
To meet both requirements, you would add two separate filters to the component visibility settings on the Lightning App Builder:
Filter 1: Field: User > Profile > Name, Operator: Equals, Value: Sales User
Filter 2: Field: Form Factor, Operator: Equals, Value: Phone

You would then set the filter logic to AND, ensuring that both conditions must be true for the component to appear.

❌ Incorrect Answers Detail:
C. Filter the component visibility with view = Mobile/Tablet.
The filter condition is Form Factor, not "view." While "Mobile/Tablet" sounds correct, it is not the actual visibility filter option available in the Lightning App Builder. The available values are typically Desktop, Phone, and Tablet.

D. Filter the component visibility with User > Role > Name = Sales User.
While a Role can be used to categorize users, a Role is primarily for defining the hierarchy of data access (sharing rules), not for defining a user's type (like "sales user"). In Salesforce, a user's functional job type (and their permissions/access to features) is correctly defined by their Profile or a Permission Set, making the Profile filter (Option A) the standard and correct choice here.