Cert++
  1. Home
  3. Slack Developer

Slack Developer

Checklist progressProgress

0/255Learned

Slack Developer Study Checklist
  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Marketing Cloud Account Engagement Specialist
  • Marketing Cloud Next Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Communications AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • Public Sector Solutions AP
  • Revenue Cloud Consultant
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Next Consultant
  • Tableau Architect
  • Slack Administrator
  • Slack Consultant
  • Slack Developer

Checklist progressProgress

0/255Learned

Recommend how to automate and/or enhance operations on a Slack workspace

0/7

  • Identifying workspace processes worth automating
  • Actions a Slack app can take in a workspace
  • Workflow Builder versus a custom Slack app for automating a process
  • Workflow trigger types and when each fits
  • Built-in Slack functions versus third-party connector steps
  • Custom workflow steps built as app functions
  • Bringing external system events into Slack

Recommend when to use Slack’s different surfaces (user touchpoints including App home, modals and messages) for a range of use cases

0/8

App Home tabs and their customization options

Learn this concept
Unseen

Home tab content design and per-user tailoring

Learn this concept
Unseen

Publishing and refreshing Home tab views

Learn this concept
Unseen

Modal design for focused input

Learn this concept
Unseen

Interactive messages for in-conversation actions

Learn this concept
Unseen

Ephemeral messages versus direct messages

Learn this concept
Unseen

Choosing App Home, modals or messages for a use case

Learn this concept
Unseen

Combining Home tab, modals and messages in one workflow

Learn this concept
Unseen

Identify when to set up a team to collaborate on a Slack app

