Slack-Dev-201 Salesforce Certified Slack Developer Exam Topics and Questions

This topic establishes what Slack apps can do and when you should build one. The weight is modest, but the decisions here shape everything downstream. You need to know which surface fits which job, when automation makes sense, and when collaboration on an app becomes necessary rather than optional.

How Apps in the Slack Platform is tested

Seven percent means roughly one item in fifteen, so expect two or three questions. They test your ability to match a business requirement to the right Slack surface or collaboration model. The stem describes a scenario and asks which approach fits best. Candidates lose marks by defaulting to messages when a modal would be clearer, or by recommending a solo build when the scope demands a team. The trap is choosing the surface you know rather than the one the use case requires. Read the scenario for constraints and user intent, not just for keywords.

One fifth of the exam sits here. You move from the conceptual decisions of the first topic into the mechanics of building workflows and designing interactions. Block Kit, entry points, component selection, and architectural fit all appear under this heading. The cost comes from the breadth: you need to know how workflows are constructed, how users enter them, and how to build UI that works within Slack's constraints.

– Workflows and architecture

Building common workflows means recognising the business process and translating it into a sequence of Slack interactions. The exam expects you to know what a typical approval flow, onboarding sequence, or escalation path looks like in Slack terms. Recommending an app design that interacts effectively with Slack's architecture is about understanding asynchronous messaging, event-driven patterns, and how Slack's API model constrains your choices. You cannot poll for changes, so your design must react to events. You cannot hold open connections indefinitely in HTTP mode, so your state management must account for that. The architecture question is always about fit, not feature count.

– Entry points, components, and Block Kit

Users enter your app from slash commands, shortcuts, mentions, buttons, or scheduled triggers. Handling entry points means knowing which context each one provides and how to route from there. Recommending when to use different Slack components means choosing between modals, App Home, messages, and ephemeral responses based on visibility, persistence, and user task. Block Kit is the UI layer: you build surfaces by composing blocks, elements, and composition objects. The exam tests your ability to pick the right block type for the job and to structure layouts that fit within Slack's rendering rules. A common mistake is choosing a static select when a multi-select would be clearer, or using a modal when an in-channel message would keep the conversation visible.

How Design the Interactive Flow of Your App is tested

Twenty percent means six or seven items. Expect stems that describe a workflow or UI requirement and ask you to choose the component, entry point, or Block Kit structure that fits. Some items present a partial Block Kit JSON payload and ask what it renders or where it fails. Others describe a business process and ask you to identify the correct sequence of interactions. Candidates lose marks by overcomplicating the workflow or by choosing components that do not match the visibility or persistence the scenario requires. The trap is assuming that more interactive elements make a better UI, when often a simpler message with fewer blocks is the right answer. Read for what the user needs to do, not for what the platform can do.

From interactive design you move into API implementation. Thirteen percent means this is the third-heaviest topic. You need to know when to use the Web API versus the Events API, how Socket Mode differs from HTTP delivery, how to handle rate limits, and how to distinguish current terminology from legacy language in the documentation. The cost is in the detail: each API has specific use cases, and the exam expects you to choose correctly.

– API selection and implementation

Recommending when to implement Slack's different APIs means knowing that the Web API is for actions you initiate and the Events API is for reactions to things that happen in Slack. Implementing the Web API means calling methods with the correct parameters, handling responses, and managing token scope. Implementing the Events API means subscribing to event types, verifying the request URL, and processing payloads asynchronously. The exam tests your ability to match the API to the task: if the app needs to post a message, you use the Web API; if it needs to respond when a user joins a channel, you use the Events API.

– Delivery modes, terminology, and rate limits

Socket Mode and HTTP-based event delivery differ in connection model and infrastructure requirements. Socket Mode holds a WebSocket connection open and delivers events over it, which removes the need for a public HTTP endpoint but limits scalability. HTTP delivery posts events to your endpoint, which requires you to handle verification and respond within three seconds. Differentiating between current and legacy terms matters because older documentation and community code use deprecated names, and the exam expects you to recognise both. Processing rate limits means respecting Retry-After headers, backing off when you hit a tier limit, and designing your app to stay within the platform's throughput constraints. The trap is assuming rate limits are per-method when some are per-workspace.

How Design Your Workflows: Spotlight on Slack's APIs is tested

