Explanation:

D. Approve or deny Slack Connect requests
The External People Management dashboard allows Org Admins to review, approve, or deny incoming Slack Connect channel invitations and requests from external organizations. This gives admins control over which external parties can communicate with their organization.

E. View all external people connected to your org and the Slack Connect channels they belong to
Admins can see a list of all external users who have access to their workspace via Slack Connect, including details about the channels they are part of. This helps in managing and auditing external access.

Why the other options are incorrect:

A & B (Removing external members from channels):
Org Admins cannot directly remove external members from Slack Connect channels via the External People Management dashboard. Channel membership management typically remains with individual channel owners or workspace admins, not through this dashboard based on permissions like "Can only post" or "Can post & invite."

C (View all Slack Connect invitations):
While admins can approve or deny requests (D), the dashboard does not provide a comprehensive view of all invitations sent. It focuses more on pending requests and external user management.

Reference:
Salesforce Help Article on Slack Connect Security and External People Management
Slack Documentation on Slack Connect and external user management

Explanation:

🔴 A. Have the "Ambassadors" conduct app review in the channel, using emoji to alert the Admins to whitelist the app.

Why it's wrong:

❌ Efficiency: This is highly inefficient. It creates a two-step manual process. The "Ambassadors" review and signal, but the actual approval still relies on a Workspace Owner or Org Admin to manually go into the App Directory to whitelist the app. This adds unnecessary delay and potential for miscommunication or oversight.

❌ Native Functionality: It doesn't leverage Slack's built-in app approval delegation capabilities.

❌ Direct Control: The "Ambassadors" don't have direct control over the approval/denial process, only advisory input.

🔴 B. Promote the "Ambassadors" to Workspace Owners in Slack.

Why it's wrong:

❌ Over-Permissioning: Promoting individuals to Workspace Owners grants them a vast array of permissions beyond just app approval (e.g., managing members, channels, billing, security settings, deleting the workspace). This is a major security risk and goes against the principle of least privilege. The scenario explicitly states "Ambassadors" for app approval, not full workspace management.

❌ Not Most Efficient: While they could approve apps, giving them excessive permissions is not the "most efficient" or secure way to achieve a single task.

🔴 C. Promote the "Ambassadors" to Workspace Admins in Slack.

Why it's wrong:

❌ Over-Permissioning (Still): Similar to Workspace Owners, Workspace Admins have significant administrative control within a workspace (e.g., managing members, archiving channels, installing many types of apps without approval if app approval is off). While it's a step down from Owner, it's still generally more permission than needed just for app approval if other specific roles exist.

❌ Specific Role vs. Broad Role: The scenario implies a dedicated group just for app approvals. Assigning them a broad "Admin" role might still grant more power than intended.

🟢 D. Add the "Ambassadors" as "selected members or groups" to manage Approved Apps.

Why it's the Correct Answer: This option directly leverages Slack's granular permission settings for app management, which is part of its Enterprise Grid (and potentially Business+ in some aspects) capabilities.

✔️ "Selected members or groups to manage Approved Apps": Slack allows Org Owners/Admins (and Workspace Owners depending on the plan and settings) to designate specific individuals or user groups as "App Managers" or to grant them specific permissions related to app approval. This is often found under "App management settings" or "Approved Apps" within the Slack administration console. You can specify who receives app requests and has the authority to approve or deny them.

