Salesforce Certified Slack Developer Practice Exam
Prepare for the Salesforce Certified Slack Developer credential with scenario questions across the full official outline — designing interactive app flows with Block Kit, Slack’s Web and Events APIs, security and OAuth, Enterprise Grid scale, admin APIs, and app distribution — each explanation linked to the exact Slack developer documentation page, with full timed simulation in Exam mode.
Start 24-hour free trial →Slack Developer exam at a glance
- Vendor
- Salesforce (Slack)
- Credential
- Salesforce Certified Slack Developer
- Format
- 60 multiple-choice / multiple-select questions (plus up to 5 unscored)
- Duration
- 90 minutes
- Passing score
- 67%
- Cost (USD)
- $200 exam; $100 retake
- Delivery
- Proctored — test center or online
- Prerequisites
- None; 6+ months of Slack API experience and a built app recommended
- Validity
- 3 years; annual Trailhead maintenance module keeps it current
- Exam version
- Questions align to the Summer ’24 release; verify current version before scheduling
Sources: Salesforce — Certified Slack Developer Exam Guide and the Trailhead credential page. Confirm the current version, passing score, and price with Salesforce before scheduling.
About the Salesforce Certified Slack Developer credential
The Salesforce Certified Slack Developer credential validates that you can plan, design, and build custom applications on the Slack platform using Slack’s APIs. Slack is a Salesforce product, and this certification sits in the Salesforce program alongside the Slack Administrator and Slack Consultant credentials — but it is distinctly a developer exam: it assumes you can read and write JSON, work with web and event-based APIs (JSON over HTTP, and to a lesser extent WebSockets), and use at least one language such as Node.js, Python, or Java to build and deploy a web app.
The exam is scenario-driven and design-focused. Rather than testing rote syntax, it asks you to recommend the right Slack surface, component, or API for a use case: when to use a modal versus a message, when to use the Events API over Socket Mode, which OAuth scopes and tokens fit a requirement, and how to design an app for Enterprise Grid and Slack Connect. Two areas dominate the weighting — designing the interactive flow of your app (which includes Block Kit UI) and designing for security — so budget the most study time there.
One practical note: Slack recently migrated its developer documentation from api.slack.com to docs.slack.dev. PowerKram’s practice questions link every explanation to the current Slack documentation page it derives from, so a wrong answer becomes a specific page to read. For where this credential sits in the wider Salesforce and Slack landscape, see our Salesforce certification guide.
Slack Developer exam objectives and weights
The official exam outline splits across nine objectives. “Design the Interactive Flow of Your App” (which includes Block Kit) and “Design for Security” are the two heaviest and together make up nearly 40% of the exam. The percentages below are from Salesforce’s published exam guide and sum to 100.
Build common workflows and use cases; design apps that interact well with Slack’s architecture; handle user entry points; choose among webhooks, slash commands, shortcuts, interactive components, and bots; build UIs with Block Kit.
Implement the OAuth installation flow; request appropriate scopes and tokens for a use case; verify requests; communicate securely; store and retrieve data and tokens safely.
Choose the right API for a use case; implement the Web API and the Events API; distinguish Socket Mode from HTTP event delivery; tell current terms from legacy language; handle rate limits.
When to use an Admin API to automate workspace/org administration; the SCIM API for users and groups; the Audit Logs API; the Discovery API for DLP, compliance archiving, and eDiscovery; the roles/tokens required.
Design for the architecture, features, and roles of Enterprise Grid; describe an Enterprise Grid Sandbox; know when to add support for channels shared externally via Slack Connect.
Build an experience aligned with Slack’s aim to make work life simpler, more pleasant, and more productive.
Recommend how to automate and enhance a workspace; choose among Slack’s surfaces (App home, modals, messages) for use cases; identify when a team should collaborate on an app.
When to contain an app to a single workspace; share across workspaces; distinguish single-workspace, distributed, and App Directory apps; best practices for submitting to the Slack Marketplace.
When to use sample code and external resources; when to use the Bolt framework; the purpose of Block Kit Builder; use cases for Slack Developer Tools (SDT).
Weights are from Salesforce’s published exam guide (questions align to the Summer ’24 release). Confirm the current outline on the official exam guide before your exam.
Who the Slack Developer exam is for
This is a developer credential, not an admin one. Salesforce recommends candidates already have hands-on Slack API experience:
- App and integration developers building custom Slack apps, bots, and integrations with Node.js, Python, or Java who want to formalize their platform expertise.
- Backend and full-stack engineers connecting Slack to enterprise systems — ticketing, CRM, CI/CD — via the Web and Events APIs.
- Platform and DevOps engineers automating workspace operations with the Admin, SCIM, Audit Logs, and Discovery APIs.
- Salesforce developers extending their skill set into the Slack platform as Slack and Salesforce integrate more deeply.
If you administer Slack rather than build apps, the Slack Administrator credential is the better fit, and client-facing implementers may prefer the Slack Consultant exam. For the roles this developer credential supports, with salary ranges and progression, see the developer career path in our Career Hub.
What this Slack Developer practice exam delivers
Learn mode
Get the correct answer, the reasoning, and why each other option fails — immediately after each question. Ideal for the “which API or surface fits this use case” decisions that dominate the exam.
Exam mode
A timed run in the real 60-question, 90-minute format, so you build the pacing and scenario-reading stamina the actual exam demands.
Source-linked explanations
Every answer links to the exact Slack developer documentation page (docs.slack.dev) — so you learn from Slack’s own docs on Block Kit, the APIs, OAuth, and security, not just a memorized letter.
Score by objective
Results break down by the nine official objectives — so practice tells you exactly which topics to drill, whether that’s Block Kit, security, or the admin APIs.
Sample Slack Developer practice questions
Ten free scenario questions across the exam’s objectives, each with a full explanation and a source link to the Slack developer documentation it derives from. The complete bank is available with the 24-hour trial.
A developer is building a Slack app with the Bolt framework that must listen for messages containing specific keywords and respond automatically. Which Bolt listener fits?
- A slash command that users must explicitly invoke
- The app.message() listener with a string or regex pattern, which fires when matching messages are posted in channels where the app is present
- A scheduled job that polls for new messages every minute
- A webhook endpoint that receives every workspace message
Show answer & explanation
Correct: B — app.message() with a pattern. Bolt’s app.message() listener matches incoming messages against a string or regex and runs the handler on matches, enabling keyword responses without explicit user invocation.
Why not the others: A slash command (A) needs explicit invocation. Polling (C) adds latency and API load. A raw webhook (D) requires custom routing and is not how Bolt models message events.
Source: Slack — Bolt for JavaScript concepts → Further reading: PowerKram — Salesforce certification guide →A developer needs an interactive message with buttons, a dropdown, and a date picker so users can submit an expense report directly in Slack. Which UI approach fits?
- A custom HTML page opened in a browser tab
- Rich text formatting with bold and italic for visual structure
- Block Kit with interactive components (buttons, static_select, datepicker) composed into a message layout, with an action handler to process the input
- Plain text messages linking to an external form
Show answer & explanation
Correct: C — Block Kit interactive components. Block Kit is Slack’s JSON-based UI framework; interactive components post action payloads to your app, creating native in-Slack experiences.
Why not the others: Plain text with a link (D) forces context-switching. Custom HTML (A) is not natively supported in a message. Rich text (B) is visual only, not interactive.
Source: Slack — Block Kit → Further reading: PowerKram — Salesforce certification guide →An app must open a form (modal) when a user clicks a button in a message, collect several fields, and receive the submission. Which method opens the modal?
- chat.postMessage with a form attachment
- dialog.open with a dialog payload
- views.open with a modal view payload of input blocks, using the trigger_id from the button’s interaction payload
- A redirect to an external web form
Show answer & explanation
Correct: C — views.open with the trigger_id. views.open opens a modal using the trigger_id from the interaction payload; input blocks collect fields, and a view_submission event fires on submit.
Why not the others: chat.postMessage (A) sends messages, not modals. dialog.open (B) is the legacy dialog API. An external redirect (D) breaks the Slack-native flow.
Source: Slack — Modals →When a user types /ticket create, the app should open a ticket-creation modal. What must the developer configure and implement?
- A Workflow Builder step for the slash command
- Register the slash command with a request URL, implement a handler that receives the command payload, extract the trigger_id, and call views.open to show the modal
- Register the slash command in the app manifest only, with no handler
- A bot that monitors all messages for the /ticket text
Show answer & explanation
Correct: B — Register the command and handle its payload. Slash commands are registered with a name and request URL; the handler receives a POST with the command text and trigger_id, which you use to open a modal.
Why not the others: Manifest registration alone (C) has nothing to respond. Message monitoring (D) cannot intercept slash commands. Workflow Builder (A) handles built-in steps, not custom app commands.
Source: Slack — Implementing slash commands →An app previously posted a status message and now needs to change it in place from ‘Pending’ to ‘Approved’ with updated formatting. Which method fits?
- Edit the message via the Slack UI on behalf of the user
- Delete the original message and post a new one
- Post a new message in a thread under the original
- Call chat.update with the original channel and timestamp (ts), supplying the updated Block Kit payload
Show answer & explanation
Correct: D — chat.update with channel + ts. chat.update modifies an existing message in place using its channel ID and timestamp, preserving position and thread context.
Why not the others: Delete-and-repost (B) loses thread replies and position. A thread reply (C) does not change the original. Apps cannot edit messages on behalf of users (A).
Source: Slack — chat.update method →A developer must verify that incoming requests genuinely originate from Slack and not a malicious source. Which mechanism is correct?
- Validate the user’s OAuth token on every request
- Check only that the request comes from a Slack IP range
- Trust all incoming requests without verification
- Verify the request signature using the signing secret — compute an HMAC-SHA256 of the timestamp and body and compare it to the X-Slack-Signature header
Show answer & explanation
Correct: D — Verify the signing-secret signature. Slack signs each request; you recompute the HMAC-SHA256 from the timestamp and raw body with your signing secret and compare it to X-Slack-Signature, which prevents request forgery.
Why not the others: Trusting all requests (C) is insecure. IP checks (B) are insufficient. OAuth tokens (A) authenticate a user, not request origin.
Source: Slack — Verifying requests from Slack → Further reading: PowerKram — Salesforce certification guide →A developer wants their app’s functionality to appear as a reusable step in Workflow Builder so non-developers can add it to their workflows. What must they implement?
- A webhook that Workflow Builder calls directly
- A custom function defined in the app manifest with typed input/output parameters, implemented as a function handler that processes inputs and returns outputs when invoked
- A slash command that Workflow Builder references
- A bot that responds to Workflow Builder trigger messages
Show answer & explanation
Correct: B — A custom function with typed I/O. Custom functions are declared with input/output parameters and surface in Workflow Builder as steps; the handler processes inputs and returns outputs for later steps.
Why not the others: Slash commands (C) are user-invoked, not workflow steps. Raw webhooks (A) are not natively integrated as steps. A message-watching bot (D) is not a workflow step.
Source: Slack — Workflow steps → Further reading: PowerKram — Salesforce certification guide →An app calls the Web API in a burst and starts receiving HTTP 429 responses. What is the correct way to handle this?
- Retry immediately in a tight loop until the calls succeed
- Respect the Retry-After header on 429 responses, back off, and design calls to stay within the method’s rate-limit tier
- Switch to a second bot token to double the request budget
- Ignore the 429s because Slack will queue the calls automatically
Show answer & explanation
Correct: B — Honor Retry-After and back off. Slack returns HTTP 429 with a Retry-After header when you exceed a method’s rate-limit tier; the app should wait that long, back off, and design its call pattern to stay within limits.
Why not the others: Tight-loop retries (A) worsen throttling. A second token (C) violates the terms and does not raise the limit. Slack does not silently queue calls (D).
Source: Slack — Web API rate limits →A developer must distribute an app to external organizations; it needs to read channels and user profiles and post messages. Which OAuth scopes and distribution approach fit?
- Use a single workspace app token for all organizations
- Give other organizations the source code to self-host
- Share the app’s bot token directly with each organization
- Configure OAuth 2.0 with granular scopes (channels:read, users:read, chat:write), implement the OAuth installation flow, and submit to the Slack Marketplace for public distribution
Show answer & explanation
Correct: D — OAuth 2.0 with granular scopes + Marketplace distribution. The OAuth installation flow lets each external org install with explicit scope consent; granular scopes enforce least privilege, and Marketplace submission makes the app discoverable.
Why not the others: Sharing tokens (C) is a security violation. Source-code self-hosting (B) is impractical. A single workspace token (A) cannot span organizations.
Source: Slack — Installing with OAuth →A button click must be acknowledged within Slack’s 3-second timeout, but the real processing takes 30 seconds. How should the developer handle this?
- Immediately acknowledge within 3 seconds, then use the response_url or chat.update to deliver the final result asynchronously once processing completes
- Tell users to wait and hope the connection does not time out
- Queue the interaction and respond the next time the user sends a message
- Increase Slack’s timeout limit to 60 seconds
Show answer & explanation
Correct: A — Ack immediately, finish asynchronously. Slack requires acknowledgment within 3 seconds; send an immediate ack, process in the background, then deliver the result via the response_url (valid ~30 minutes) or chat.update.
Why not the others: The timeout cannot be raised (D). Waiting (B) causes timeout errors. Deferring to the next message (C) is poor UX and unreliable.
Source: Slack — Handling user interaction → Further reading: PowerKram — Slack Administrator exam →Keep going: Learning & Career resources
Slack app development is a specialized, well-paid skill as Slack becomes the interface layer for enterprise workflows and AI agents. Two PowerKram hubs back this exam.
Deep dive: exam structure, the docs migration, high-leverage topics, and study path
Exam structure and scoring
The exam is 60 multiple-choice/multiple-select questions (plus up to five unscored) in 90 minutes, with a 67% passing score. Questions align to the Summer ’24 release, and the credential is valid for three years with an annual Trailhead maintenance module. Because Slack ships platform changes regularly — the Winter ’26 maintenance module highlights new Workflow Builder, Block Kit, and Lists APIs plus updated API Terms of Service and rate-limit rules — check the exam guide and current release notes before scheduling. Read the Salesforce certification guide →
The docs.slack.dev migration
Slack moved its developer documentation from api.slack.com to docs.slack.dev. Old bookmarks and older study guides that point at api.slack.com now redirect, so use the current docs.slack.dev pages — the source links in the questions above already point to the new locations. This matters on the exam only insofar as terminology and API references should reflect the current docs, not legacy language (which the outline explicitly asks you to distinguish). See the Slack Consultant exam →
High-leverage topics
Two objectives carry the most weight: designing the interactive flow of your app (Block Kit, surfaces, slash commands, shortcuts, interactive components) at 20%, and designing for security (OAuth flow, scopes, tokens, request verification, safe storage) at 19%. Beyond those, the API objectives reward knowing when to use the Web API versus the Events API, Socket Mode versus HTTP delivery, and the admin-oriented SCIM, Audit Logs, and Discovery APIs. Rate-limit handling and the 3-second interaction acknowledgment pattern are common scenario testers. See the JavaScript Developer exam →
Realistic study path
Build a real app with Bolt (Node.js, Python, or Java): implement a slash command that opens a Block Kit modal, handle the view_submission, post and later chat.update a status message, verify request signatures with your signing secret, and complete an OAuth installation flow with least-privilege scopes. Then read the current docs.slack.dev pages for each objective and run timed practice by objective until you consistently clear 67%, weighting your time toward interactive flow and security. Developer career paths →
Frequently asked questions about the Slack Developer exam
Is the Slack Developer certification a real Salesforce credential?
What is the exam format and passing score?
What are the exam objectives and weights?
Do I need prior experience or prerequisites?
Where is the official Slack developer documentation?
Start your free 24-hour Slack Developer practice trial
Full access to 450+ questions across all nine objectives, both study modes, and source-linked explanations. No credit card required.
Start free trial →