Explanation:

❌ A. Make the workspace a default workspace for all current and future users.

Why it's wrong:

Making a workspace a "default" workspace (also known as a required workspace) does ensure all current and future users are automatically added. However, the scenario describes creating an external workspace dedicated to Slack Connect channels. It implies that this workspace might be in addition to existing departmental workspaces, not necessarily replacing them or becoming the primary workspace for all internal communication. While it addresses the "all current and future users" part, it might oversimplify the intent or imply that this is the only workspace they'd be in, which isn't stated. More importantly, it's a broad brush when a more targeted, efficient method for selective workspace addition might exist, especially if users already have primary workspaces. The efficiency of this depends on the intent of the new workspace, and the best method often aligns with an IdP.

❌ B. Use an org-wide default channel to introduce the new workspace and its purpose. Ask all users who are currently using Slack Connect to join the workspace.

Why it's wrong:

✖️ "Ask all users... to join": This relies on manual action from users. It's not the "easiest and most efficient" way to add all current and future users, especially in a quickly growing company. Many users might miss the message, forget, or simply not bother, leading to incomplete adoption.

✖️ Limited Scope: It only targets users currently using Slack Connect, but the requirement is "all current users, plus any future users" to be in the workspace, even if they aren't actively using Slack Connect yet.

✖️ Not Automated: This is a manual, communication-based approach, not an automated user provisioning method.

❌ C. Use the workspace's admin dashboard to add all users within your organization.

Why it's wrong:

✖️ Manual Effort: While the workspace admin dashboard allows you to add users, doing so for "all current users" (potentially thousands in a large company) is a highly manual, time-consuming, and error-prone process. It certainly isn't the "easiest and most efficient" way, especially when considering "future users" who would also need to be manually added.

✖️ Scalability: This approach does not scale well with quick company growth, as new users would constantly need to be manually added.

✅ D. Sync all current and future users to the workspace using identity provider (IdP) groups.

Why it's the Correct Answer:

This is by far the easiest and most efficient way to manage user access in a large, growing Enterprise Grid environment.

✔️ Identity Provider (IdP) Integration: Enterprise Grid integrates deeply with IdPs (like Okta, Azure AD, OneLogin, etc.) for user provisioning via SCIM.

✔️ Group-Based Provisioning: You can define specific groups in your IdP (e.g., an "All Employees" group, or a "Slack Connect Users" group if you want to be more granular) and then sync these IdP groups directly to specific workspaces within Slack Enterprise Grid.

✔️ Automation: When a user is added to or removed from that IdP group, their access to the corresponding Slack workspace is automatically granted or revoked. This handles "all current users, plus any future users" with zero manual effort from the Slack admin beyond the initial setup.

✔️ Efficiency and Scalability: This is the hallmark of efficient user lifecycle management in an enterprise environment. It ensures consistent, accurate, and automatic provisioning, making it highly scalable for a rapidly growing company. It perfectly addresses the need to efficiently add all users to the new workspace and keep it up-to-date.

Conclusion:
For managing users in a large-scale, growing Enterprise Grid environment, leveraging your Identity Provider (IdP) with SCIM provisioning, specifically by syncing IdP groups to workspaces, is the most robust, efficient, and scalable method.

Reference:
✔️ Slack Help Center: Set up SCIM provisioning for Enterprise Grid
✔️ Slack Help Center: Connect your identity provider to Enterprise Grid
These resources explain how to connect your IdP and use group synchronization to manage user access to workspaces within an Enterprise Grid organization. This is a core capability for large companies.

Explanation:

✅ A. Use the Discovery API to export all messages and files from the channel.

Why it's the Correct Answer: The Discovery API (also known as the Discovery Events API or sometimes just "Discovery API") is Slack's primary tool designed for eDiscovery, DLP (Data Loss Prevention), and compliance. It allows Org Owners and designated Discovery Admins on Enterprise Grid to access all content (messages, files, edits, deletions, reactions) across the entire organization, including Slack Connect channels, for the purpose of legal holds, investigations, and compliance exports.