Thirteen percent translates to four or five items. They present a scenario and ask which API or delivery mode fits, or they describe a rate limit error and ask how to handle it. Some items test your ability to distinguish a Web API call from an Events API subscription, or to identify when Socket Mode is appropriate. Candidates lose marks by choosing the Web API when the task requires reacting to an event, or by ignoring rate limit signals. The trap is treating all APIs as interchangeable, when each has a specific role. Another common error is assuming Socket Mode scales to Enterprise Grid when HTTP delivery is the better fit. Read the scenario for direction of initiation and infrastructure constraints.

Eight percent, one sub-topic. This is the principles layer: you build a user experience that aligns with Slack's commitment to making work life simpler, more pleasant, and more productive. The topic is short but the standard is high. The exam expects you to know what makes an interaction feel native to Slack, where friction appears, and how to remove it. The cost is in the judgment calls, not the mechanics.

How Design a Great User Experience is tested

Eight percent means two or three items. They describe an app behaviour or interaction pattern and ask whether it aligns with Slack's UX principles. The stems are often about reducing cognitive load, respecting user context, or avoiding unnecessary steps. Candidates lose marks by choosing designs that require too many clicks, that interrupt the user's flow without cause, or that duplicate functionality already present in Slack. The trap is assuming that more features or more configuration options improve the experience, when often the opposite is true. Read for simplicity and user intent. If the design makes the user work harder, it is wrong.

Nineteen percent makes this the second-heaviest topic. OAuth, scopes, tokens, secure communication, and safe storage all sit here. You need to know how the OAuth installation flow works, how to request the minimum scopes for a use case, which token type to use, and how to store credentials without exposing them. The cost is in the specifics: choosing the wrong scope or token type breaks the app or creates a security gap.

– OAuth, scopes, and tokens

Implementing the OAuth installation flow means handling the authorization URL, exchanging the code for tokens, and storing the result. Requesting the appropriate scopes means asking for only what the app needs to perform its function, because over-scoped apps fail security review and violate least-privilege principles. The exam expects you to match a use case to the minimum scope set. Requesting the appropriate tokens means knowing when to use a bot token versus a user token, and when to request additional tokens for specific features. Bot tokens act on behalf of the app; user tokens act on behalf of the installing user. The choice changes what the app can do and what appears in the audit log.

– Secure communication and storage

Identifying the steps to make your app communicate securely means verifying request signatures, using HTTPS for all endpoints, and validating redirect URIs during OAuth. Slack signs every request it sends, and you verify the signature to confirm the request is genuine. Storing and retrieving data and tokens safely means encrypting tokens at rest, rotating credentials, and never logging sensitive values. The trap is storing tokens in environment variables that get committed to version control, or in databases without encryption. Another mistake is failing to verify request signatures, which opens the door to replay attacks.

How Design for Security is tested

Nineteen percent means six or seven items. They describe a use case and ask which scopes or tokens are required, or they present a security scenario and ask how to mitigate the risk. Some items test your knowledge of the OAuth flow by asking what happens at each step. Others describe a storage or communication pattern and ask whether it is secure. Candidates lose marks by requesting more scopes than necessary, by choosing a user token when a bot token would suffice, or by failing to verify request signatures. The trap is assuming that HTTPS alone makes communication secure, when signature verification is also required. Read for what the app does, then choose the narrowest scope and the correct token type.

Nine percent. You design for Enterprise Grid, understand sandbox characteristics, and know when to support Slack Connect. The weight is modest but the scope is specific: if your app will run on Grid, you need to know how org-level versus workspace-level installations differ, what roles exist, and how shared channels change your data model.

How Design for Scale is tested

Nine percent means three items. They describe an Enterprise Grid scenario and ask how your app should behave, or they ask when to support Slack Connect. Some items test your knowledge of Grid roles, such as Org Owner or Workspace Admin, and what each can do. Others ask about sandbox characteristics or how to handle channels shared with external organizations. Candidates lose marks by assuming a single-workspace app design will work on Grid without modification, or by failing to account for the security and compliance requirements of shared channels. The trap is treating Grid as a larger workspace when it is a different architecture. Read for org-level versus workspace-level scope, and for whether the channel is internal or shared.

Five percent, the lightest topic. You recommend when to use sample code, the Bolt framework, Block Kit Builder, and Slack Developer Tools. The exam expects you to know what each tool does and when it saves time. The cost is low, but you still need to distinguish between them.

– Sample code, Bolt, Block Kit Builder, and SDT

