Salesforce-Slack-Administrator Practice Test Questions

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.

Explanation:

A. Automatically adds or removes members of an IdP group to workspaces within your org. This is a fundamental benefit. When you sync IdP groups, Slack can automatically provision and deprovision users from workspaces based on their group membership in your identity provider. This vastly simplifies user management, especially for large organizations with frequent hires, role changes, and departures.

C. Makes membership for certain workspaces required to ensure that all members of an IdP group remain members of a workspace. This allows for strong control over access to critical workspaces. If a specific department (represented by an IdP group) must be in a certain workspace for their work, syncing ensures they are always there. If they are removed from the IdP group, they are also removed from the required workspace.

D. Automatically assigns system roles. This is another powerful automation benefit. Instead of manually assigning Slack system roles (like Channels Admin, Users Admin, etc.) to individual users, you can assign these roles to IdP groups. As users join or leave those IdP groups, their Slack system roles are automatically updated, streamlining administrative delegation.

Let's look at why the other options are not correct:

B. Makes membership for certain channels required to ensure that all members of an IdP group remain members of a channel. While you can connect IdP groups to channels to automatically add members, Slack states that members of an IdP-synced channel can leave those channels at any time. Therefore, it doesn't require them to remain members in the same way it can for workspaces.

E. Automatically assigns approved apps to certain groups within your org. IdP group syncing primarily manages user and role provisioning, not the automatic assignment or installation of approved apps to specific groups. App management often has its own set of controls within Slack's App Administration settings.

F. Automatically assigns admin roles. This is too broad. While it does automatically assign system roles (as in option D), "admin roles" could imply broader administrative permissions not directly managed by IdP group syncing for all scenarios. Option D is more precise regarding the specific types of roles automatically assigned.

Reference:

Slack's official documentation on "Connect identity provider groups to your Enterprise organization" explicitly details these capabilities. You'll find information on how IdP groups streamline:

Workspace Membership: Auto-joining and leaving workspaces, including making workspace membership required.

Channel Membership: Auto-joining channels (though with the caveat that users can leave).

System Role Assignment: Assigning specific Slack system roles to IdP groups.

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