Productivity and Collaboration practice questions

Create a custom report type.

Why it fails: Custom report types define the record relationships and fields available for reporting but do not inherently provide the visualization capabilities required for a manager's dashboard. While necessary for data collection, they require an additional step of building a dashboard component to effectively display the lead metrics graphically.

Configure a dynamic dashboard.

Why it fails: Dynamic dashboards allow viewers to see data based on their own security settings, which is useful for individual performance, but a standard dashboard is sufficient for tracking campaign-level metrics. The primary requirement is visualization of lead counts, not necessarily the specific security-based visibility provided by dynamic dashboard features.

Enable Chatter feed tracking on the Lead object.

Why it fails: Chatter feed tracking provides a chronological history of changes to specific fields but does not support the aggregate visualization or quantification of lead generation trends over time. It is a collaboration tool rather than an analytical tool, making it ineffective for high-level management performance monitoring or trend analysis.

Opportunities

Why it fails: Opportunities are a core sales object used for tracking potential revenue deals, not an activity type. While activities can be related to opportunities, the opportunity object itself exists independently and is designed to manage the sales pipeline rather than daily user productivity tasks.

Cases

Why it fails: Cases are a service object used to track customer support inquiries or issues. While users often log activities on cases to describe actions taken to resolve the issue, a Case itself is a record of a problem, not an activity type used for scheduling.

The user does not have permission to view the Task object.

Why it fails: If the user lacked permission, they would likely see an 'Insufficient Privileges' error rather than a 'No Results' message. A report returning zero results implies the user has access to run the report, but the filtering criteria are failing to match any actual records in the database.

The tasks were deleted by the system administrator.

Why it fails: While data deletion would explain a lack of results, it is an unlikely scenario for a manager attempting to run a report. The exhibit points specifically to a filtering context, suggesting a configuration mismatch rather than a data loss event, which would be indicated by other system errors.

The report format is set to 'Summary' instead of 'Tabular'.

Why it fails: The report format dictates how data is displayed, not whether data is retrieved. A summary report would still show data if the filtering criteria were met; the format of the report has no bearing on the underlying query's ability to locate and return records based on date.

Automatic PC synchronization

Why it fails: There is no 'automatic PC synchronization' feature in the mobile app. The mobile app syncs with the Salesforce server, not directly with a user's local PC. This is a distractor as it refers to a non-existent architectural capability that does not relate to mobile productivity.

Full Desktop Website View

Why it fails: Forcing the full desktop website view on a mobile device is detrimental to productivity. The interface is not touch-optimized, leading to poor user experience, slow loading times, and difficulty navigating with fingers. Mobile users should use the dedicated mobile app or mobile-optimized pages instead.

The Task status is still 'Open'.

Why it fails: An open task status is the correct state for a pending reminder. If the task were already 'Completed', the system would stop issuing reminders. Therefore, the open status is actually the correct configuration for receiving a notification, not a cause for the failure.

The Reminder Date is in the future.

Why it fails: A reminder date in the future is perfectly valid. The system is designed to wait until that date to trigger the alert. If the user expects a reminder before the date, that is a logic error, but a future date itself does not prevent the eventual notification.

The activity type is a 'Call'.

Why it fails: The activity type ('Call') is irrelevant to the reminder functionality. Salesforce allows reminders for all task types, including calls, meetings, and emails. The type of activity does not restrict the system's ability to trigger a reminder if the notifications are properly configured and enabled.

Create a custom object for documentation.

Why it fails: Creating a custom object for documentation creates a disconnected data silo that lacks the advanced search, versioning, and publishing workflows inherent in the Salesforce Knowledge platform. This approach would require significant manual maintenance and custom coding, which is inefficient compared to utilizing the native, purpose-built Knowledge solution.

Hard-code links in a formula field.

Why it fails: Hard-coding links in formula fields is a brittle practice that becomes difficult to maintain when document URLs change. Furthermore, this method does not provide context-sensitive suggestions and requires manual updates every time a new document is released, making it an unsustainable strategy for long-term knowledge management and collaboration.

Use the Salesforce Content Delivery network.

Why it fails: The Content Delivery Network is a mechanism for distributing web content and static assets, not a tool for managing contextual business documentation within the Salesforce UI. While it is useful for performance, it does not provide the search-driven, record-linked functionality required for surfacing Knowledge articles within the Opportunity page.

