Explanation:

In Slack Enterprise Grid, workspaces are used to group people, channels, and apps within the same organization. However, creating too many workspaces leads to fragmentation and context switching, which harms user adoption and productivity.

Best practice is to:
Minimize the number of workspaces → so employees don’t have to constantly switch between them.
Use multi-workspace channels (shared channels across workspaces) to avoid silos and reduce duplication.
Keep workspace design consistent with corporate governance while balancing usability.
That’s why option C is the best approach: fewer, well-structured workspaces with shared channels for cross-team collaboration.

❌ Why the other options are incorrect:

A. Ensure the workspace design is loosely defined...
✗ Not recommended. Lack of structure leads to chaos, inconsistent experiences, and governance issues.

B. Define organization policies to prevent workspaces from differing...
✗ Policies are important, but being too rigid on workspace design can stifle flexibility and doesn’t directly solve context switching.

D. Create new workspaces instead of multi-workspace channels...
✗ The opposite of best practice. Multi-workspace channels are preferred for reducing noise while maintaining collaboration. Creating too many workspaces creates fragmentation.

📖 Reference:
Slack official guide: Slack Enterprise Grid: Workspace design
Slack Admin Docs: About Slack Enterprise Grid

Explanation:

B. Remove the user from all of their channels in bulk using the External People menu. ✅
Correct. This removes the offending user from your workspace’s shared channels, preventing further inappropriate messages, while still allowing the partner org relationship to continue with other users.

Other options:

🔴 A. Disconnect all shared connection points with the offensive user's organization using the Connections menu.
Not correct. Disconnecting the entire organization is extreme and would remove all collaboration with that partner, even with compliant users. Targeting the individual is more appropriate than punishing the whole org.

🔴 C. Mute the offensive user in each of the channels where they have membership using the channel Settings menu.
Not correct. Muting only hides messages for specific individuals; it doesn’t prevent the offending user from continuing to post inappropriate content, which is the core issue that needs resolving.

🔴 D. Encourage users who reported the messages to use the /leave slash command in each conversation with the offensive user.
Not correct. Asking victims to leave conversations doesn’t solve the root problem. The offensive user would still have access and could continue disruptive behavior, affecting other members.

📖 Reference: Slack Help: Manage external users in Slack Connect

permissions to manage users and channels with the fewest privileges, avoiding excessive access. Other roles either grant too much or too little authority.

✅ B) Workspace Admin
The Workspace Admin role on the Business+ plan grants permissions to manage users (e.g., inviting, deactivating) and channels (e.g., creating, archiving) within a single workspace, meeting the needs of the task with minimal privileges. Unlike Org Admin or Workspace Owner roles, which are relevant for Enterprise Grid or have broader access, Workspace Admin is tailored for Business+ and avoids granting unnecessary control. This aligns with the Salesforce Certified Slack Administrator Exam’s emphasis on assigning roles based on least privilege for effective governance and security.

Incorrect Answers:

✖️ A) Org Admin
Org Admin is specific to Enterprise Grid plans, not Business+, and grants organization-wide permissions across multiple workspaces. This exceeds the needs of managing a single workspace, violating the principle of least privilege for the Head of IT’s tasks.

✖️ C) Workspace Owner
Workspace Owner has broader permissions than Workspace Admin, including managing billing and workspace settings like SSO. This role grants more access than necessary for user and channel management, making it less appropriate than Workspace Admin.

✖️ D) Member
The Member role lacks administrative permissions, preventing the Head of IT from managing users or channels. Members can only participate in channels and use Slack features, making this role insufficient for the required duties.

Reference:
Slack Help Center: Roles and permissions in Slack
Salesforce Trailhead: Slack Admin Basics

Explanation:

As an Org Owner on a Slack Enterprise Grid instance, you need to address concerns about a former employee potentially exporting sensitive information before leaving. The security team’s knowledge of what the employee may have accessed suggests they need detailed evidence to confirm specific actions. Slack’s Enterprise Grid provides robust tools like audit logs to track user activity, which are critical for investigating such incidents. Below is a detailed evaluation of each option to determine the best course of action:

