Explanation:

The requirement is to automatically delete records based on field values. Among the standard Salesforce automation tools, only Flow Builder has the native capability to delete records.

Let's break down each option:

C. Flow Builder
Correct. A record-triggered flow can be configured to run when a record is created or updated. Within the flow, the administrator can use a Decision element to check the record's field values and then use a Delete Records element to automatically delete the record if it meets the criteria. This is the modern, supported way to perform this action.

A. Workflow
Incorrect. Workflow Rules are a legacy automation tool. Their available actions are limited to:
- New Task
- Email Alert
- Field Update
- Outbound Message
Workflow Rules cannot delete the record that triggers them.

B. Process Builder
Incorrect. Similar to Workflow Rules, Process Builder has a limited set of immediate actions. While it is more powerful than Workflow and can create records and call Flows, its native actions do not include the ability to delete a record.

D. Automation Studio
Incorrect. Automation Studio is a feature of Marketing Cloud, not the core Salesforce platform (Sales Cloud, Service Cloud, etc.). It is not available for automating record deletion in the main Salesforce application.

Summary:
For any automation that requires deleting records in the core Salesforce platform, Flow Builder is the only declarative tool that provides this capability.

Reference:
Salesforce Help: "Delete Records Element" in Flow Builder
This documentation details how to use the "Delete Records" element within a flow to remove records from the database, which is the solution to this requirement.

Explanation:

An Outbound Message in Salesforce is a SOAP-based message sent from Salesforce to an external system when certain criteria are met.

Key Points:
- Outbound messages cannot be directly triggered by Flow or Process Builder.
- They are only available as an action in Workflow Rules.

When a Workflow Rule condition is met, Salesforce can:
- Send an Outbound Message to a configured endpoint URL.
- Include fields from the record in the message payload.

This is commonly used for integrations with external systems.

❌ Incorrect Options:

A. Process Builder
Process Builder can automate many actions (field updates, emails, tasks, invocable processes), but it cannot directly send outbound messages.
You would need to call an Apex action or Flow to simulate this.

B. Task Assignment
Task Assignment is used for creating tasks or notifications.
It cannot send messages to external systems.

D. Flow Builder
Flow Builder automates processes and can make HTTP callouts via Apex or external services, but standard outbound message actions are not natively available in Flow.
Workflow Rules are the simplest and standard method.

Summary:
To automate sending an outbound message to an external system, the administrator should create a Workflow Rule with an Outbound Message action.
Define the criteria for triggering the message.
Configure the endpoint URL and fields to send.

This is the Salesforce-native way to automate outbound SOAP messages without writing code.

Reference:
Salesforce Help: Workflow Actions: Outbound Messages
Trailhead: Automate Business Processes with Workflow Rules

Explanation:

Why A Is Correct
Deactivating a user is the only supported and reversible way to immediately free up a user license without losing any historical data.

When you deactivate a user:
- The Salesforce license is released instantly and becomes available for the new hire.
- All historical records (Owned records, Chatter posts, Audit trail, Login history, etc.) remain intact.
- The user cannot log in anymore.
- You can reactivate later if needed (e.g., contractor returns).

Quick Setup (30 seconds):
Setup → Users → [Former Employee] → Edit
Uncheck Active → Save
License counter drops by 1 → Assign to new user immediately

This is Salesforce’s official best practice for employee offboarding.

Why the Other Options Fail

Option B – Delete former employees user record is permanently destructive and wrong.
- User deletion is only allowed in sandboxes.
- In production, you cannot delete users — only deactivate.
- Even if possible, deletion erases all audit history and breaks record ownership trails.

Option C – Freeze former employees user record is not enough.
- Freezing only blocks login — it does NOT free the license.
- The seat remains occupied → you still can’t assign it to the new hire.
- Used only as a temporary security measure before deactivation.

Option D – Change the former users record to the new user is forbidden and dangerous.
- You cannot reuse a user record (violates compliance, audit, and licensing rules).
- Changing name/email breaks all historical attribution (reports, approvals, ownership).
- Triggers duplicate user errors and corrupts data integrity.

Salesforce Official Guidance
“Deactivate users who leave the company. This frees up the user license for reassignment while preserving all historical data.”
— Salesforce Help: Deactivate Users

Verification Steps (Live Test)
- Check Setup → Company Information → Used Licenses: 100/100
- Deactivate former user → Refresh → Used Licenses: 99/100
- Create new user → License available instantly
- Try Freeze only → License still occupied
- Try Delete → Button doesn’t exist in production

Explanation:

B. Assign permission set group to Users
A Permission Set Group is the most efficient way to manage and assign multiple Permission Sets (including the one you just created in step C) to a large number of users.

This approach bundles the required permissions and simplifies administration, making it ideal when the access needs to be granted to "more than one user."

C. Create a Permission Set
A Permission Set is the primary tool used to grant access to a custom object (Read, Create, Edit, Delete) and its custom fields (Field-Level Security, or FLS).

It is an additive way to extend permissions to users, independent of their Profile. Once created, it can be assigned to multiple users to meet the requirement.

❌ Incorrect Answers Detail

A. Add to manual sharing list
Manual Sharing is used to grant access to individual records (record-level security), not to grant object-level access (the ability to see the custom object and its fields in the first place). The object must be visible before any record can be shared.

D. Edit organization-wide defaults
Organization-Wide Defaults (OWD) set the default record-level access that users have to records they do not own. Like Manual Sharing, OWDs do not grant the required object-level permissions needed to see the custom object tab or its fields.

🌐 References
Salesforce Help: Permission Sets: This resource confirms that permission sets are used to grant additional permissions, including object and field access, to specific users regardless of their profile.

Salesforce Help: Permission Set Groups: This resource details that groups are used to bundle permission sets for simplified user assignment and maintenance, making it the preferred method for managing access for large groups.

Explanation:

The administrator needs a centralized, Salesforce-native way to track which users have been assigned specific licenses and permission sets. The Lightning Usage App is the out-of-the-box tool designed precisely for this kind of user entitlement reporting.

Let's break down each option:

B. Lightning Usage App
Correct. The Lightning Usage App is an administrator's hub for monitoring adoption and user entitlements. It contains pre-built reports and dashboards that show:

User Licenses: A summary of all license types, how many are used, and by whom.
Permission Set Assignments: A list of all users and the permission sets assigned to them.
This directly replaces the manual spreadsheet for tracking these assignments.

A. Login History
Incorrect. Login History is an audit log that shows user login attempts, IP addresses, and status (success/failure). It is used for security monitoring, not for tracking static assignments like licenses and permission sets.

C. User Report
Incorrect. While you can create a custom report on the User object, it is not a dedicated, pre-built feature for this purpose. The Lightning Usage App provides a more focused and easily accessible view specifically for license and permission set tracking without needing to build a report from scratch.

D. Permission Set Groups
Incorrect. A Permission Set Group is a configuration tool used to bundle multiple permission sets together for easier assignment. It is not a reporting tool for tracking what has already been assigned across the organization.

How to Access the Lightning Usage App:
From Setup, enter "Lightning Usage" in the Quick Find box and select it. Navigate to the "User Entitlements" tab to see the detailed reports.

Summary:
The Lightning Usage App is the standard, declarative feature that provides administrators with immediate visibility into license consumption and permission set assignments, eliminating the need for manual spreadsheets.

Reference:
Salesforce Help: "Monitor User Entitlements with the Lightning Usage App"
This documentation confirms that the app lets you "see how many user licenses you have and how they’re used" and "view the permission sets and permission set licenses assigned to each user."