Recommending when to use sample code and external resources means knowing when a starting template or reference implementation accelerates development and when it introduces unwanted dependencies. Bolt is a framework that abstracts common patterns like event handling, OAuth, and request verification. Recommending when to use it means recognising scenarios where those abstractions reduce boilerplate without hiding behaviour you need to control. Block Kit Builder is a visual tool for constructing and previewing Block Kit layouts. Its purpose is to validate JSON payloads before you send them, and its value is in catching syntax errors and layout problems early. Slack Developer Tools is a CLI and local development aid. You use it to tunnel events to your local environment, inspect payloads, and test your app without deploying. The exam expects you to know which tool fits which stage of development.

How Tools is tested

Five percent means one or two items. They describe a development task and ask which tool is appropriate. The stems are straightforward: if you need to preview a Block Kit layout, you use Block Kit Builder; if you need to handle events locally, you use Slack Developer Tools; if you want to reduce boilerplate in a new app, you consider Bolt. Candidates lose marks by recommending a tool that does not match the task, such as using Block Kit Builder to test OAuth flows or using Bolt when the app requires low-level control. The trap is assuming every app should use Bolt when sometimes the framework adds overhead without benefit. Read for the task, not for the tool you prefer.

Twelve percent. You move from building apps to managing workspaces and orgs. The Admin API, SCIM API, Audit Logs API, and Discovery API all appear here, along with the user roles required to generate tokens. The cost is in knowing which API does what and who can use it. These are administration APIs, not app-building APIs, and the use cases are different.

– Admin, SCIM, and Audit Logs APIs

Recommending when an Admin API could be used means knowing it automates workspace and org administration tasks like adding users, managing channels, and setting policies. Using the SCIM API to manage users and user groups means provisioning and deprovisioning accounts programmatically, typically integrated with an identity provider. Monitoring workspace events with the Audit Logs API means retrieving a record of actions taken in the workspace for compliance or security analysis. The exam expects you to match the API to the administrative task. If the task is user lifecycle management, you use SCIM. If it is policy enforcement or channel management, you use the Admin API. If it is compliance auditing, you use Audit Logs.

– Discovery API and required roles

Recommending when to use the Discovery API means knowing it is for data-loss prevention, compliance archiving, or eDiscovery. It retrieves message content across the org, which makes it a high-privilege API. Identifying the required user role to generate a token for these APIs means knowing that only Org Owners or Workspace Owners can create tokens with the necessary scopes, and that some APIs require Enterprise Grid. The trap is assuming any admin can generate tokens for all APIs, when role and plan tier both constrain access.

How APIs for Managing Your Slack is tested

Twelve percent means four items. They describe an administrative task and ask which API fits, or they ask which role is required to generate a token. Some items test your ability to distinguish between the Admin API and SCIM, or between Audit Logs and Discovery. Candidates lose marks by choosing the wrong API for the task or by assuming any admin can access any API. The trap is confusing the Discovery API with Audit Logs, when Discovery retrieves message content and Audit Logs retrieves actions. Another mistake is recommending an API that requires Enterprise Grid when the scenario does not specify that plan. Read for the administrative goal and the role mentioned.

Seven percent, the final topic. You examine when to contain an app to a single workspace, how to share it with other workspaces, and the differences between single-workspace, distributed, and published App Directory apps. You also learn the process and expectations for submitting an app to the Slack Directory. The weight is modest, but the distinctions matter if you plan to distribute beyond your own workspace.

– Distribution models and the App Directory

Examining why you would want to contain an app to a single workspace means understanding that some apps are workspace-specific, contain sensitive logic, or are not ready for broader use. Sharing an app with other workspaces means enabling OAuth and supporting multi-workspace installation. Differentiating between a single workspace app, a distributed app, and a published App Directory app means knowing that single-workspace apps install only where they are created, distributed apps can be installed by any workspace via OAuth but are not listed in the Directory, and published apps appear in the Directory after review. Explaining the best practices, expectations, and process to submit an app to the Slack Directory means knowing the security, UX, and documentation requirements Slack enforces, and the review steps your app goes through. The exam expects you to know which distribution model fits which scenario and what submission requires.

How Distribute Your App is tested

Seven percent means two or three items. They describe a distribution scenario and ask which model fits, or they ask about the App Directory submission process. Some items test your ability to distinguish between distributed and published apps, or to identify when single-workspace containment is appropriate. Candidates lose marks by recommending public distribution when the app is not ready, or by assuming that enabling OAuth automatically lists the app in the Directory. The trap is confusing distributed with published, when the former is any app with OAuth enabled and the latter is a subset that passes Directory review. Read for the distribution goal and the review readiness.