Free Salesforce Slack Developer Practice Test Questions

Explanation:

The Events API delivers notifications (events) to your app when activity happens in Slack that your app has subscribed to. A new message posted in a channel the app is part of is a classic example — the message.channels event fires when a message is posted in a public channel the app is a member of. Other common events include app_mention (when the app is @mentioned), message.im (DMs to the app), reaction_added (a reaction added to a message), member_joined_channel, file_shared, and app_home_opened.

To receive events, your app subscribes to specific event types, and Slack sends an HTTP POST to your Request URL for each occurrence. Your app must acknowledge within 3 seconds and can process the payload. Events are tied to Slack-side activity, so only relevant, subscribed Slack actions trigger notifications.

✅ A. A new message posted in a channel the app is part of – This triggers the message.channels event via the Events API.

❌ Why Other Options Are Incorrect:

B. A user's local clock changing – A user's device clock is unrelated to Slack; the Events API only reports Slack activity, not local device state.

C. A browser tab switch – Switching browser tabs is a client-side action and does not generate a Slack event.

D. A workspace's billing renewal – Billing events are not delivered through the Events API (billing is managed outside app event subscriptions).

📚 References:

Slack API Docs – Events API – Explains that Slack activity (e.g., messages, mentions, reactions) triggers event notifications to subscribed apps.

Slack API Docs – message.channels event – Documents the event fired when a message is posted in a public channel the app is in.

Explanation:

Workflow Builder is Slack's no-code automation tool that lets users create simple workflows without writing any code. It is designed for workspace members — not just developers — so anyone with the appropriate permissions can build workflows using a visual, drag-and-drop interface. Users can create workflows that:

Trigger on events (e.g., a new channel member, an emoji reaction, a slash command, or a scheduled time).

Take actions like sending messages, collecting form input, creating channels, or calling a webhook.

Add steps from connected apps that publish workflow steps.

The goal of Workflow Builder is to democratize automation, letting non-technical team members automate routine tasks. Developers can extend it by building custom workflow steps for their apps, but building basic workflows requires no coding — just the right workspace permissions.

✅ B. Workspace members with the appropriate permissions, without needing to code – Workflow Builder is a no-code tool available to permitted workspace members.

❌ Why Other Options Are Incorrect:

A. Only Slack employees
– Workflow Builder is a customer-facing tool; Slack employees are not the only ones who can use it.

C. Only certified developers
– No certification is required, and no coding is needed to build simple workflows. Developers are only needed to build custom steps.

D. Only Enterprise Grid org owners
– Workflow Builder is available on many plans and to regular members — not restricted to Enterprise Grid Org Owners.

References:

Slack Docs – Workflow Builder – Describes Workflow Builder as a no-code tool for automating tasks, usable by workspace members with appropriate permissions.

Slack API Docs – Workflow Steps for apps – Explains how developers extend workflows with custom steps (beyond simple, no-code flows).

Explanation:

By default, the Events API delivers notifications to your app by sending an HTTP POST request to a public HTTPS endpoint — your app's Request URL. When a subscribed event occurs in Slack (e.g., a message is posted, the app is mentioned), Slack packages the event as a JSON payload and POSTs it to the Request URL you configured in your app's settings.

For this to work, the endpoint must:
Be publicly accessible over the internet.
Use HTTPS (TLS) — Slack requires a secure endpoint.

Acknowledge the request within 3 seconds by returning HTTP 200. If it doesn't, Slack retries and may disable the event subscription.

The payload includes a type (e.g., event_callback) and the event details. Apps should verify the request signature to confirm authenticity. As an alternative to the default HTTP webhook model, apps can use Socket Mode, which delivers events over a WebSocket connection (via an app-level token) instead of a public endpoint — but the default delivery method is the HTTPS webhook POST.

✅ A. Via a webhook POST to a public HTTPS endpoint – The default Events API delivery method is an HTTP POST to your app's Request URL over HTTPS.

❌ Why Other Options Are Incorrect:

B. Via email – Slack does not deliver Events API notifications by email.

C. Via a desktop notification – Desktop notifications are a Slack client UI feature, not how events reach your app's backend.

D. Via SMS – SMS is not an Events API delivery mechanism.

📚 References:

Slack API Docs – Events API – Explains that events are delivered as HTTP POST requests to your app's Request URL.

Slack API Docs – Request URL & verification – Requires a public HTTPS endpoint and acknowledgment within 3 seconds.

Explanation:

When a Workflow Builder workflow uses the webhook trigger, Slack exposes a unique webhook URL for that workflow. To start the workflow, you send an HTTP POST request to that URL with your payload. The payload must be sent as JSON, so the request must include the header:

Slack expects the webhook trigger's request body to be JSON-formatted. Once the workflow is triggered, the JSON fields you send become variables that the workflow's steps can reference — for example, you can map a name field from the payload into a message the workflow posts. If you send the wrong Content-Type (or malformed JSON), Slack will reject or fail to parse the payload, and the workflow variables won't populate correctly.

✅ C. application/json – The webhook trigger expects a JSON body, so you must send Content-Type: application/json.

❌ Why Other Options Are Incorrect:

A. multipart/form-data – This is used for file uploads and mixed form data, not the JSON payload the webhook trigger expects.

B. text/plain – Plain text won't be parsed as structured JSON, so workflow variables can't be mapped from the payload.

D. application/x-www-form-urlencoded – This is the classic HTML form encoding, not JSON. Slack's webhook trigger expects JSON, not form-encoded data.

📚 References

Slack Docs – Webhook triggers for Workflow Builder – Explains that webhook triggers accept JSON payloads and map fields to workflow variables.

Slack API Docs – Content types / sending JSON – Documents using Content-Type: application/json for JSON request bodies.