Create a workflow rule on the FeedItem object that sends an email to all group members whenever a new post is created.

Why it fails: This fails because workflow rules cannot be created on the FeedItem object. Chatter posts are not standard objects that support workflow rules. While you can use Flow or Apex triggers to react to FeedItem, the requirement is met by native Chatter email settings, not by a workflow rule, which is not supported here.

Enable 'Allow Email Notifications' in the Chatter group settings and set the group's default email frequency to 'Daily Digest'.

Why it fails: This is insufficient because group settings alone do not control individual email delivery. Even if the group allows email notifications, each user must opt in via their personal Chatter settings. A daily digest would also not provide immediate email notifications for each post, which the scenario implies by 'whenever a sales rep posts'.

Assign the 'Chatter Moderator' permission set to all group members so they can receive email notifications for every post.

Why it fails: This is wrong because the Chatter Moderator permission set is for moderating flagged posts and managing group content, not for enabling email notifications. Email notification settings are user-specific preferences, not permission-set-driven. Assigning this would not affect whether members receive emails for posts.

Private Group

Why it fails: A Private Group restricts visibility to members only, so posts are not visible to everyone in the group if non-members cannot see them. The scenario requires all posts to be visible to everyone in the group, which is possible, but the group is not public. Since the manager wants a public group, Private Group does not satisfy the public visibility requirement.

Unlisted Group

Why it fails: An Unlisted Group is not searchable and only members can see it, so it does not meet the requirement of being public. Additionally, membership management is typically open to all members, not restricted to managers. This group type is designed for private collaboration, which contradicts the need for a public group with manager-only membership control.

Public Group

Why it fails: A Public Group in Chatter is visible to all users, but any member can add other members, not just managers. The requirement that only group managers can add or remove members is not met. Additionally, Public Groups do not have the same moderation controls as other group types, so this choice fails the membership control criterion.

Add the standard 'New Task' action to the Chatter publisher and instruct the user to manually copy the post content and set the due date.

Why it fails: The standard 'New Task' action does not automatically prefill the subject with the Chatter post content or set a relative due date. It would require manual copying and date entry, which does not meet the automation requirement. The user needs a more efficient, automated solution.

Create a custom Quick Action on the User object that creates a Task with predefined due date and subject.

Why it fails: A Quick Action on the User object would create a task related to the user, not to the Chatter post, and cannot dynamically pull the post content into the subject. This does not meet the requirement of creating a follow-up task directly from a post with prefilled content and a relative due date.

Enable the 'Create Task from Chatter Post' setting in Chatter Settings and set default due date to 3 days.

Why it fails: There is no standard 'Create Task from Chatter Post' setting in Chatter Settings. While Chatter actions can be customized, this specific toggle does not exist. The administrator must use a different approach, such as a custom Chatter action or a flow, to achieve the desired behavior.

Create a Chatter group for each Account and add all sales reps as members.

Why it fails: Chatter groups are useful for team collaboration, but they are not tied to a specific Account record. Creating a group per Account would not automatically surface that record's feed on the Account page, and it adds unnecessary administrative overhead for the requirement described.

Enable Chatter for the Account object in Setup.

Why it fails: Chatter is enabled at the organization level, not per object. Once Chatter is on, feeds are available for all objects that support them. Enabling it for Account specifically is not a separate setting, so this step would not accomplish the goal here.

Grant the 'Chatter Internal User' permission set to all sales reps.

Why it fails: The Chatter Internal User permission set controls whether users can access Chatter features, but it does not place a feed on a record page. Even with this permission, the Account layout would still lack the component needed to show posts and updates for that record.

Disable the 'Allow Customer Invitations' setting in Chatter settings.

Why it fails: This setting controls whether customers can be invited to Chatter, not the visibility of individual posts. Disabling it would not affect existing external members or hide the specific post from them, and it could disrupt other intended collaboration with customers.

Create a new Chatter group that excludes external users and ask the rep to post there.

Why it fails: Creating a separate group would hide the post from external users, but it also removes the post from the original conversation context. The requirement is to keep the post in the existing group while limiting visibility, so a new group is an unnecessary workaround that changes collaboration flow.