Option A: Revoke the encryption key with the Enterprise Key Management (EKM) feature so that the data from the former employee’s account is protected.
Slack Enterprise Key Management (EKM) allows organizations to manage their own encryption keys through AWS Key Management Service (KMS), providing control over data access. Revoking an encryption key can prevent access to encrypted data in Slack, such as messages and files, for users or apps relying on that key. However, this action is not directly relevant to investigating what a former employee may have accessed or exported. Revoking a key would not provide insights into past actions and could disrupt access for other users if not carefully managed. Additionally, EKM is more about controlling future access rather than auditing historical activity, which is the primary concern here.
➲ Why it’s incorrect: Revoking an encryption key does not help confirm what the former employee accessed or exported; it only restricts future access to encrypted data.
➲ Additional notes: EKM is a proactive security measure, useful for securing data post-incident, but it’s not a tool for investigating past user actions.

Option B: Use the member analytics dashboard to confirm the former employee’s account activity.
The member analytics dashboard (part of the Workspace or Org analytics dashboard in Slack) provides high-level metrics like Daily Active Users (DAU), Weekly Active Users (WAU), and general engagement trends. While useful for understanding overall workspace activity, this dashboard does not provide granular details about specific user actions, such as what data a former employee accessed or exported. It lacks the detailed audit trail needed to investigate specific activities like file downloads or message exports. For this scenario, you need a tool that logs individual user actions, not aggregate analytics.
➲ Why it’s incorrect: The member analytics dashboard offers broad usage statistics, not detailed access logs required to investigate specific actions by a former employee.
➲ Additional notes: The analytics dashboard is better suited for tracking workspace trends, not for forensic analysis of individual user activity.

✅ Option C: Export the former employee’s access logs from the admin dashboard. (Correct Answer)
Slack’s audit logs, available on Enterprise Grid, provide a detailed record of user and app activities, such as logins, file downloads, message postings, or data exports. As an Org Owner, you can access these logs through the admin dashboard to investigate the former employee’s actions. To do this:
✔ From the Slack desktop app, click your organization name in the sidebar.
✔ Navigate to Tools & settings > Organization settings > Security > Audit Logs.
✔ Use filters (e.g., Acting user, Event, Date range) to focus on the former employee’s activities.
✔ Export the logs as a CSV file for detailed analysis by clicking Export Logs in the top-right corner.

Audit logs include events like file downloads, app installations, or data exports, which are critical for confirming whether the former employee exported sensitive information. This approach directly addresses the security team’s need to verify specific actions and is the most effective way to investigate the concern.

➲ Why it’s correct: Audit logs provide a granular record of the former employee’s actions, allowing you to confirm what they accessed or exported, and can be exported for further analysis.
➲ Additional notes: Audit logs are available only on Enterprise Grid and can be filtered to focus on specific users or actions, making them ideal for this investigation.

Option D: Access your security information and event management (SIEM) tool to view actions logged by the former employee.
A Security Information and Event Management (SIEM) tool integrates with Slack’s Audit Logs API to collect and analyze audit log data for real-time monitoring and threat detection. While a SIEM tool can provide insights into user actions by ingesting audit logs, it assumes the organization has already set up the integration and configured the SIEM to collect Slack data. The question does not confirm that a SIEM tool is in use, and accessing audit logs directly from Slack’s admin dashboard is a more immediate and universally available option for an Org Owner. Additionally, the SIEM tool would rely on the same audit log data that can be exported directly from Slack, making it a secondary step rather than the primary action.
➲ Why it’s incorrect: While a SIEM tool can be useful, it’s not the most direct or guaranteed method, as it depends on prior integration setup. Exporting audit logs from the admin dashboard is more straightforward and accessible.
➲ Additional notes: If a SIEM is integrated, it could complement the investigation, but the first step is to access and export audit logs from Slack directly.