» "Export all messages and files": This API is specifically built for comprehensive data export, meeting the "all" requirement for legal purposes.
» "from a Slack Connect channel": The Discovery API covers content from Slack Connect channels as well as internal channels.
» "Due to a legal issue": This is precisely the use case for the Discovery API.

❌ B. Use the Audit Logs API to monitor and report on all messages and files from the channel.

Why it's wrong:
» Purpose of Audit Logs API: The Audit Logs API is designed for monitoring administrative actions and security events within the Slack organization (e.g., who logged in, who changed a setting, when an app was installed). It is not designed for exporting the content of messages and files themselves.
» "monitor and report on all messages and files": This is an incorrect description of its functionality regarding content. It logs metadata about content (e.g., when a file was uploaded, when a message was sent), but not the content itself for bulk export.

❌ C. Use Slack's Import/Export Data tool to export all messages from the channel, and then manually download the files.

Why it's wrong:
Limitations of Standard Export: Slack's standard Import/Export Data tool (available to Workspace Owners on paid plans, and Org Owners on Enterprise Grid) can export messages and links to files. However, for a legal issue requiring all messages and files, this tool has limitations:

» It typically exports a zip file with JSON or CSV data of messages.
» It provides links to files but often requires manual download of the files themselves, which is inefficient and highly impractical for a large volume of files from a legal perspective.
» More critically, it often doesn't capture deleted messages or edits in a forensically sound manner needed for eDiscovery, which the Discovery API does.
» "manually download the files": This is not efficient or scalable for a legal hold, especially from a "best way" perspective for an Org Owner on Enterprise Grid.

❌ D. Use the Discovery API to export messages and files from the channel that were sent by your company. Then ask the partners in the Slack Connect channel to do the same.

Why it's wrong:

» Incomplete Data: While it correctly identifies the Discovery API as the tool, the premise "export messages and files from the channel that were sent by your company" is incomplete for a legal issue that requires all messages and files. A legal request usually requires the entire conversation history, regardless of who sent it.
» Reliance on External Parties: "Then ask the partners... to do the same" introduces a significant point of failure, inefficiency, and potential non-compliance. You cannot guarantee that the external company will cooperate, do it correctly, or use a method that is forensically sound. For a legal issue, you need direct, comprehensive control over the data collection process. The Discovery API, when properly configured, gives you access to both sides of the Slack Connect channel data within your own organization's compliance system (or through a third-party eDiscovery vendor integrated with it).

Conclusion:
For legal and compliance purposes requiring comprehensive data export (including deleted content and edits) from Slack, especially in an Enterprise Grid environment, the Discovery API is the purpose-built solution. It offers the depth and breadth of data access necessary for eDiscovery and ensures that all relevant content, regardless of sender, is captured in a forensically sound manner.

Reference:
🔒 Slack Help Center: Set up and use the Discovery API (This is the primary resource for eDiscovery and compliance exports on Enterprise Grid).
🔒 Slack Help Center: What's the difference between Enterprise Grid export tools? (This often clarifies the distinct uses of standard export, Audit Logs API, and Discovery API).

Explanation:

❌ A. Stay on the Slack Pro plan, and enable domain claiming.

Why it's wrong:

→ Domain Claiming Feature: "Domain claiming" (sometimes called "email domain verification" or "domain capture") is the feature specifically designed to prevent unauthorized workspaces from being created with your company's email domain. When you claim a domain, any attempt to create a new workspace with an email address from that domain will either be automatically routed to your existing Enterprise Grid organization or blocked, depending on how it's configured.

→ Plan Requirement: However, domain claiming is an Enterprise Grid feature. It is not available on the Slack Pro plan or Business+ plan. Therefore, recommending to "stay on the Slack Pro plan" while enabling a feature exclusive to a higher tier is incorrect.