Change the group's access type to 'Private' so external users cannot see any posts.

Why it fails: Changing the group to Private affects who can join and see the group, but external members who are already in the group would still see posts unless the post itself is restricted. This does not selectively hide a single post from external users while keeping it visible to internal members.

Activity Timeline on each record

Why it fails: The Activity Timeline is specific to a single record, such as an opportunity or account. It does not provide a consolidated view across all records for a team. The manager would have to visit each record individually, which is inefficient and does not allow filtering by owner or date globally.

Activities List View on the Home page

Why it fails: The Activities List View on the Home page shows only the current user's activities, not the entire team's. It cannot be filtered by owner to see other users' activities. This does not meet the manager's need to view all team activities across multiple records.

Activities Dashboard component

Why it fails: There is no standard 'Activities Dashboard component' that lists activities. Dashboards display aggregate data, not individual activity records. While you can create custom reports and dashboards, they do not provide the interactive list view with filtering that the manager needs for daily management.

The file was shared with the group but the user's Chatter group membership is not yet active due to a pending invitation.

Why it fails: If the user is a member of the group, membership is active unless she was invited but has not accepted. However, the scenario states she is a member, so this is not the cause. Pending invitations would mean she is not yet a member, contradicting the given information.

The file was uploaded to a library that the user does not have access to, and group sharing does not apply to library files.

Why it fails: Salesforce Files can be shared with groups even if they are in a library, provided the user has access to the library. If the user lacks library access, she might not see the file, but the scenario does not mention libraries. The more likely cause is record-level access when the file is linked to a record.

The file's sharing setting was changed to 'Shared with the group' but the group's access to the file was later removed by the file owner.

Why it fails: If the group's access was removed, the file would no longer be shared with the group, but the scenario says the file is marked as 'Shared with the group'. This option contradicts the stated condition. The file's sharing setting is still with the group, so removal is not the issue.

Create public Chatter groups for each department to encourage open communication.

Why it fails: Public groups allow all users to see and join, which can increase noise and potentially expose information to unintended users. While they can encourage communication, they do not enhance security. For a large organization aiming to reduce noise and maintain security, public groups are not the best choice; private or unlisted groups would be more appropriate.

Use permission sets to grant the 'Modify All Data' permission to Chatter moderators.

Why it fails: Granting 'Modify All Data' is excessive and a security risk. Chatter moderators need specific permissions like 'Moderate Chatter' or 'Manage Chatter Messages', not broad data modification rights. This action would violate the principle of least privilege and could lead to unintended data changes, so it is not recommended.

Set the organization-wide default for Chatter to Private.

Why it fails: Chatter does not have a separate organization-wide default setting like other objects. Chatter visibility is governed by sharing settings and permissions. Setting a 'Private' default is not a valid configuration for Chatter, so this action cannot be taken. It is a common misconception that Chatter has its own OWD.

Change the owner of each task and event to the other rep using a mass update.

Why it fails: Mass updating ownership would transfer the records permanently, and the original rep would lose visibility and ownership. The requirement is temporary redirection during vacation, so a mass update is too broad and does not automatically revert when the rep returns.

Create a workflow rule that reassigns tasks and events when the owner is out of office.

Why it fails: Workflow rules cannot be triggered by a user being out of office, and they do not operate on events in the same way as tasks. This would require custom logic and does not provide the built-in temporary delegation that the scenario needs.

Enable 'Out of Office' in the user's personal settings to auto-forward tasks and events.

Why it fails: The 'Out of Office' setting in personal settings creates an automated response for case and lead assignments, but it does not redirect tasks and events. It is designed for case and lead routing, not for the vacation delegation of activities described here.

The related list is not included in the Lightning page layout.

Why it fails: In Lightning Experience, related lists are added to the page layout, but they are displayed via the Related Lists component on the Lightning page. If the Related Lists component is not added to the Lightning page, the related lists will not appear. However, the scenario states that the administrator checked the page layout and confirmed the related list is added. The issue could be that the Lightning page does not include the Related Lists component, but the question specifies the page layout, not the Lightning page. The most likely reason is profile permission.

The user does not have 'Read' permission on the Activity object.

