Free Salesforce-Slack-Developer Practice Test Questions (2026)

Explanation:

The question asks which Slack feature lets a user trigger an app action via a right-click or lightning bolt menu. Shortcuts are exactly this feature, a way for users to invoke an app's functionality on demand from the Slack UI rather than through a slash command or a message event. Slack offers different shortcut entry points, including global shortcuts, which appear from the lightning bolt icon in the message composer, and message shortcuts, which appear in the context menu when a user right-clicks or opens the "More actions" menu on an individual message. These user-initiated interactions deliver a payload to the app and can be used to open modals, start workflows, or perform other app actions.

Shortcuts are a core part of Slack's interactivity model and are commonly used to open modals for data collection, kick off workflows, or perform actions like creating a task, filing a ticket, or translating a message. They are registered in the app configuration, and developers can handle them in Bolt using `app.shortcut()`, typically filtering by the shortcut's `callback_id`. Because shortcuts are explicitly invoked by the user, the app does not need to passively listen to all messages.

❌ Why Other Options Are Incorrect:

B. Webhooks
– Webhooks, such as incoming webhooks, allow external services to post messages into Slack. They are not user-facing trigger mechanisms for invoking app actions from the Slack UI.

C. Scopes
– Scopes are OAuth permission grants that define what an app is allowed to access or perform, such as `chat:write` or `commands`. They are permissions, not user-facing interaction triggers.

D. Manifests
– A manifest is a YAML or JSON configuration that defines an app's settings, permissions, and features. It is used to configure the app rather than to provide users with a mechanism for triggering actions.

References:

Slack API Documentation – Shortcuts – Official Slack documentation describing global and message shortcuts as user-initiated ways to trigger app functionality from Slack's interface.

Explanation:

The scenario describes a workflow where a third-party service posts vacation requests as Slack messages, and app managers need to approve those requests, with the message updating once approved. This is a classic use case for interactive buttons built with Block Kit. Buttons are interactive elements that appear inside a message and can be attached to an actions block or used as a section accessory. Each button carries an action_id and a value that identifies which request is being approved. When a manager clicks the button, Slack sends a block_actions interaction payload to the app containing the action, the user who clicked, the channel, and the message (including its ts). The app can then acknowledge the click with ack(), process the approval, and update the original message using chat.update with the channel ID and message timestamp so that everyone in the channel sees the new status.

❌ Why Other Options Are Incorrect:

A. Message reactions
– Reactions are emoji responses users add to messages. While a reaction_added event could technically signal approval, reactions do not include the structured action payload, action_id, or button value that makes approval routing reliable, and they are not the intended mechanism for capturing a formal approval decision or updating the message cleanly.

C. Global shortcuts
– Global shortcuts are invoked from the composer or lightning bolt menu, not from within a specific message. They are not tied to an individual vacation request message, so a manager could not approve a particular request directly from its message.

D. Slash commands
– Slash commands are typed in the composer and are not attached to a message. They cannot directly target a specific vacation request message for approval, and they do not provide an inline approve/reject control on the request itself.

References:

Slack API Block Kit documentation on Button elements – Describes buttons as interactive elements with action_id and value used to trigger app actions within messages.

Explanation:

The question asks which Bolt method is typically used to open a modal in response to a shortcut. In Bolt, modals are opened by calling the Slack Web API method views.open, which is exposed on the Bolt client object as client.views.open(). When a user invokes a shortcut (global or message), Slack sends an interaction payload that includes a trigger_id. This trigger_id is short-lived and valid for only about 3 seconds, so the app must call client.views.open() immediately with the trigger_id and a view object built using Block Kit. For example, in Bolt for JavaScript: await client.views.open({ trigger_id: body.trigger_id, view: { type: 'modal', ... } }). In Bolt for Python, the equivalent is client.views_open(trigger_id=body["trigger_id"], view=...).

❌ Why Other Options Are Incorrect:

A. app.modal()
– This is not a real Bolt method. Bolt does not have an app.modal() listener or helper; modals are opened via the client, not through an app.* method.

C. app.popup()
– This is not a valid Bolt method. There is no popup() helper in Bolt for opening Slack views.

D. client.modal.show()
– This is not a valid Slack Web API method or Bolt client method. The correct API namespace is views (views.open, views.update, views.push), not modal.

References:

Bolt for JavaScript documentation on Opening modals – Shows client.views.open() being called with a trigger_id in response to a shortcut or action.

Explanation:

The question asks what happens when a user clicks an interactive button in a Block Kit message. When a user interacts with an element such as a button, select menu, overflow menu, or date picker, Slack generates an interaction payload of type block_actions and dispatches it to your app. The destination depends on how the app is configured: if the app uses a public HTTP endpoint, Slack sends the payload to the Request URL configured in the app's Interactivity settings; if the app uses Socket Mode, Slack delivers the payload over the persistent WebSocket connection instead. In both cases, Bolt receives the payload and routes it to the matching listener, typically app.action() filtered by action_id. .

❌ Why Other Options Are Incorrect:

A. Slack silently ignores it
– This is false. Slack actively generates and sends an interaction payload to the app. It only shows an error to the user if the app fails to acknowledge within 3 seconds.

C. The message is deleted
– This is false. Clicking a button does not delete the message. The app may choose to update or delete the message via the API, but that is an explicit app action, not automatic behavior.

D. The user's OAuth token is revoked
– This is false. Clicking a button has no effect on OAuth tokens. Token revocation only happens through explicit user or admin action, such as uninstalling the app.

📚 References:

Slack API documentation on Handling interactions – Explains that clicking interactive elements generates a block_actions payload sent to the app's Request URL or Socket Mode connection.

Explanation:

The question asks which Slack feature is best to trigger a multi-question form that users can invoke from anywhere in Slack, with the captured data sent to a backend system and also posted into the #benefits-us channel. The key phrase is "from anywhere in Slack" — this is precisely what a global shortcut provides. Global shortcuts appear when a user clicks the lightning bolt icon in the message composer (or opens the shortcuts menu), regardless of which channel or conversation they are currently in. When invoked, Slack sends an interaction payload containing a trigger_id, which the app uses to open a modal built with Block Kit. The modal can contain multiple input blocks (text inputs, select menus, checkboxes, date pickers, etc.) to collect the multi-question form data.

❌ Why Other Options Are Incorrect:

A. Incoming webhook
– An incoming webhook is a one-way mechanism for posting messages into Slack from an external system. It cannot trigger a form or open a modal; it only pushes content in.

B. Message shortcut
– A message shortcut is tied to a specific message in its context menu (right-click / More actions). It cannot be invoked from "anywhere in Slack," so it does not meet the requirement.

C. Message reaction
– A reaction is an emoji added to a message. It is not a form trigger, cannot open a modal, and is not suited for multi-question data collection.

References:

Slack API documentation on Shortcuts – Defines global shortcuts as invocable from the lightning bolt menu anywhere in Slack, and message shortcuts as tied to individual messages.

Slack API documentation on Modals – Explains that a trigger_id from a shortcut is used with views.open to display a Block Kit modal for collecting input.

Explanation:

The question asks for two correct statements about the App Home tab and modals in Slack. Both C and E accurately describe how these surfaces behave, while the other options contain factual errors.

Option C states that for modals there is only ever a single view visible at a given moment, and there is no way to return to previous views with their prior state still in place. This is correct. Modals support a view stack of up to 3 views (via views.push), but only the topmost view is visible at any one time. When a user closes or navigates back from a modal, the previous view in the stack does not retain its prior input state — the stack is torn down, and the user cannot go "back" to a previously filled view with the data still intact. This is an important design consideration: if you need multi-step input with preserved state, you must design your modals carefully or store state on your backend.

Option E states that the Home tab is a space that can be fully customized by the app and can be updated by the app at any time. This is correct. The App Home is a dedicated surface rendered with Block Kit, and the app can publish and update it at any time using views.publish with a user token. It is commonly used as a persistent dashboard, a starting point for app actions, or a place to show personalized content for each user. The Home tab is not static — it is fully app-controlled and can be refreshed whenever the app needs to reflect new data or state.

Together, these two statements capture the essential contrast: the Home tab is a persistent, fully customizable surface that the app owns and can update freely, while modals are temporary, stacked views where only one is visible at a time and state is not preserved when navigating back.

❌ Why Other Options Are Incorrect:

A. The Home tab is a space that cannot be updated by the app. – This is false. The Home tab can be fully customized and updated by the app using views.publish.

B. You can use the Block Kit Builder to construct Modals but not the Home Tab. – This is false. The Block Kit Builder can be used to prototype blocks for both modals and the Home tab; both use Block Kit.

D. While modals can hold up to 3 views at one time in a view stack, there is only ever a single view visible at a given moment. – While the first half (up to 3 views in a stack) is true, this option is incomplete and misleading compared to C. C is the better answer because it also correctly notes that previous views do not retain their prior state, which is a key modal limitation the exam is testing.

📚 References:

Slack API documentation on Modals – Explains that modals support a stack of up to 3 views, only one of which is visible at a time, and that previous views do not retain their state.

Explanation:

The question asks which Block Kit elements should be used to collect three specific pieces of information in a time-off request modal: absence period, free text descriptive information, and manager's username. The correct mapping is:

Absence period → A datetime picker is the right element because a time-off request spans a period that includes both a date and a time (or at minimum a date range). The datetimepicker element lets users select both a date and a time, which is more appropriate for absence periods than a plain time picker (which only selects a time of day). A datepicker alone would work for single dates, but a datetime picker covers the period including time, making it the best fit for "absence period."

Free text descriptive information → A plain-text input element is designed for short free-form text entry, such as a reason or comment. It supports a multiline option, a placeholder, and a max length, making it ideal for descriptive notes.

Manager's username → A select menu of users is the correct choice. Slack provides a users_select element (a type of select menu) that renders a picker of workspace members, letting the user choose their manager by name. This is more reliable than asking for a typed username, because it returns a valid user ID rather than free text.

