Salesforce-Slack-Administrator Practice Test Questions

Explanation:

💬 Slack Connect DM Permissions & Restrictions
✅ Correct Answer: C. Alpha Corp users cannot DM anyone from Beta Corp since Slack Connect DMs are disabled.

✅ C. Alpha Corp users cannot DM anyone from Beta Corp since Slack Connect DMs are disabled
If Slack Connect DMs are disabled at the organizational level, no direct messages can be exchanged between members of different organizations, even if they share Slack Connect channels. The Slack Connect channel still allows communication, but only within that channel. This restriction is global and applies to all users, regardless of role, workspace, or membership. The CIO should be reassured that the security setting is enforced at the system level and cannot be bypassed without administrative changes.

🚫 A. Alpha Corp users can DM any Beta Corp users that are in the same Slack Connect channels as they are
This is incorrect because participation in a Slack Connect channel does not automatically grant the ability to send Slack Connect DMs. The ability to start a DM with an external user is governed by a separate setting, and in this case, it has been explicitly disabled. Even if two users are in the same channel, the "Message" button to initiate a DM will be unavailable.

🚫 B. Alpha Corp users can DM any Beta Corp users now that the two organizations have been connected
Merely connecting organizations in Slack Connect does not automatically open DM capabilities. The DM function is an additional, optional feature that must be enabled by Org Owners/Admins in both organizations. Since it is disabled here, no DMs can be sent, regardless of the fact that Slack Connect is in place.

🚫 D. Workspace Admins can give access to specific Alpha Corp users to DM with Beta Corp
This is misleading because Slack Connect DM permissions are controlled org-wide by the Org Owner (in Enterprise Grid) or Workspace Owner (in other plans). You cannot bypass the disabled setting by granting individual permissions. This setting is a blanket restriction—either all allowed users can DM external contacts, or no one can.

📚 Reference: Slack Help – Manage Slack Connect Direct Messages

Explanation:

Tam Corp, with 500 employees across global teams (sales, engineering, support, human resources) and 15 software versions, is transitioning from two Slack Plus plan workspaces to an Enterprise Grid plan. Currently, one Plus workspace is organized by team (e.g., #sales-team, #engineering-team, #support-team), and the other is for recruiting and leadership discussions. Leadership wants minimal disruption to existing communication patterns. The Enterprise Grid plan supports multiple interconnected workspaces, allowing flexible structures for cross-functional collaboration. Let’s evaluate each option to find the structure that aligns with leadership’s goal and enables effective team communication:

Option A: Create workspaces for each department and sub-department in the company.
This approach would create separate workspaces for every department (e.g., Sales, Engineering, Support, HR) and their sub-departments (e.g., Sales-NorthAmerica, Sales-EMEA). With 500 employees and potentially dozens of sub-departments, this could result in an overly fragmented structure, with 20+ workspaces. This would disrupt current communication patterns, as teams would need to navigate multiple workspaces, and cross-functional collaboration (e.g., Sales and Engineering) would require frequent Slack Connect or shared channels, increasing complexity. It also deviates from the current setup, where teams operate in a single workspace with team-specific channels, violating leadership’s desire for minimal impact.
➜ Why it’s incorrect: Overly granular workspaces complicate communication and disrupt the existing team-based structure.

Option B: Create workspaces for each product line sold, where each workspace is the "primary" workspace for the employee.
Creating a workspace for each of Tam Corp’s 15 software versions (e.g., ProductA, ProductB) would align teams around products but assumes employees work primarily on one product. With 500 employees across sales, engineering, support, and HR, most employees (e.g., HR or leadership) don’t focus on a single product, and even Sales or Engineering may support multiple products. This structure would fragment communication, forcing employees to join multiple workspaces for cross-product or cross-functional work, disrupting the current team-based channel structure (e.g., #sales-team). It also ignores the recruiting/leadership workspace, creating a significant shift from current practices.
➜ Why it’s incorrect: Product-based workspaces don’t reflect current team-based communication and would disrupt workflows for non-product-specific teams.

Option C: Create workspaces based on how information is shared, and where employees have one "primary" workspace where they spend 80% of their time. (Correct Answer)
This approach involves designing workspaces around communication patterns, mirroring the current Plus plan structure. For example, Tam Corp could create:

✔ A Team Workspace for department-based collaboration (e.g., Sales, Engineering, Support), maintaining channels like #sales-team, #engineering-team, and #support-team.
✔ A Leadership & Recruiting Workspace for HR and leadership discussions, preserving the second Plus workspace’s purpose.
✔ Optionally, a Global Workspace for org-wide announcements or cross-functional collaboration (e.g., #all-hands, #product-updates).

Employees would have a “primary” workspace (e.g., Sales employees in the Team Workspace, HR in the Leadership & Recruiting Workspace) where they spend most of their time, aligning with the 80% guideline. Shared channels or Slack Connect can facilitate cross-workspace collaboration (e.g., #sales-engineering shared between workspaces). This structure minimizes disruption by closely resembling the current setup, supports team-based communication, and leverages Enterprise Grid’s flexibility for cross-functional work, satisfying leadership’s goal.

➜ Why it’s correct: It preserves existing communication patterns, aligns workspaces with team functions, and ensures effective collaboration with minimal disruption.
➜ Additional notes: The “80% primary workspace” concept ensures focus while allowing employees to join secondary workspaces or shared channels as needed.

Option D: Create one workspace, where each product line sold has its own channel.
Consolidating all 500 employees into a single workspace with channels for each of the 15 product lines (e.g., #productA, #productB) simplifies the structure but overlooks the current team-based and recruiting/leadership separation. This would force all communication—team-specific, leadership, recruiting, and product-related—into one workspace, leading to channel overload (potentially hundreds of channels) and reduced discoverability. It disrupts the existing setup, where teams have dedicated channels in one workspace and leadership/recruiting in another, and makes it harder for employees to focus on their primary roles (e.g., HR managing recruiting, not product lines). Cross-functional collaboration would also suffer due to the lack of workspace-level separation.
➜ Why it’s incorrect: A single workspace with product-based channels disrupts team-based communication and overwhelms users with irrelevant channels.

Additional Considerations:
➡️ Minimal Disruption: Option C aligns with the current two-workspace structure by mapping the Team Workspace to the team-based Plus workspace and the Leadership & Recruiting Workspace to the second Plus workspace, ensuring continuity.
➡️ Cross-Functional Collaboration: Shared channels (e.g., #sales-engineering) or a Global Workspace can connect teams across workspaces, supporting Tam Corp’s global operations.
➡️ Scalability: With 500 employees and 15 products, Option C allows flexibility to add workspaces (e.g., for specific projects) while maintaining the core structure.
➡️ Implementation: Use Slack’s migration tools to transition channels and data from Plus to Enterprise Grid, and educate teams on using primary workspaces and shared channels. Monitor engagement via the Org analytics dashboard.

Summary:
The best structure is Option C, creating workspaces based on how information is shared (e.g., Team Workspace for departments, Leadership & Recruiting Workspace, and potentially a Global Workspace), with employees having a primary workspace for 80% of their time. This mirrors the current Plus plan setup, minimizes disruption, and supports effective team communication. Options A and B create overly fragmented structures, while Option D oversimplifies and disrupts team-based workflows.

References:
➟ Slack Help Center: Slack Enterprise Grid Overview
➟ Salesforce Trailhead: Slack Enterprise Grid Administration
➟ Slack Help Center: Shared Channels in Enterprise Grid

Explanation:

Correct Answer: B. Ask the employees to post their own question in a public #help channel, where Jose and his team will respond in thread.

Why This Is the Best Approach:

1. Promotes Self-Service & Transparency
Encourages employees to use public channels (like #help) instead of DMs, making answers searchable for others.
Reduces duplicate questions—future employees can find solutions in the channel history.

2. Scales Support Efforts
Jose’s team can respond once in a thread, benefiting everyone (vs. repeating answers in DMs).
Aligns with Slack’s best practices for public collaboration.

3. Empowers Employees
Teaches users to ask in the right place, fostering long-term adoption of Slack norms.

Why the Other Options Are Less Effective:

A. "Ask, then post for them": Still trains employees to rely on Jose instead of learning to use #help themselves.

C. "Post on their behalf": Creates dependency—employees won’t learn to engage in public channels independently.

D. "Respond via DM":
Worst option: Encourages DM culture, hides solutions from others, and doesn’t scale.
Contradicts Slack’s guidelines on reducing DM overload.

Pro Tip for Jose:
Pin common answers in #help (e.g., "How to connect apps") to further reduce repetitive questions.
Use emoji reactions (e.g., ✅) to mark resolved threads, making it easy to scan for solutions.

Reference:
Slack’s Guide to Public Channels
Why Public Channels Beat DMs

Explanation:

✅ B. Utilize bulk channel lifecycle management APIs
For an enterprise with around 1,000 channels to manage during a cleanup, Slack’s channel lifecycle management APIs (such as conversations.archive, conversations.delete, and conversations.rename) are the most efficient and scalable choice. These APIs allow you to script and automate large-scale operations, avoiding the need to perform them manually. This is especially important in Enterprise Grid environments, where consistency, accuracy, and time efficiency are critical. You can run bulk operations programmatically, apply set criteria, and maintain audit logs for compliance.

🚫 A. Use Slack's channel management tools
While Slack offers built-in channel management tools within the Admin Console, these are best suited for smaller-scale operations or one-off changes. They provide useful search and filter features, but there’s no bulk execution capability at the scale of 1,000 channels. Performing each change manually using these tools would be time-consuming and prone to human error, making them less effective for large-scale cleanup efforts.

🚫 C. Take action from each channel's settings
Editing or archiving channels individually from their channel settings is the most manual and inefficient approach, especially when working with hundreds or thousands of channels. This process is labor-intensive, slow, and increases the likelihood of missing certain channels or applying inconsistent rules. It’s better suited for occasional changes to one or two channels, not a mass cleanup operation.

🚫 D. Request that each channel owner take action
Relying on each channel owner to manually archive or delete their own channels introduces delays, inconsistency, and potential non-compliance with your cleanup policy. In a large enterprise, not all channel owners will act promptly, and some may not even be active users. Centralized control through APIs ensures that your cleanup happens according to schedule and with uniform application of your set criteria.

📚 Reference: Slack API – Conversations Methods

Explanation:

For a 5,000-employee company with international offices launching Slack to enhance collaboration and company culture, the CIO’s concern about custom emoji uploads centers on balancing creative expression with preventing inappropriate content, while minimizing the administrative burden on the Workspace Admin team. The Enterprise Grid plan, suitable for a company of this size, offers granular controls for managing custom emoji. Let’s evaluate each option to find the best solution:

Option A: Allow all members access to upload custom emoji, but communicate and document the appropriate emoji use and uploads. (Correct Answer)
Allowing all members to upload custom emoji fosters creativity and engagement, aligning with the goal of building a stronger company culture. Custom emoji can reflect team identities, humor, or cultural nuances across international offices, encouraging collaboration. To address the CIO’s concerns about inappropriate uploads, clear guidelines (e.g., no offensive or copyrighted images) can be communicated via a pinned post in a #general channel, a Slack onboarding workflow, or company documentation. Slack’s Enterprise Grid allows admins to monitor and remove inappropriate emoji via the admin dashboard (under Customize Slack > Emoji) without significant burden. This approach avoids overloading the admin team with requests while empowering employees, with oversight to ensure compliance.
➜ Why it’s correct: It promotes culture and collaboration, addresses inappropriate content through guidelines and monitoring, and minimizes admin workload.
➜ Additional notes: Use Slack’s audit logs to track emoji uploads and integrate with Data Loss Prevention (DLP) tools to flag inappropriate images if needed.

Option B: Prior to launch, pre-load a set of custom emoji voted on by a council of leaders, and do not allow anyone to request custom emoji uploads.
Pre-loading a set of leader-approved emoji ensures control over content but stifles employee creativity and engagement, which could hinder the goal of building a collaborative culture. With 5,000 employees across international offices, a small set of emoji may not reflect diverse team identities or needs, reducing adoption. Prohibiting requests for custom emoji uploads places the burden on admins to anticipate all emoji needs, which is impractical and could lead to dissatisfaction. This approach also misses the opportunity to leverage emoji as a fun, inclusive tool for global teams.
➜ Why it’s incorrect: It limits cultural expression, may not meet diverse needs, and could still burden admins with future emoji demands.

Option C: Do not allow any custom emoji creation to minimize the risk of members uploading inappropriate imagery.
Banning custom emoji eliminates the risk of inappropriate uploads but significantly undermines the goal of building a stronger company culture. Custom emoji are a popular Slack feature that encourages fun, personal expression, and team bonding, especially in a large, global organization. Prohibiting them could reduce Slack’s appeal, hinder adoption, and make the platform feel rigid, countering the collaboration objective. While this option requires no admin oversight for emoji, it sacrifices a key cultural tool and doesn’t address the CIO’s concern about admin burden, as it’s an overly restrictive solution.
➜ Why it’s incorrect: It stifles creativity and culture, missing the goal of enhancing collaboration.

Option D: Restrict custom emoji uploads to Workspace Owners and Admins, and do not allow anyone to request custom emoji uploads.
Restricting emoji uploads to Workspace Owners and Admins ensures tight control over content but places the entire burden on the admin team to create and manage emoji, directly contradicting the CIO’s goal of avoiding admin overload. With 5,000 employees, the lack of a request process would likely lead to informal requests via messages or emails, creating administrative chaos. This approach also limits employee engagement, as only admins can contribute emoji, reducing the sense of ownership and cultural connection across international teams.
➜ Why it’s incorrect: It burdens admins and restricts employee participation, hindering collaboration and culture.

Additional Considerations:
✔ Enterprise Grid Controls: In Enterprise Grid, admins can manage custom emoji via the admin dashboard, removing inappropriate ones quickly. Audit logs track emoji uploads, providing accountability.
✔ Cultural Sensitivity: For international offices, guidelines should emphasize culturally appropriate emoji to avoid missteps in a global workforce.
✔ Implementation: Use Workflow Builder to automate emoji guideline delivery during onboarding, and pin a policy in a #culture or #general channel.
✔ Monitoring: If concerns about inappropriate uploads persist, integrate a DLP tool to scan emoji images or periodically review uploads in the admin dashboard.

Summary:
Option A is the best solution, allowing all members to upload custom emoji to foster collaboration and culture, while addressing the CIO’s concerns through clear guidelines and admin oversight. This minimizes the admin team’s burden and ensures appropriate use via monitoring. Options B, C, and D either limit creativity, overburden admins, or fail to support the cultural goal.

References:
Slack Help Center: Custom Emoji in Slack Salesforce Trailhead: Slack Enterprise Grid Administration Slack Help Center: Audit Logs in Slack

Explanation:

In a Slack Enterprise Grid environment, the minimum role needed to perform certain actions depends on the scope and level of control required. Here's the breakdown for the given roles in relation to managing a specific workspace within the Grid:

Minimum Role Needed for Actions in a Specific Workspace:
➡️ Workspace Admin (C) → Can manage most settings within a single workspace (channels, members, apps, settings), but cannot manage org-wide settings or other workspaces.
➡️ Workspace Owner (A) → Similar to Workspace Admin but may have additional permissions depending on org settings. However, in Enterprise Grid, Workspace Admin is often sufficient for workspace-specific actions.
➡️ Org Admin (B) → Has org-wide control (manages workspaces, billing, org settings, etc.), which is more than needed for workspace-specific tasks.
➡️ Roles Admin (D) → Manages custom roles and permissions but is not required for basic workspace administration.

Answer: C
For actions limited to a single workspace (e.g., managing channels, members, or settings within that workspace), the **minimum required role is:

✅ C. Workspace Admin
If you need org-wide control (e.g., creating/deleting workspaces, managing billing), then B. Org Admin would be required. But for workspace-specific tasks, Workspace Admin is sufficient.

Explanation:

✅ A. Create an ordered list of conditional rules for app and integration approvals, enable custom approval status notifications to requesters, and create rules at both the Enterprise Grid and workspace level.
This option aligns perfectly with Slack’s App Approval Workflow capabilities in Enterprise Grid. An ordered list of conditional rules ensures that approvals are handled automatically based on predefined criteria, such as app category, security risk, or compliance requirements. Custom notifications to requesters improve transparency and reduce confusion, while rules at both the org and workspace levels provide flexibility—some approvals might need to be universal, while others can be workspace-specific. This approach strikes the right balance between centralized governance and local autonomy, ensuring efficient yet controlled app adoption.

🚫 B. Create a list of trusted members for app and integration approvals, enable custom approval status notifications to approvers, and create rules at both the Enterprise Grid and workspace level.
While having a list of trusted members can be useful, it doesn’t scale well for automation. It relies on individuals manually reviewing requests rather than using rules to process them automatically. Notifications to approvers instead of requesters can also delay feedback to the people who need the apps. Although this option mentions rules at both the org and workspace level, the lack of an ordered, conditional rule system limits automation potential.

🚫 C. Create rules to approve apps and integrations based on their licensing cost, enable custom approval status notifications to requesters, and create rules at the workspace level.
This approach is too narrow because it focuses only on licensing cost as the approval criterion, ignoring critical factors such as security risk, compliance, or app functionality. Limiting rules to the workspace level also removes org-wide governance, which is essential in Enterprise Grid environments. While notifying requesters is good, this option lacks the flexibility and comprehensive scope that a robust automated approval process requires.

📚 Reference: Slack Help – Manage app approvals in Enterprise Grid

Explanation:

To ensure all Slack data is archived and stored outside of Slack, Brian (an Org Owner) needs to take steps that comply with Slack's data retention and export capabilities. Here’s the breakdown of the options:

Correct Answer:
✅ A. Turn on Corporate Exports to retrieve private data and store it elsewhere.

✔ Corporate Exports (also known as Enterprise Grid EMM exports) allow Org Owners and Org Admins to export all workspace data, including public and private channels, direct messages, and files, in a format that can be stored externally (e.g., in a compliance or archival system).
✔ This is the primary method for legally compliant, full-data archiving in Enterprise Grid.

Why Not the Others?

B. Contact Slack to set retention policies to "Keep all messages" → This only retains data inside Slack but does not export it externally for archival.

C. Enable DLP and quarantine messages/files → DLP (Data Loss Prevention) helps block or redact sensitive data, but it doesn’t archive all Slack data externally.

D. Use a third-party eDiscovery app → While possible, this is not the native Slack solution and requires additional setup. Corporate Exports are the built-in, official method for full data export.

Steps for Brian:
1. Go to Org Settings (as an Org Owner).
2. Enable Corporate Exports (EMM exports).
3. Request exports as needed or set up automated exports to an external storage system.

Final Answer:
A. Turn on Corporate exports to retrieve private data and store it elsewhere.

Explanation:

🚫 A. It is not possible to create a custom workflow for your team in fewer than five clicks.
This is false because Slack’s Workflow Builder is designed to be quick and user-friendly. A simple workflow (like a welcome message in a channel) can be created in fewer than five clicks using built-in templates. The exam likes to test misconceptions like this—Slack intentionally makes workflow creation accessible to non-technical users, meaning it’s not a long or complicated process unless you’re building something advanced.

✅ B. Workspace Owners and Admins can view all published workflows created by members of their workspaces.
This is true. In Slack, Workspace Owners and Admins have the ability to view all published workflows that members have created within their workspace. This allows admins to manage workflow usage, ensure compliance with company guidelines, and assist with troubleshooting if needed. The viewing capability does not extend to all workspaces in an Enterprise Grid unless they are also admins in those specific workspaces.

✅ C. To see all workflows in a workspace, you need to be an Owner or Admin of that workspace.
This is also true. Regular members can only see workflows in channels they have access to, whereas Workspace Owners and Admins have visibility into all workflows within the workspace. This includes private-channel workflows (if they’re part of the channel) and public-channel workflows, ensuring admins maintain oversight.

🚫 D. It is currently possible for Org Owners and Admins to view all workflows created in an Enterprise Grid org.
This is false. Even in Enterprise Grid, Org Owners and Org Admins do not have a single unified dashboard showing every workflow across all workspaces. They would need to either check each workspace individually or rely on Workspace Admins to report. This is a common trap option in the exam.

📚 Reference: Slack Help – Create workflows in Slack

Explanation:

✅ B. Turn on app approval within the Manage Apps dashboard, and require end users to provide a comment for each installation request in the App Directory. Add the members of your team to the list of App Managers, and send all approval requests to a public #ffplz-apps channel.

Why This Works Best:
✔ Native App Approval Feature – Slack’s built-in "Require app approval" setting (under Manage Apps > Settings) ensures that no app is installed without review.
✔ Mandatory Comments for Requests – Enabling "Require a comment for app requests" forces users to provide a rationale for why they need the app.
✔ App Managers & Audit Trail – By assigning your team as App Managers, they can review requests. Sending approvals to a public #ffplz-apps channel creates a transparent audit log.
✔ No Manual Workarounds Needed – Unlike workflows or preapproval lists, this method is fully integrated into Slack’s permissions system.

Why Not the Others?
A. Preapproving common tools doesn’t enforce case-by-case review or rationale collection for new apps.
C. Restricting approvals to Workspace Owners only is too restrictive and doesn’t automate notifications as effectively as a public channel.
D. Using Workflow Builder is a manual workaround (not native app governance) and lacks direct integration with Slack’s approval system.

Steps to Implement:
Go to Settings & administration > Manage apps > Settings.

Enable:
✔ "Require app approval"
✔ "Require a comment for app requests"
Add your team as App Managers (under App Managers).
Set up a public channel (#ffplz-apps) for approval notifications.
This ensures compliance, transparency, and accountability while using Slack’s native features.

Final Answer: B