❌ B. Upgrade to the Slack Business+ plan, and enable Enterprise Key Management (EKM).

Why it's wrong:

→ Business+ Plan: While Business+ is a higher plan, it still does not offer domain claiming.

→ Enterprise Key Management (EKM): EKM is an add-on for Enterprise Grid (and Enterprise+), not available on Business+. Its purpose is to give organizations control over the encryption keys for their data in Slack, providing an additional layer of security and compliance, but it has nothing to do with preventing new workspace creation with company email addresses.

✔️ C. Upgrade to the Slack Enterprise Grid plan, and enable domain claiming.

Why it's the Correct Answer:

→ Enterprise Grid Plan: This is the correct plan that offers the "domain claiming" feature. Enterprise Grid is designed for large organizations that need centralized control over their Slack usage, including preventing the proliferation of unmanaged workspaces.

→ Enable Domain Claiming: As explained in option A, "domain claiming" (or similar features like "Managed Org Email Domain") is the specific functionality that allows you to assert control over your company's email domain within Slack. Once enabled on Enterprise Grid, any new workspace attempted to be created with an email address from your claimed domain will be managed or blocked by your Enterprise Grid organization. This directly addresses the compliance team's request.

❌ D. Ask your Org Owner to enable two-factor authentication (2FA).

Why it's wrong:

→ Purpose of 2FA: Two-factor authentication (2FA) enhances the security of individual user logins by requiring a second verification step. While crucial for user account security, 2FA does not prevent users from creating new workspaces. A user could still create a new, unmanaged free workspace and enable 2FA on that new workspace. The problem is about controlling the creation of workspaces, not the login security of existing ones.

→ Org Owner: While an Org Owner would be involved in implementing such a security feature, the feature itself is misapplied to the problem.

Conclusion:
The most effective and appropriate solution to prevent users from creating unauthorized Slack workspaces using their organization's email addresses is to upgrade to the Slack Enterprise Grid plan and enable domain claiming. This feature allows centralized control over the corporate email domain within Slack, ensuring that all workspaces associated with that domain are under the organization's management.

Reference:
Slack Help Center: Manage Org Email Domains (or similar documentation on Domain Claiming/Verification for Enterprise Grid): This is the definitive feature for controlling workspace creation with your company's email.
Slack Pricing Plans Comparison (especially between Business+ and Enterprise Grid): This would show which features are available at each tier.

Explanation:

❌ A. Allow all workspace members to invite new members.

Why it's wrong:
On the Slack Free plan, by default, all members (not just owners/admins) can invite new members. While this might help with internal employee onboarding, it directly contradicts the second goal of preventing anyone outside the company from joining without admin approval. If any member can invite, they could inadvertently or intentionally invite external individuals without proper vetting, bypassing any admin control. This provides no gatekeeping for external users.

❌ B. Invite all employees to the workspace by entering their email addresses in the invite flow from the workspace settings page.

Why it's wrong:
👉 Manual Effort: Manually inviting all employees one by one by entering their email addresses is highly inefficient and not scalable, especially for a company of any significant size. It also doesn't account for future employees.
👉 No Automatic Restriction: While you control who you initially invite, this method doesn't inherently prevent others (once invited and joined) from inviting external users if the workspace settings allow it. It doesn't put a systematic prevention in place for external access.

❌ C. Direct your employers to access Slack through your identity provider (IdP).

Why it's wrong:
👉 Plan Limitation: Integrating with an Identity Provider (IdP) for Single Sign-On (SSO) and robust user management is a feature of paid Slack plans (Business+ and Enterprise Grid), not the Free plan. On the Free plan, you cannot direct employees to use an IdP for authentication or user provisioning.
👉 Not Directly Relevant to External Access: While IdP integration enhances security, its primary purpose isn't to prevent external users from joining a free workspace; it's about managing internal users and their login process securely.