0/4

  • When to add backup collaborators to a Slack app
  • App collaborator capabilities and guest collaborator limits
  • Managing collaborators from app settings and the Slack CLI
  • Restoring access to internal apps without active collaborators
  • Core components of a Slack workflow
  • Identifying business processes suited to Slack apps and workflows
  • Choosing Slack steps, connector steps or custom steps in a workflow
  • Defining a custom workflow step in an app manifest
  • Completing a custom workflow step's execution
  • Interactive approval request flow in messages
  • Custom workflow step hosting options and limitations
  • Distributing apps that contain custom workflow steps
  • Automatic versus user invocations of a Slack app
  • Scheduled, external-service and event-driven app invocations
  • Request URL configuration for interactivity
  • Interaction payload types and the type field
  • Acknowledgment response timing for interaction payloads
  • Choosing how to respond to an interaction payload
  • response_url message responses versus Web API posting
  • Chaining interactions into multi-step app workflows
  • Designing for workspace size, locales, devices and settings
  • Designing for user types, roles and app access
  • Global shortcuts versus message shortcuts
  • Creating and configuring app shortcuts
  • Responding to global and message shortcut invocations
  • Slash commands as a workflow entry point
  • Choosing a user entry point for an app workflow
  • Choosing the right surface for an app need
  • App Home tabs and publishing the Home tab
  • Opening modals in response to user interactions
  • Modal view objects and the modal view stack
  • Blocks, block elements and composition objects
  • Choosing layout blocks for a structured message or view
  • Choosing interactive elements for a user input need
  • Select menu option sources and the Options Load URL
  • Identifying blocks and elements with block_id and action_id
  • Input blocks versus actions blocks for collecting modal data
  • Responding to modal submissions with response_action
  • Passing state between interactions with private_metadata
  • Top-level text fallback and accessibility in block messages
  • Block limits and block availability per app surface
  • Web API versus Events API for an app requirement
  • Incoming webhooks versus chat.postMessage for posting messages
  • Direct API calls versus a Bolt or SDK-based app
  • Specialized Slack APIs for administration, compliance and service health
  • Web API request formatting and token placement
  • Interpreting Web API responses and method error codes
  • Choosing a Web API method for a common app task
  • Bolt listener client versus top-level app.client for Web API calls
  • Cursor-based pagination for Web API collection methods
  • Event Subscriptions setup and request URL verification
  • Choosing event types for an app's use case
  • Bot events versus workspace events subscriptions
  • Event subscription scopes and reinstallation
  • Events API event wrapper and payload fields
  • Handling Events API events with Bolt listeners
  • Acknowledging event deliveries and Slack retry behavior
  • App uninstall and token revocation events
  • HTTP versus WebSocket connection characteristics for Slack apps
  • Choosing Socket Mode or HTTP request URLs for an app's environment
  • Enabling Socket Mode and its effect on app configuration
  • App-level tokens and apps.connections.open in Socket Mode
  • Running a Bolt app in Socket Mode versus HTTP mode
  • Event delivery mode for Slack Marketplace and distributed apps
  • Legacy, deprecated and retired status of platform features
  • Legacy custom integrations and their Slack app equivalents
  • Classic apps versus granular-permission Slack apps
  • OAuth v1 versus OAuth v2 installation endpoints
  • Deprecated perspectival scopes and their granular replacements
  • Legacy RTM API versus Events API and Socket Mode
  • Deprecated verification token versus signing secret
  • Legacy message attachments versus Block Kit blocks
  • Legacy dialogs versus modals for collecting user input
  • Web API rate limit tiers and how they are scoped
  • Burst limits versus rate limits
  • Responding to HTTP 429 and the Retry-After header
  • Built-in rate limit handling in Bolt and the Slack SDKs
  • Message posting and incoming webhook rate limits
  • Events API delivery limits and the app_rate_limited event
  • Workflow trigger rate limits
  • SCIM API rate limits
  • Building with empathy for the end user
  • Onboarding and in-app help for users new to the app
  • Bot user naming and renaming
  • Message attachment bar and app profile colors
  • Slash command naming and collisions
  • Composing clear, scannable Block Kit messages
  • Ephemeral versus in-channel app responses
  • App notification volume and etiquette
  • Timezone-aware timing of app notifications
  • Localizing app language for users and channels
  • Updating messages after a user interacts
  • Communicating errors and input validation to users
  • Accessible app content for all users
  • Slack desktop versus mobile client considerations
  • User preferences that change how app content appears
  • Workspace-level settings that constrain app messages
  • Accounting for guests, admins and bot users in app design
  • Designing for small and very large workspaces
  • Developer Policy user experience obligations
  • Single-workspace token setup versus OAuth for multi-workspace apps
  • Steps of the v2 OAuth installation flow
  • Declaring bot and user scopes for installation
  • Redirect URL configuration and matching rules
  • State parameter and state stores for CSRF protection
  • Code exchange with oauth.v2.access
  • Tokens and installation details in the oauth.v2.access response
  • Bolt built-in OAuth setup and install routes
  • Incoming webhooks provisioned through OAuth installation
  • Requesting additional user authorizations after installation
  • Deriving a least-privilege scope list from an app's methods and events
  • Conversation-type scope families for public, private, DM and group DM access
  • Choosing among message-posting scopes
  • Scopes behind slash commands, shortcuts and link unfurling
  • Matching requested scopes to supported token types
  • Sign in with Slack scopes versus Add to Slack installation
  • Admin API scopes and their installation requirements
  • Adding or removing scopes on an installed app
  • Bot tokens versus user tokens for an app's actions
  • App-level tokens and the jobs they serve
  • Configuration tokens for the App Manifest APIs
  • Service tokens for Slack CLI automation
  • Workflow tokens and borrowed channel visibility
  • Identifying Slack token types by prefix
  • Legacy bot and workspace tokens versus granular v2 bot tokens
  • Signing secret signature verification for incoming Slack requests
  • Request timestamp checks against replay attacks
  • Built-in request verification in Bolt frameworks
  • TLS requirements for connections to Slack
  • Transmitting tokens over HTTP: POST requests and TLS
  • Verifying the connecting account after an enterprise OAuth install
  • Outbound domain restrictions for Slack-hosted functions
  • Access control and input validation for workflow functions and triggers
  • Keeping app credentials out of code: development versus production
  • Installation stores for multi-workspace token persistence
  • Retrieving the right token for each workspace, org or user
  • Encrypting stored tokens and securing backups and hosts
  • Keeping tokens out of logs, error messages and the UI
  • Regenerating the client secret and signing secret
  • Token rotation: expiring access tokens and refresh calls
  • Automatic token rotation in Bolt and InstallProvider
  • Deleting and revoking stored tokens when access ends
  • Secrets and sensitive data in Slack-hosted workflow apps
  • Safe storage and querying with Slack datastores
  • Enterprise org architecture of organizations and workspaces
  • Global user IDs versus local user IDs
  • User ID translation and migration to global user IDs
  • Detecting and storing Enterprise org context with enterprise_id
  • Opting an app into organization-wide deployment
  • Enterprise Grid admin roles and app approval for org installs
  • Org-wide installation flow and adding the app to workspaces
  • Scope inheritance from an org-wide installation
  • Token storage design for organization-ready apps
  • Handling users from other workspaces in an Enterprise org
  • Multi-workspace channels versus Slack Connect channels
  • Channel IDs versus channel names with chat.postMessage in org-ready apps
  • Slash command behavior in Enterprise org workspaces
  • Legacy RTM API and legacy bots in Enterprise orgs
  • Slack CLI development on an Enterprise Grid organization
  • Developer sandbox as an Enterprise org test environment
  • Regular workspace versus developer sandbox versus partner sandbox
  • Developer sandbox capacity limits
  • Developer sandbox feature restrictions
  • Sandbox lifespan, extension and archival lifecycle
  • Enterprise admin governance and policy inheritance for sandboxes
  • Deciding when an app must support Slack Connect channels
  • Conversations API and channel IDs for Slack Connect channels
  • Determining privacy and type of an externally shared channel
  • Detecting when a channel becomes shared or unshared
  • Channel ID changes when channels are shared or unshared
  • External members and strangers in shared channels
  • Referencing and messaging external users in shared channels
  • Slack Connect app design considerations for external users
  • Slack Connect API scopes for invitations and channel management
  • Slack Connect invitation lifecycle with API methods and events
  • App blueprints and code samples as starting points for common app patterns
  • First-party Slack tools versus community-developed libraries
  • Slack developer support channels, issue trackers and changelog
  • Built-in capabilities of the Bolt framework
  • Bolt framework versus the Slack SDKs for custom app foundations
  • Bolt versus Deno Slack SDK and Workflow Builder by hosting model
  • Purpose and value of Block Kit Builder in Slack app UI design
  • Slack Developer Tools (SDT) app purpose and capabilities
  • App manifests for setting up and managing app configuration
  • Slack CLI commands across the app development lifecycle
  • Admin API purpose and trade-offs against the admin dashboard
  • Admin API plan availability and admin scope requirements
  • Programmatic workspace creation and user assignment at scale
  • Automated approval of workspace invite requests
  • Admin, owner and system role assignment through admin methods
  • Automated app approval and restriction workflows across an org
  • Session reset for lost or stolen devices
  • Channel management and bulk channel lifecycle across workspaces
  • Custom retention periods for specific conversations via admin methods
  • IdP group default channels versus private channel allowlists
  • Admin API versus SCIM, Audit Logs and Discovery APIs for an admin need
  • When to use the SCIM API versus other Slack admin APIs
  • SCIM API authorization: admin scope and Bearer token
  • SCIM Users and Groups endpoints and HTTP methods
  • SCIM user attributes and Slack profile field mapping
  • Deprovisioning and deactivating users with SCIM
  • Provisioning guest accounts through SCIM
  • Managing user groups and IdP groups with SCIM
  • SCIM 1.1 versus SCIM 2.0 in Slack
  • Audit Logs API use cases and limitations
  • auditlogs:read scope and user token requirements
  • Audit Logs API endpoints and what each returns
  • Anatomy of an audit event record
  • Filtering and paginating results from the logs endpoint
  • Audit Logs API rate limits versus Web API rate limits
  • Discovery API purpose and permitted use cases
  • eDiscovery versus DLP apps built on the Discovery API
  • Discovery API data coverage, export format and retention interplay
  • Discovery API versus Audit Logs API for compliance needs
  • Discovery API versus conversations.history for org-wide message capture
  • Enterprise org roles that can install apps requesting admin scopes
  • Org-level installation of apps that need admin tokens
  • SCIM API token generation roles on Business+ versus Enterprise
  • SCIM token permission ceiling and token-holder role retention
  • Owner requirement for Audit Logs API tokens
  • Roles that can enable the Discovery API and install its apps
  • When to keep an app undistributed in a single workspace
  • Install App page tokens versus an OAuth 2.0 install flow
  • Preparing an app for distribution to other workspaces
  • Activating public distribution and the install tools it unlocks
  • Deactivating public distribution versus discontinuing a Marketplace listing
  • Uninstall handling for apps installed on multiple workspaces
  • Private distribution of org-ready apps across an Enterprise org
  • Tokens and scopes when an app moves to organization-wide deployment
  • Single-workspace, unlisted distributed and Marketplace-listed apps compared
  • Unlisted distribution versus a Marketplace listing for a rollout stage
  • Retired workspace apps versus current single-workspace Slack apps
  • Slack Marketplace submission prerequisites
  • App types unsuitable for Slack Marketplace listing
  • Slack Marketplace listing content guidelines
  • App Developer Policy data and privacy obligations
  • Security and privacy design expected of Marketplace apps
  • Slack Marketplace review lifecycle and launch planning
  • Direct Install URL versus landing page installation
  • App Suggestions for published Marketplace apps

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other Slack Developer studiers.

