Explanation:

The requirement is to grant Editor access to 20 specific "Superusers" across all regions, without affecting the existing Viewer access for regional sales reps. The optimal solution is to:

Create a Salesforce Public Group – Add all 20 Superusers to this group. Public groups are ideal for collecting users from different roles, profiles, or departments without altering the role hierarchy.

Assign the public group Editor access to the app – In the app's sharing settings, you grant the public group Editor permissions. This overrides or supplements the existing Viewer access for those specific users, while all other regional reps retain their Viewer access.

This approach is scalable, maintainable, and does not disrupt the role hierarchy. It also avoids creating duplicate roles or complex sharing rules.

Why the others are wrong:

B (Create new roles):
Roles are hierarchical and designed for reporting/ownership, not for granting app permissions. Creating new roles for 20 users would distort the role hierarchy and require restructuring reporting lines—unnecessary and not recommended.

C (Create a new sharing rule):
Sharing rules are for record-level access in Salesforce (e.g., Account sharing), not for app-level permissions in CRM Analytics. App access is controlled via folder/app permissions, not sharing rules.

References:

Salesforce Help – "Manage App Permissions": Recommends using public groups for assigning app access to cross-functional teams.

CRM Analytics Security Guide: Public groups are the preferred method for granting permissions to users across multiple roles.

Explanation:

When the sole manager of a CRM Analytics app leaves the company, their user record will eventually be deactivated. Deactivating the user removes their access and can cause the app to become orphaned—with no active manager to administer it (e.g., rename the app, manage members, edit settings). To prevent this, the consultant must proactively assign an active user as the app's manager while the departing manager is still active. This ensures a smooth transition and uninterrupted app management. The app's manager can be updated via the app's settings or folder sharing permissions.

Why the others are wrong:

B (Deactivate the user and assign an active one):
Deactivating the manager before assigning a new manager is risky. Once deactivated, the user may no longer appear in selection lists, and the app could become orphaned, requiring Salesforce Support intervention to recover. The correct order is assign first, then deactivate.

C (Auto-assign):
CRM Analytics does not have an auto-assignment feature for app managers. This must be done manually.

References:

Salesforce Help – "Manage App Permissions": States that an app must have at least one active manager; deactivating the sole manager requires reassignment beforehand.

CRM Analytics Administration Guide: Recommends updating app managers before user deactivation.

Explanation:

When embedding a CRM Analytics dashboard via the Analytics Dashboard Lightning component on a record page or Lightning page, you can control component visibility using standard Salesforce Lightning page assignment rules (filters). These rules determine which users or profiles see the component on the page. In this scenario, the System Administrator can see the dashboard and data, but the Contract Manager sees a completely blank Lightning page (not an error or empty dashboard). This indicates that the Lightning component itself is not rendered for the Contract Manager—meaning the component's visibility filter was configured to show it only to System Administrators (or to users with a specific profile/permission set that the Contract Manager lacks). The component is hidden entirely, not just the data.

Why the others are wrong:

B (Dashboard filter condition for data):
If data filtering were the issue, the Contract Manager would see the dashboard layout (titles, headers, widgets) but with no data or an empty chart. A blank page suggests the component is not loaded at all, not that data is hidden.

C (Hide on Error):
The "Hide on Error" feature hides the widget or dashboard only when an error occurs (e.g., query failure). It does not cause a blank page for specific users; it would show an error message or hide the widget conditionally. The Contract Manager sees a blank page, not an error.

References:

Salesforce Help – "Lightning Component Visibility": Explains how to set component visibility based on user profiles, permissions, or criteria.

CRM Analytics Dashboard Component Guide: Component visibility is separate from data security.

Explanation:

In CRM Analytics dashboards, incorporating blank space (whitespace) improves readability and visual hierarchy. There are two primary declarative ways to achieve this:

Use the "Cell Spacing" layout property :– This adds padding/gaps between widgets in the dashboard grid, creating consistent breathing room around each component.

Increase the dashboard granularity via columns: – By setting a higher number of columns (e.g., 12 or 24), you create a finer grid. You can then insert blank columns (by leaving cells empty) to add intentional whitespace between widgets.

These methods give you full control over spacing without needing custom CSS or complex workarounds.

Why the others are wrong:

B (Fine row height + blank rows + "With Spacing" property):
"Fine" row height and "With Spacing" are not standard layout properties in CRM Analytics dashboards. The correct row-related properties are row height (small/medium/large) and auto-height.

C (Increase columns + blank columns + pages):
While increasing columns and using blank columns is correct, using pages to break content into multiple tabs creates page separation, not blank space within a page. Pages are for organizing content, not for adding whitespace.

References:

Salesforce Help – "Dashboard Layout Properties":: Cell Spacing and column granularity are documented methods for adding whitespace.

CRM Analytics Dashboard Designer Guide:: Blank columns and cell spacing are the recommended approaches for whitespace.

Explanation:

In CRM Analytics, app permissions are controlled by access levels on the app's folder or the app itself. The three main levels are:

Manager – Full control, including renaming the app, editing app properties, managing members, and deleting the app.

Editor – Can create, edit, and delete dashboards, lenses, and datasets within the app, but cannot rename the app or manage app-level settings.

Viewer – Read-only access; cannot edit or rename anything.

Since the user can access dashboards, lenses, and datasets (meaning they have at least Editor or Viewer access) but cannot rename the app, they lack Manager-level permissions on that specific app. The consultant should grant the "Manager" permission set or folder access to resolve this.

Why the others are wrong:

B (App name cannot be changed): This is false. App names can be changed at any time by users with Manager access.

C (User does not have Editor access): If the user lacked Editor access, they would not be able to edit dashboards or lenses either. Since they can access and edit content (implied), they have Editor rights, but that does not include renaming the app.

References:

Salesforce Help – "App Permissions in CRM Analytics":Lists Manager, Editor, and Viewer roles and their capabilities.

CRM Analytics Security Guide: Renaming an app requires Manager access.