✔️ Efficiency: When an app request is made by a user, it goes directly to the designated "App Managers" (the "Ambassadors" in this case), often appearing as a notification in the configured channel (#plz-app-request as specified). From there, the Ambassadors can directly review the app details and take the approval or denial action within the Slack interface. This is a streamlined, one-step process.

✔️ Least Privilege: This method grants only the necessary permissions for app approval, avoiding the over-permissioning of making them full Workspace Owners or Admins.

✔️ Meeting All Requirements: It ensures the "Ambassadors" can review and approve/deny, in the specified channel, efficiently, without granting them undue access to other workspace settings.

🔒 Conclusion:
Slack's administrative features allow for granular control over who can manage apps. The most efficient and secure way to empower "App Approval Ambassadors" without granting them excessive permissions is to assign them the specific role that allows them to manage approved apps directly. This feature is typically found by adding them as "App Managers" or configuring them under specific "App Approval" settings within the Slack Admin dashboard.

🔒 Reference:
Slack Help Center: Manage app approval settings
Slack Help Center: Set permissions for a workspace (specifically looking at the "App Management" or "Integrations" permissions within different roles).
These resources detail how to set up app approval workflows and delegate app management responsibilities to specific individuals or groups, which is the core of Option D.

Explanation:

In Slack Workflow Builder, the best practice for updating an existing workflow is to:

1. Unpublish the current version (to prevent outdated information from being triggered).
2. Edit the workflow steps (update content, change messages, forms, etc.).
3. Republish it once the updates are complete.

This approach maintains the existing workflow logic and history while ensuring accurate and current information is shared moving forward.

❌ Why not the others?

B. Download and edit JSON manually:
Workflow export/import (via JSON) is available but not the intended or easiest method for small updates. It's error-prone and overcomplicated for this use case.

C. Add a step noting what changed:
That doesn’t address the core issue: the outdated content still exists. Adding a note won't replace incorrect or irrelevant information.

D. Delete and recreate:
Unnecessary extra work and removes existing logic, triggers, and history. Editing the workflow is faster and cleaner.

🔗 Official Reference:
Slack Help – Edit a Workflow
Slack – Workflow Builder Documentation

Explanation:

✅ C. Set a mobile session duration of 2 weeks for all mobile devices.
Setting a fixed mobile session duration balances security and usability. A 2-week session timeout is a common practice that helps ensure users don’t have to log in too frequently—reducing frustration and improving adoption—while still limiting the risk of unauthorized access if a device is lost or compromised.

❌ Why the other options are less appropriate:

A. Allow users to set their own mobile session duration.
This can lead to inconsistent security policies and weaker protection if users choose overly long sessions.

B. Log all users out of mobile anytime your organization experiences a security threat.
While necessary in some high-risk scenarios, this reactive approach can disrupt users frequently and hurt productivity.

D. Allow all users to remain logged in infinitely.
This poses significant security risks, especially if devices are lost or stolen, and is not recommended.

Reference:
Slack Help Center – Manage session duration and device access

Explanation:

Option A: Members can share files externally by creating public URLs.
This is the correct answer. When "public file sharing" is enabled in an Enterprise Grid organization, it allows members to generate shareable public links (URLs) for files uploaded to Slack. These links can be distributed to anyone on the internet, even those without a Slack account, enabling external collaborators, clients, or partners to view or download the files. This feature is particularly useful for sharing non-sensitive materials like marketing assets, public reports, or event flyers. However, it requires careful governance, as these URLs are accessible to anyone who possesses them, potentially risking unintended exposure of information if used improperly. Admins often complement this setting with data loss prevention (DLP) tools to monitor sensitive content.

Option B: Members can share files in public channels within the Slack Enterprise Grid.
This is incorrect because the ability to share files in public channels is a default behavior in Slack, unrelated to the "public file sharing" setting. All members can already upload files to public channels (assuming they have channel access), where they become visible to other channel members. The "public file sharing" toggle specifically controls external sharing via public URLs, not internal channel-based sharing. This option misinterprets the term "public" as referring to public channels rather than public internet access.

Option C: Members can share files with guests in Slack.
This is incorrect because guest file sharing is governed by separate permission settings. Slack guests (single- or multi-channel) can typically view/files shared in channels they’ve been added to, but this isn’t tied to the "public file sharing" feature. That setting controls whether files can be shared via public links outside the organization entirely, whereas guest sharing occurs within Slack’s internal ecosystem. Admins manage guest permissions through workspace/org-level settings like "Allow guests to send files."

Option D: Members can share files externally via Slack Connect channels.
This is incorrect because Slack Connect—used for secure collaboration with external organizations—has its own file-sharing permissions. While Slack Connect does allow file sharing with partnered organizations, it’s a controlled environment where external members must be approved. "Public file sharing," by contrast, creates open URLs accessible to anyone on the internet, with no requirement for the recipient to join Slack or a Connect channel. These are distinct features with different security implications.

Key Distinction:
The "public file sharing" setting exclusively enables the creation of public URLs for files (Option A). It does not affect:
→ Internal channel file sharing (B)
→ Guest collaboration (C)
→ Slack Connect file sharing (D)
For security, orgs often disable this for sensitive environments while enabling it for teams needing open collaboration. Admins should pair it with clear usage policies.

Reference: Slack’s Enterprise Grid file permissions guide.