Go to Discord
  1. Slack Developer Checklist
  3. Apps in the Slack Platform

Combining Home tab, modals and messages in one workflow

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 255 concepts on the Salesforce Slack Developer exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptWhen to add backup collaborators to a Slack app

Checklist progress

0/255 (0%)

0 of 255 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other Slack Developer studiers.

Go to Discord
Close
  1. Slack Developer Checklist
  3. Apps in the Slack Platform
Combining Home tab, modals and messages in one workflow

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 255 concepts on the Salesforce Slack Developer exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptWhen to add backup collaborators to a Slack app

Explainer

A Slack app can show content on several surfaces. Three common ones are the App Home, modals and messages, and each fits a different job. The App Home is a private personal workspace, a modal is a short focused task such as a form, and a message is a shared update in a conversation. Strong apps chain these surfaces so each step of a user's workflow happens on the surface that fits it.
Core information
  • A surface is a distinct UI container where users interact with your app. Pick one by asking where the user is when they need the content and what they are trying to do. A quick update or notification fits a message, a personal workspace for your app fits the App Home, and collecting input or showing a focused task fits a modal.
More details and nuances
  • An app cannot open a modal on its own. views.open needs a valid trigger_id, which comes only from an interaction payload after a user uses one of the app's entry points, such as a button click or a slash command. The trigger_id expires 3 seconds after it is sent, so call views.open right away. This rule makes sure modals appear only with the user's express permission.

Explainer

A Slack app can show content on several surfaces. Three common ones are the App Home, modals and messages, and each fits a different job. The App Home is a private personal workspace, a modal is a short focused task such as a form, and a message is a shared update in a conversation. Strong apps chain these surfaces so each step of a user's workflow happens on the surface that fits it.
Core information
  • A surface is a distinct UI container where users interact with your app. Pick one by asking where the user is when they need the content and what they are trying to do. A quick update or notification fits a message, a personal workspace for your app fits the App Home, and collecting input or showing a focused task fits a modal.
More details and nuances
  • An app cannot open a modal on its own. views.open needs a valid trigger_id, which comes only from an interaction payload after a user uses one of the app's entry points, such as a button click or a slash command. The trigger_id expires 3 seconds after it is sent, so call views.open right away. This rule makes sure modals appear only with the user's express permission.