ℹ️ Additional Considerations:
➟ Immediate Action: Before investigating, ensure the former employee’s account is deactivated to prevent further access. This can be done via SCIM provisioning (if integrated with an IdP) or manually by an Org Owner in the admin dashboard under Manage members > Deactivate account.
➟ Audit Log Details: Audit logs capture actions like file_download, user_login, or export_initiated, but they do not include message content. If sensitive data was exported, you may need to cross-reference with Data Loss Prevention (DLP) tools or review channel access permissions.
➟ DLP Integration: If your organization uses a third-party DLP solution (e.g., Nightfall or Strac), it can detect sensitive data shared in channels or files, which could provide additional context for the investigation. However, this is supplementary to audit logs.
➟ Next Steps: After exporting and analyzing the audit logs, collaborate with the security team to identify any exported data and assess its sensitivity. If needed, use Slack’s eDiscovery tools or consult with Slack Support for a custom data export to review specific conversations or files.

🧩 Summary:
The best action is Option C: Export the former employee’s access logs from the admin dashboard, as it directly addresses the need to confirm what the former employee accessed or exported. Audit logs provide a detailed, exportable record of user actions, accessible to Org Owners on Enterprise Grid, making them the most effective tool for this investigation. Option A (revoking EKM keys) is proactive but not investigative, Option B (member analytics) lacks granularity, and Option D (SIEM tool) is less direct without confirmed integration. After exporting logs, ensure the former employee’s account is deactivated and consider DLP tools for further insight.

References:
Slack Help Center: Audit logs in Slack
Slack Engineering: Slack Audit Logs and Anomalies
Slack Help Center: Exports for Enterprise Grid
Slack Help Center: Security tips to protect your workspace

Explanation:

❌ A. Open

✖️ Why it's wrong:

Visibility: An "Open" workspace is visible to all members of the organization, fulfilling Requirement 1.

Approval: However, "Open" workspaces allow any member of the organization to join without requiring approval. This directly contradicts Requirement 2, where the group's leaders want to approve members.

❌ B. Invite Only

✖️ Why it's wrong:

Visibility: An "Invite Only" workspace is not visible to all members of the organization in the directory. Members must be explicitly invited by a Workspace Owner or Admin (or sometimes by other members if settings allow). This fails Requirement 1 ("visible to all members... so that they can volunteer to join").

Approval: While it gives control over who joins (via invitation), it doesn't allow for a "request and approve" workflow by the leaders if the workspace isn't discoverable.

✅ C. By Request

✔️ Why it's the Correct Answer:

This option perfectly aligns with both requirements.

Visibility: A "By Request" workspace is visible to all members of the organization in the workspace directory. This fulfills Requirement 1, allowing members to discover the ERG and express interest.

Approval: When a member sees a "By Request" workspace and wants to join, they submit a request. This request then goes to the Workspace Owners/Admins (who, in this case, would be the group's leaders delegated that authority, or who would process these requests on behalf of the leaders). The Owners/Admins then have the explicit "rights to approve any members before they join," fulfilling Requirement 2. This creates the desired controlled entry point with visibility.

❌ D. Hidden

✖️ Why it's wrong:

Visibility: A "Hidden" workspace is not visible to any non-member within the organization directory. It is the most restrictive visibility setting. This completely fails Requirement 1 ("visible to all members... so that they can volunteer to join"). It's typically used for highly confidential or temporary administrative workspaces.

Approval: While it allows for control over who joins (only by direct invitation from an Owner/Admin), its lack of discoverability makes it unsuitable for a volunteer group that wants members to find and request to join.

Conclusion:
"By Request" is the ideal access level because it strikes the perfect balance between discoverability for the entire organization and controlled approval by the group's leaders, which are the two critical requirements in this scenario.

Reference:
Slack Help Center: Set permissions for a workspace (or similar articles detailing workspace access levels like "Open," "By Request," "Invite Only," and "Hidden"). These documents explain how each access level impacts visibility and joining methods.