✅ D. Enable employees to sign up for the workspace using the company's email domain.

Why it's the Correct Answer:
✔️ Leveraging Workspace Settings for Domain Access: On Slack's free, Pro, and Business+ plans, Workspace Owners can configure settings to "Allow invitations, and approve invitations for any email address from these domains." This means you can specify your company's email domain (e.g., @yourcompany.com). When this is set, any person attempting to join or sign up for your specific workspace using an email address from that approved domain will be allowed to join automatically. This addresses "allow all employees... to join when they're ready" efficiently, as they can self-register using their company email.
✔️ Restricting External Access: By only approving your company's email domain for self-signup, anyone attempting to join using a non-company email address (e.g., Gmail, Yahoo, or another company's domain) would not be able to join without a direct invitation and your explicit admin approval (if you have "invite approval" also enabled, or by simply not allowing unapproved domains). This prevents "anyone outside your company from accessing your workspace without admin approval" by creating a gate at the email domain level. This is the best native functionality on the Free plan to achieve both goals simultaneously.

Conclusion:
The best way to balance inviting all internal employees easily while preventing unauthorized external access on a Slack Free plan is to enable employees to sign up for the workspace using the company's email domain. This allows for self-service internal onboarding while keeping external individuals out unless manually invited and approved.

Explanation:

In Slack Enterprise Grid, inviting external guests (like Single-Channel or Multi-Channel Guests) can be controlled at the workspace level.

Although Org Admins manage settings at the organization level, inviting guests is delegated through the workspace's invitation permissions.

