Free Salesforce Slack Consultant Practice Test Questions

Explanation:

After key decisions are made to customize Slack policies and settings, the implementation of those configurations must be carried out by someone with the appropriate permissions and access to the client's Slack instance. The Slack admin on your client's engagement team is the correct responsible party.

Has the necessary permissions – Only users with administrative roles (Org Admins, Workspace Admins, or Owners) can implement policy changes, modify settings, manage user permissions, and configure integrations. The client's Slack admin possesses these permissions.

Owns the instance – The client's admin is an employee of the client organization who is responsible for the ongoing management, maintenance, and governance of their Slack environment. They are the rightful operational owner of the instance.

Internal accountability – Implementing configurations is an internal operational task. The client's admin is the appropriate person to execute changes because they understand their organization's infrastructure, approval processes, and change management protocols.

Why other options are incorrect:

A. The Slack account executive
– The Account Executive (AE) is a sales representative responsible for customer acquisition, renewals, and commercial relationships. They do not have access to the client's Slack instance and do not perform technical implementations.

C. The Slack customer success manager
– The Customer Success Manager (CSM) is a post-sales advisor focused on adoption, value realization, and strategic guidance. While they may offer best-practice recommendations, they do not have administrative access to the client's instance and do not perform configuration changes.

D. Your client's executive sponsor
– The Executive Sponsor is a senior leader who champions the project, removes organizational barriers, and secures resources. They are not involved in day-to-day technical configuration—they focus on strategic alignment and governance, not implementation.

References:

Slack Certified Consultant Trailhead – "Slack Governance": States that "configuration changes must be executed by the client's Workspace or Org Admins, who hold the necessary permissions and operational ownership."

Explanation:

To automatically sign users out of desktop and mobile instances of Slack every 30 days, the correct setting to configure is the session duration in the org security settings, set to 720 hours (30 days × 24 hours = 720 hours).

Org security settings – This is where Slack administrators manage workspace and organization-wide security policies, including session expiration. The session duration setting controls how long a user remains logged in before being required to re-authenticate. Configuring this at the org level ensures the policy applies uniformly across all workspaces in an Enterprise Grid.

720 hours – Slack's session duration is configured in hours, not days. Thirty days equals 720 hours (30 × 24). This setting enforces automatic logout from both desktop and mobile instances after the specified period.

Security best practice– Enforcing periodic re-authentication is a standard security measure to reduce the risk of unauthorized access due to stale sessions, lost devices, or compromised credentials.

Why other options are incorrect:

A. Enable session duration in org security settings to have a session duration of 30 calendar days
– While the intent is correct (org security settings), session duration must be configured in hours, not calendar days. Slack does not accept "30 days" as a valid value; the correct numeric value is 720 hours.

B. Enable session duration in org SSO settings
– SSO (Single Sign-On) settings control authentication methods (e.g., SAML, OIDC) and identity provider configurations, not session expiration for the Slack client itself. Session duration is a security setting, not an SSO setting.

C. Enable session duration in org SSO settings to have a session duration of 720 hours
– This option correctly uses 720 hours but incorrectly places the setting under SSO. Session duration is not an SSO parameter; it is managed under org security settings.

References:

Slack Enterprise Grid Documentation – "Org security settings": States that "session duration can be configured in the Org Security Settings, measured in hours, to enforce automatic logout after a specified period."

Slack Help Center – "Set a session duration for your organization": Confirms that "the session duration setting is found under Organization Settings > Security, and values must be entered in hours."

Explanation:

RedSplash Corp wants to measure Slack adoption by department and identify potential Slack champions (managers who can train others). To gain this insight, they need accurate, consistent, and up-to-date department and manager data mapped to each user's Slack profile. The correct approach is to create custom profile fields for "Department" and "Manager" and configure SCIM (System for Cross-domain Identity Management) to push values from the identity provider (IdP) into these fields.

Why other options are incorrect:

A. Map SCIM attributes dept and mgr to populate custom profile fields
– This option is close but specifies incorrect attribute names. Slack does not accept generic "dept" and "mgr" attributes. The correct SCIM attributes are typically enterprise.department and enterprise.manager.managerId (or similar, depending on the IdP). This option is technically inaccurate.

B. Create custom profile fields so members can update them manually
– Manual updates are unreliable and quickly become outdated. Users may forget to update their information or enter inconsistent values, making adoption reports inaccurate. This defeats the purpose of reliable departmental analysis.

C. Push SCIM attributes enterprise.department and enterprise.manager.managerId from IdP to populate custom profile fields
– This option correctly identifies the SCIM attributes but omits the critical step of creating the custom profile fields first. Custom fields must exist in Slack before SCIM can push data into them. The order matters: create fields, then map SCIM attributes.

References:

Slack Enterprise Grid Documentation – "SCIM and custom profile fields": States that "custom profile fields must be created in Slack before SCIM attributes can be mapped and synchronized."

Slack Help Center – "Set up SCIM provisioning": Confirms that SCIM can push attributes like enterprise.department to custom profile fields for reporting and search. "

Explanation:

Slack Connect is a feature that enables secure, real-time collaboration between your organization and external partners, vendors, or clients. Whether approval is required to work with an external partner in Slack Connect channels depends on how the organization has configured its Slack Connect settings and permission policies.

Configurable approval settings – Slack Connect has built-in flexibility. Organizations can set default policies that require approval for all external invitations, allow certain users or teams to invite partners without approval, or require approval only for specific domains. These settings are managed by Org Admins and Workspace Admins.

Domain-based controls – Organizations can whitelist trusted domains (e.g., @partner.com) so that invitations to those domains do not require approval, while all other external domains require admin review.

User roles and permissions – Admins can also delegate invite permissions—allowing certain members (e.g., department leads, project managers) to invite external partners without approval, while others must request approval.

Because the approval requirement depends on custom organizational policies, it is sometimes required—not always, not never.

Why other options are incorrect:

A. Slack Connect channels require approvals only if Slack Apps require approvals
– Slack App approvals and Slack Connect approvals are completely unrelated. One governs app installation; the other governs external collaboration. This option conflates two separate processes.

B. Approval is never required
– Incorrect. Many organizations enforce approval workflows for security and compliance reasons. The default setting can be configured to require approval, especially in regulated industries.

C. Approval is always required
– Incorrect. Organizations can whitelist trusted domains or delegate invite permissions, allowing members to invite external partners without going through an approval process.

References:

Slack Help Center – "Manage Slack Connect for your organization":States that "Org Admins can set default approval requirements for Slack Connect invitations, including domain-based exceptions and delegated permissions."