Option B correctly pairs these three: datetime picker for the period, plain-text input for the description, and select menu of users for the manager.

❌ Why Other Options Are Incorrect:

A. Time picker, plain-text input and number input
– A timepicker only selects a time of day, not a date range, so it cannot capture an absence period. A number input is for numeric values (like hours or days) and cannot capture a manager's username.

C. Time picker, plain-text input and select menu of users
– The manager part is correct, but a timepicker only captures a time of day and cannot represent an absence period spanning dates. This fails the "absence period" requirement.

D. Datetime picker, plain-text input and number input – The datetime picker and plain-text input are correct, but a number input cannot capture a manager's username; a users select menu is needed.

References:

Slack API Block Kit documentation on Datetime picker element – Describes the datetimepicker element for selecting both date and time, suitable for periods like absence ranges.

Explanation:

The question describes an HR team that wants to send newsletters regularly to specific regional Slack channels but cannot automate the process themselves. The question asks how Block Kit Builder can help them. Block Kit Builder is a  visual prototyping tool provided by Slack that lets users drag and drop Block Kit elements (sections, dividers, images, buttons, inputs, and more) into a layout and see a live preview of how the message will look in Slack. As users build the message, the tool generates the corresponding  JSON payload in real time, which can then be copied and used in an app or pasted into a message-sending tool. This makes it significantly easier for non-developers, like an HR team, to  design and prepare a message before it is actually sent to a channel, without needing to write code or hand-craft JSON from scratch.

❌ Why Other Options Are Incorrect:

A. It lets you save and organize the message templates you use most often.
– This is false. Block Kit Builder does not provide a template library or save/organize feature; users typically copy the generated JSON and store it elsewhere.

C. It helps you test your message interactivity flows from end-to-end.
– This is false. Block Kit Builder previews the visual layout of blocks, but it does not execute or test end-to-end interactivity flows such as button clicks triggering app logic.

D. It can automatically convert a word processor document into Block Kit without knowledge of JSON.
– This is false. Block Kit Builder requires users to assemble blocks manually (or paste existing JSON); it does not import or convert word processor documents automatically.

📚 References:

Slack API Block Kit Builder documentation – Describes the tool as a visual prototyping environment for designing and previewing Block Kit messages while generating JSON.

Explanation:

The question asks about the purpose of the Slack MCP plugin mentioned in the developer docs. MCP stands for Model Context Protocol, an open standard that allows AI agents and LLM-powered tools to connect to external services and data sources in a structured way. The Slack MCP plugin exists to expose Slack's developer capabilities to these agentic tools, enabling agent-assisted development workflows. In practice, this means an AI coding assistant or agent can interact with Slack's platform — for example, to help scaffold apps, look up API methods, manage app configuration, or assist with building and deploying Slack apps — through the standardized MCP interface rather than through manual, ad-hoc integrations. .

❌ Why Other Options Are Incorrect:

B. To manage billing
– This is false. Billing and workspace administration are handled through Slack's admin and billing interfaces, not through an MCP developer plugin.

C. To replace the Slack CLI
– This is false. The Slack CLI remains the official tool for app development, and the MCP plugin complements rather than replaces it.

D. To handle OAuth exclusively
– This is false. While OAuth and authentication may be involved when an agent connects, the plugin's broader purpose is enabling agent-assisted development, not handling OAuth exclusively.

📚 References:

Slack Developer documentation on the Slack MCP plugin – Describes the Model Context Protocol integration as a way to enable AI agents and assistants to work with Slack's developer platform.

Explanation:

The question asks where a developer should look first to start building an AI agent for Slack. Among the four options, docs.slack.dev/ai/agent-quickstart is the only one that is a developer documentation resource specifically dedicated to building AI agents for Slack. The page is titled "Quickstart: Creating a Slack agent" and walks a developer through the entire process: installing the Slack CLI, authenticating with a workspace, scaffolding a project from the Support Agent sample app (Casey), choosing an agent framework (Claude Agent SDK, OpenAI Agents SDK, or Pydantic AI), configuring environment credentials, and running the app with slack run. This is exactly the "look first" destination for someone beginning agent development — it combines setup instructions, framework guidance, and next-step resources like the Slack MCP Server integration in one place.

Why Other Options Are Incorrect:

B. slack.com/pricing – This is Slack's pricing and plan-comparison page. It covers subscription tiers, feature limits, billing, and FAQs, not how to build an AI agent.

C. api.slack.com/legal – This is Slack's terms and policies page. It contains legal notices and cookie preferences, offering no developer or agent-building guidance.

D. app.slack.com/marketplace – This is the Slack App Marketplace for finding and installing existing apps. It is aimed at end users, not developers starting an agent project.

📚 References:

Slack Developer Docs, "Quickstart: Creating a Slack agent" – Provides step-by-step instructions for building an AI-powered Slack agent using the Slack CLI, Bolt, and supported agent frameworks (Claude Agent SDK, OpenAI Agents SDK, Pydantic AI).