Free Salesforce Slack Developer Practice Test Questions

Explanation

To manage user groups across multiple workspaces in an Enterprise Grid org using a single token, you need an org-level installation, which produces an org-wide token that works across the org's workspaces. The steps are:

1. Ensure the app is approved at the Enterprise Grid org-level — An Org Owner (or someone with the right admin permissions) must approve the app for the organization. Enterprise Grid enforces org-level app approval to control which apps are allowed.

2. Install the app at the Enterprise Grid org-level — Installing at the org level generates an org-wide token (e.g., an org-level bot/user token) that can be used to call APIs affecting user groups across the org's workspaces — without needing a separate token per workspace.

This satisfies the constraint of using a single token while managing user groups across workspaces.

✅ B. Ensure the app is approved at the Enterprise Grid org-level, then install the app at the Enterprise Grid org-level – Org approval + org-level install yields a single org-wide token.

❌ Why Other Options Are Incorrect

A. Install at org-level and also install individually on each workspace – Installing on each workspace creates multiple per-workspace tokens, which violates the "single token" constraint.

C. Approved at org-level and grant access to each workspace – Approval plus granting workspace access does not by itself produce the single org-wide token; the app must be installed at the org level.

D. Install at org-level and grant access to each workspace – You skipped the required org-level approval step, and granting workspace access isn't what generates the single org-wide token — org-level installation does (after approval).

📚 References

- Slack API Docs – Enterprise Grid & org-level apps – Explains org-level app approval and installation, and org-wide tokens for cross-workspace actions.

- Slack API Docs – Installing with OAuth / org-wide installation – Covers org-level installation producing a single org-wide token.

Explanation

Slack's Admin APIs include conversation management methods that let Org Owners and Admins manage channels across an Enterprise Grid organization at scale. These admin conversation methods are used for tasks like renaming, inviting members to, and searching/archiving public and private channels across workspaces — without needing to be a member of each channel. They are built for centralized, org-wide administration rather than day-to-day user actions.

Typical capabilities include:

- Searching for channels across the org (by name, type, etc.).
- Inviting users or groups to channels (including bulk operations).
- Renaming channels.
- Archiving/unarchiving and managing channel settings org-wide.

These methods require admin scopes (e.g., admin.conversations:*) and are only available to authorized org admins.

✅ A. Renaming, inviting to, and searching public/private channels – Correct. Admin conversation methods handle org-wide channel management, including rename, invite, and search.

❌ Why Other Options Are Incorrect

B. Compiling Bolt code – Compiling code is a development/build task done by your toolchain. Admin APIs do not compile Bolt code.

C. Designing Block Kit layouts – Block Kit layouts are designed with the Block Kit Builder or in JSON; Admin APIs do not build UI layouts.

D. Issuing app-level tokens – App-level tokens are generated in the App Dashboard / via configuration, not through admin conversation methods. Admin APIs use tokens; they don't issue them.

📚 References

- Slack API Docs – Admin API: admin.conversations. – Documents methods for searching, renaming, inviting to, archiving, and managing public/private channels org-wide.

- Slack API Docs – Admin API overview – Explains admin scopes and that these methods are for Enterprise Grid Org Owners/Admins.

Explanation

Slack's Audit Logs API returns structured entries describing security-relevant actions in an Enterprise Grid org. Each audit log entry contains four main data points:

1.Action – What happened (e.g., user_login, app_installed, channel_created), identified by an action type.
2.Actor – Who performed the action (user, app, or system), including actor type and ID.
3. Entity – What was acted upon (the target, e.g., a user, channel, file, or app), with its type and ID.
4.Context – Surrounding details such as location (IP address, workspace/enterprise), user agent, and a unique event UUID/timestamp.

Together these answer what happened, who did it, what it affected, and the circumstances around it — the foundation of an audit trail.

✅ C. Action, actor, entity, context – These are the four main data points in a Slack audit log entry.

❌ Why Other Options Are Incorrect

A. Event, user, entity, context – "Event" and "user" are not the standard field names; the correct terms are action and actor. Incorrect.

B. Action, actor, team, context – "Team" is not one of the four main data points; workspace info appears within context. Incorrect.

D. Entity, team, actor, action – Again, "team" is not a main data point, and the ordering swaps in the wrong term. Incorrect.

📚 References

- Slack API Docs – Audit Logs API – Documents entries with the four main data points: action, actor, entity, and context.

- Slack API Docs – Audit log entry schema – Details fields within each data point (actor type/ID, entity type/ID, context location/user agent, UUID).