Why it fails: While read permission on the Activity object is necessary to view activities, if the user lacked it, they would likely see an error or the related list would be completely hidden. However, the more common reason for a related list not appearing is that the user's profile does not have permission to view the related list itself, or the related list is not included in the page layout assigned to the user. In this scenario, the administrator confirmed the related list is on the page layout, so the issue is likely due to the user's profile lacking access to the related list.

The user does not have 'Read' permission on the Opportunity object.

Why it fails: If the user lacked read permission on the Opportunity object, they would not be able to access the Opportunity record at all, not just the Activities related list. Since the user can view the Opportunity page, they must have read access to the Opportunity. Therefore, this is not the reason the related list is missing. The issue is specific to the related list visibility, which is controlled by profile permissions on the related list.

Einstein Activity Capture

Why it fails: Einstein Activity Capture automatically syncs emails and events, but it does not create follow-up tasks based on call completion. It is designed for automatic activity logging, not for conditional task creation. Therefore, it cannot fulfill the requirement of generating a follow-up task with specific assignment and due date logic.

Workflow Rule with a Task creation action

Why it fails: Workflow Rules can create tasks, but they are triggered by record changes, not by the completion of a call activity. Calls are typically logged as tasks or events, and workflow rules on the Task object could create tasks, but they cannot easily reference the related account and assign to the call owner with a dynamic due date. Workflow Rules are also being retired in favor of Flow. This option is less suitable than a Flow-based solution.

Process Builder with a scheduled action

Why it fails: Process Builder can automate tasks, but it is also being retired and replaced by Flow. While it could potentially create a task, the complexity of linking to the account and setting a due date based on the call completion date would be cumbersome. Process Builder lacks the flexibility of Flow for this scenario, and Salesforce recommends migrating to Flow.

Add the 'Files' related list to the Opportunity page layout and instruct the user to refresh the page frequently.

Why it fails: Adding the Files related list allows users to see files when they view the opportunity, but it does not generate notifications. The user would have to manually check the opportunity. This does not meet the requirement of being notified when a new file is added.

Create a workflow rule that sends an email alert to the opportunity owner when a file is added.

Why it fails: Workflow rules cannot trigger on file additions because files are not standard objects that support workflow. Email alerts would also not provide in-app Salesforce notifications. This approach is technically infeasible and does not address the user's need for a Salesforce notification.

Instruct the user to enable 'File notifications' in her personal Chatter settings.

Why it fails: There is no 'File notifications' setting in personal Chatter settings. Chatter notifications are controlled by following records and users, and by the types of updates. File additions may generate a post in the feed, but there is no specific toggle for file notifications. This option does not exist and would not meet the requirement.

Set the organization-wide default for Chatter to Private.

Why it fails: Chatter does not have organization-wide defaults; sharing settings apply to records, not Chatter posts. Chatter visibility is controlled by group access and record sharing. Setting a non-existent 'Chatter default' would not secure data and is not a valid configuration in Salesforce.

Use a Chatter stream to filter out sensitive posts.

Why it fails: Chatter streams aggregate posts from multiple sources into a personal feed, but they do not filter out sensitive content for security purposes. Streams are a viewing tool, not a permission or data protection mechanism. They cannot prevent users from seeing posts they have access to.

Disable the 'Allow Posts' permission for all users.

Why it fails: Disabling posts entirely would prevent collaboration, which contradicts the goal of enabling users to collaborate on records. The requirement is to collaborate securely, not to eliminate posting. This action is too restrictive and does not address sensitive data exposure in a balanced way.

Review the user's Profile object permissions.

Why it fails: Object permissions control the ability to create, read, edit, or delete records, but they do not control the visibility of a related list component on a specific page layout. An administrator would only need to check these if the user could not see the Opportunity records entirely.

Examine the Organization-Wide Defaults for Activities.

Why it fails: Organization-wide defaults control the baseline security and record-level access for sharing data. These settings govern whether a user can see a specific record, but they do not dictate whether a related list component exists or is visible on the UI layout for an object record page.

Verify the user has 'Edit' access to the Opportunity.

Why it fails: Edit access allows a user to modify field values on the Opportunity record itself, but it does not dictate the presence of UI elements like related lists. Even with read-only access, a user should still be able to see the related list if it is configured on the layout.