To allow regular members (like Lydia's corporate events team) to invite guests, Lydia needs to go to the Workspace Invitations page, where she can configure invitation permissions, including who is allowed to invite guests.

This is where she can give permissions to specific members or user groups to invite guests, even if they aren't Workspace Admins.

🔗 Official Reference:
Slack Help – Set who can invite new members to a workspace
Slack – Manage invitations to your workspace

Explanation:

Correct Answer: B. Survey a selection of end users to determine whether existing knowledge networks are already in place.

Explanation:

When designing your channel and workspace strategy for Slack Enterprise Grid, understanding your organization's existing communication patterns and knowledge networks is paramount. This insight will help you create a structure that naturally supports how your employees already work and share information, leading to better adoption and more effective collaboration.

Let's look at why the other options are less ideal before finalizing your design:

A. Migrate existing workspaces into your Enterprise Grid org so that employees can familiarize themselves with its features as you plan the design. While migrating is a crucial step in the overall upgrade process, doing it before finalizing your design can lead to confusion and a less optimized structure. It's better to have a well-thought-out design first, then migrate. Employees can be familiarized with features through controlled pilots or training.

C. Review the technical requirements for your single sign-on (SSO) system to ensure it is compatible with Slack. SSO compatibility is a critical technical requirement for the Enterprise Grid implementation, but it doesn't directly inform your channel and workspace collaboration strategy. This is something to address during the technical setup phase, not necessarily as a primary input for organizational design.

D. Develop a Champions Network of interested users to help share the design with others. A Champions Network is an excellent strategy for driving adoption and sharing the final design, but it comes after you have a preliminary design or a framework in place. They can help validate and disseminate the design, but they don't typically help create the initial understanding of current collaboration patterns needed for the design itself.

Reference:
This concept aligns with best practices for change management and technology adoption. When implementing a new collaboration platform, understanding the "as-is" state of communication is vital for designing an effective "to-be" state. Salesforce and Slack often emphasize the importance of understanding user needs and existing workflows during the planning phase of an Enterprise Grid deployment.

You can often find guidance on this in Slack's own resources for Enterprise Grid adoption, which highlight:

Discovery Phase: Understanding current communication tools, common workflows, and pain points.
Stakeholder Interviews/Surveys: Gathering input from different departments and user groups.
Identifying Collaboration Patterns: How information flows, who needs to communicate with whom, and what types of discussions occur.

Explanation:

The goal is to encourage members to "self-start and learn about Slack at their own pace."

A. Use Workflow Builder to create an onboarding workflow with webinars and Help Center articles. This is the best answer. Workflow Builder allows you to create automated, structured onboarding flows within Slack itself. By incorporating links to webinars (which can be watched on demand) and Help Center articles, new hires can access information and learn independently whenever they are ready. This directly supports the "self-start" and "own pace" aspects.

Let's look at why the other options are less ideal for the stated goal:

B. Host a hackathon that allows new employees to learn about building Slack apps. A hackathon is a more advanced activity, typically for users who are already comfortable with Slack and possibly interested in development. It's not a foundational onboarding strategy for all new hires to learn the basics "at their own pace."

C. Use a custom bot to pair employees up, and have onboarding buddies help train new hires on Slack. While an onboarding buddy system can be very beneficial for integration and culture, it relies on another person's availability and teaching style. This doesn't fully align with the "self-start and learn at their own pace" requirement for initial Slack learning, although it could complement a self-paced approach.

D. Host a Slack 101 training for new hires to onboard them. A live training session is a great way to introduce Slack, but it's a synchronous activity. It requires new hires to be available at a specific time and doesn't inherently allow them to learn "at their own pace" as effectively as a self-directed workflow.

Reference:
Slack's own best practices for adoption and onboarding often highlight the use of features like Workflow Builder for automated processes and the importance of providing readily accessible resources (like a dedicated #onboarding channel, pinned posts with guides, and links to the Help Center). This empowers users to find answers and learn independently.

You can find more on Workflow Builder and its applications for onboarding in the Slack Help Center or on the Slack blog, specifically looking for articles on "Slack onboarding best practices" or "using Workflow Builder for new hires."

Explanation:

To determine the best course of action for the #bug-cricket channel, we need to consider the team’s need to reference the conversation history in the future, the channel’s inactivity, and the implications of each option on access and visibility. The goal is to preserve the channel’s history for future reference while minimizing clutter in the active workspace, given that the bug case is closed and there has been no recent activity.

Correct Answer: B. Archive the public channel; anyone can still browse the conversation history in Slack, and messages will appear in search results.

Explanation:

Why this is correct: Archiving the public channel #bug-cricket is the most appropriate action because:
Preserves history: Archiving a public channel retains all messages, files, and conversation history, which can be browsed by anyone who had access to the channel before it was archived (i.e., all workspace members for a public channel). This aligns with the team’s need to reference the history in the future.
Maintains searchability: Messages and files in an archived public channel remain searchable by anyone in the workspace, ensuring the team can easily find relevant information about the bug or architecture issue.
Reduces clutter: Archiving removes the channel from the active channel list, keeping the workspace organized without deleting valuable data.
No additional steps needed: Since the channel is already public, archiving it is straightforward and doesn’t require changing its privacy settings or removing members.

Implementation:
A Workspace Admin or a member with channel management permissions can archive the channel.
Navigate to the #bug-cricket channel, click the channel name in the header, and select “Additional options.”
Choose “Archive this channel” to move it to the archived channels list.
Team members can later access the archived channel via the Channel Browser or search for specific messages using Slack’s search functionality.

Why Not the Other Options?

A. Convert the channel to private, and then archive it; members of the channel will retain access to the files:
Converting a public channel to private before archiving limits access to only the current channel members, which is unnecessary since the channel is public and the team wants to retain broad access for future reference. Additionally, converting to private adds an extra step that doesn’t align with the goal of preserving history for all workspace members. While members of a private archived channel retain access to files, this option restricts visibility unnecessarily.

C. Delete the channel; messages from a deleted channel are still available via search:
Deleting a channel is not recommended because, in Slack, deleted channels permanently remove the ability to browse the channel’s conversation history. While some messages might still appear in search results for users with access to those messages, this is not guaranteed, and the team would lose the ability to view the full context of the discussions. This conflicts with the stated need to reference the history in the future.

D. Remove all members from the channel, and then archive it; this way, members can find messages via search but will not be able to browse the channel history itself:
Removing all members from a public channel before archiving is not a standard or recommended practice in Slack. Once members are removed, they lose the ability to browse the channel’s history, even after archiving, which directly contradicts the team’s need to reference the history. While messages might still be searchable, the inability to browse the full conversation makes this option unsuitable.

📘 Reference:
Slack Help Center: “Archive or delete a channel” explains that archived public channels retain their history and remain searchable and browsable by workspace members who had access, while deleted channels lose browsable history.
Trailhead: Salesforce Slack Administrator Certification Prep: Modules on channel management emphasize archiving as the best practice for inactive channels that may need to be referenced later, particularly for public channels in team collaboration scenarios.
Slack Enterprise Grid Best Practices: Recommends archiving inactive channels to maintain a clean workspace while preserving data for future use.

Explanation:

In Slack Enterprise Grid, workspace creation is a centralized process managed by Org Admins, not something end users can do independently.

The ideal strategy is to provide a clear and structured request workflow:
End users initiate workspace requests in a dedicated org-wide help channel (making it easy to find).
Admins then review and evaluate the business rationale in a private channel, maintaining security and avoiding public debates or confusion.
This ensures workspace sprawl is avoided and each new workspace has justified, intentional use.

This balances:
Transparency and accessibility (via the help channel)
Governance and control (admin-only review)

Why not the others?

A. Public review of requests:
Not secure or scalable. It could lead to noisy discussions and expose sensitive details.

C. Ban workspace requests:
Too restrictive. Some teams may need their own workspaces for compliance or org structure.

D. Allow end users to create and link workspaces:
Not allowed in Enterprise Grid. Workspace creation and linking are Org Admin-only functions, and domain claiming doesn’t work that way for linking.

🔗 Official References:
Slack Help – Manage workspaces in an Enterprise Grid organization
Slack – Guide to Enterprise Grid Administration

Explanation:

The goal is to automate and streamline tool access requests for new hires using Slack, reducing manual work and email-based back-and-forth. Here’s why A and D are the best-fit solutions:

✅ A. Use Workflow Builder to automatically send instructions on how to request access to new tools when new employees join the default #general channel.
→ Workflow Builder can be triggered automatically when someone joins a channel (like #general).
→ This ensures immediate delivery of tool request instructions at the right time (onboarding).
→ Removes the need for HR to manually email instructions.

✅ D. Use Workflow Builder to create a form for tool access requests, to simplify data collection and reduce wasted time going back and forth in email.
→ Workflow Builder allows creation of custom forms inside Slack.
→ New hires can fill out requests in a structured way, reducing back-and-forth.
→ IT support receives complete, consistent information.

❌ Why not the others?

B. Invite each new employee as a Single-Channel Guest before they join
→ Not scalable or appropriate for employees—Single-Channel Guests are typically used for external collaborators, not internal hires.

C. Post instructions once per week in #general
→ Less effective because it’s not personalized and can be missed. New hires may join at any time, not in sync with a weekly post.

🔗 Official References:
Slack Help – Workflow Builder overview
Slack Help – Automate tasks with forms in Workflow Builder

Explanation:

Given the context of a growing company and the need to offload responsibilities by assigning specific system roles, the Roles Admin is the designated role for managing and assigning these administrative responsibilities.

Let's break down why:

Roles Admin: This role is specifically designed to manage and assign other system roles within Slack. If your team decides to assign roles like "Compliance Admin," "Channels Admin," or "Users Admin," it's the Roles Admin who has the authority to grant these specific administrative permissions to other users.

Let's look at why the other options are incorrect:

A. Compliance Admin: This role is responsible for managing legal holds, eDiscovery, and other compliance-related features. While crucial, this role doesn't assign other admin responsibilities.

C. Channels Admin: This role is responsible for managing channel-specific settings, archives, and potentially creating certain types of channels. It does not assign other administrative roles.

D. Users Admin: This role is responsible for managing user accounts, invitations, deactivations, and user groups. It does not assign other administrative roles.

Reference:

This question directly relates to the system roles available in Slack Enterprise Grid, which are designed to delegate administrative duties in larger organizations. You can find detailed descriptions of these roles in the Slack Help Center under sections related to "Enterprise Grid roles" or "Admin roles and permissions." Specifically, look for documentation that outlines the responsibilities of each administrator role.

Explanation:

To determine what is true when public file sharing is enabled in Slack, we need to understand the implications of this setting, particularly in the context of an Enterprise Grid organization, as relevant to the Salesforce Slack Administrator Exam. Public file sharing allows files uploaded to Slack to be shared externally via public links, which can be accessed by anyone with the link, even outside the organization. Let’s evaluate each option based on this understanding.

Correct Answer: A. Integrated data loss prevention (DLP) solutions can monitor files in private channels and direct messages (DMs).

Explanation:

Why this is correct: When public file sharing is enabled, files uploaded to Slack (including those in private channels and direct messages) can have public links created, which increases the risk of sensitive data being shared externally. Slack’s integration with third-party data loss prevention (DLP) solutions (e.g., Netskope, Symantec, or Palo Alto Networks) allows organizations to monitor and control file sharing across all channels, including private channels and DMs. DLP solutions can:

Scan files for sensitive content (e.g., credit card numbers, personal data). Block or restrict the creation of public links based on organizational policies. Monitor and log file-sharing activities to ensure compliance with security protocols. This capability is particularly relevant in Enterprise Grid, where security and compliance are critical, and DLP integrations help mitigate risks associated with public file sharing.

Implementation: As a Slack Workspace Admin or Org Admin:

Enable public file sharing in the Admin Dashboard under Organization Settings > Security > File Sharing. Configure a DLP integration via Slack’s App Directory or API to monitor files across public channels, private channels, and DMs. Set policies to flag or block external sharing of sensitive files, ensuring compliance with data protection requirements.

Why Not the Other Options?

B. Your organization’s file sharing settings will apply to all files uploaded to a Slack Connect channel by any of the up to 250 organizations that have joined the channel:
This is incorrect because, in Slack Connect channels, each organization’s file-sharing settings apply only to the files uploaded by its own members. Slack Connect allows up to 250 organizations to collaborate in a single channel, but each organization retains control over its own file-sharing permissions (e.g., whether public links can be created). One organization’s settings do not override or apply to files uploaded by members of other organizations.

C. File upload permissions to Slack Connect channels can’t be restricted:
This is incorrect because file upload permissions in Slack Connect channels can be restricted. Workspace Admins or Org Admins can configure settings to limit who can upload files to Slack Connect channels (e.g., restricting uploads to specific members or roles). Additionally, public file-sharing settings can be adjusted to prevent external link creation, and DLP tools can further enforce restrictions.

D. In a public channel, only admins can create an external link for a file:
This is incorrect because, when public file sharing is enabled, any member of a public channel (not just admins) can create an external link for a file, unless restricted by specific organizational policies or DLP settings. Admins can configure permissions to limit who can create external links, but this is not the default behavior when public file sharing is enabled.

Reference:

Slack Help Center: “Share files in Slack” explains public file sharing and the ability to create external links, as well as how DLP integrations can monitor and control file sharing in private channels and DMs.

Trailhead: Salesforce Slack Administrator Certification Prep: Modules on security and compliance highlight the role of DLP solutions in managing file sharing risks, especially in Enterprise Grid environments.

Slack Enterprise Grid Documentation: Notes that DLP integrations can monitor files across all conversation types (public channels, private channels, and DMs) when public file sharing is enabled, ensuring data security.