The APIs for channel management allow your app to create and control channels within your Enterprise Grid organization.
You can achieve anything with your app that could be done with a Slack Admin's channel management tools.
That includes: creating and deleting channels, archiving and unarchiving them; and more complex tasks like connecting and disconnecting additional workspaces, and setting posting preferences.
With the help of these APIs, you can streamline and automate the task of channel management, saving your admins time and making their lives more pleasant and productive. To get started, head to the setup section.
admin.conversations:readscope allows the app to get information about channels.
admin.conversations:writescope allows the app to create and change channels.
admin.* scopes are obtained using the normal OAuth flow, but there are a few extra requirements. The OAuth installation must be initiated by an Enterprise Grid admin or owner. Also, the install must take place on the Enterprise Grid org, not on an individual workspace using the workspace switcher during the install flow.
Check out the scope documentation for more detail.
Here's a list of the most common things you'll want to do with channels:
The reference pages linked above are your best source of info for how to call these methods and what to expect in response.
If you have your channels up and running, you might want to make some modifications to who has permission to post messages and to respond in threads. If so, read on.
You can decide exactly who can post messages in your channel, and who can respond inside threads.
Here's a quick primer on the
To set either who can post or who can respond in threads, you'll use the
prefs argument with some stringified JSON. "Stringified JSON" means JSON with white space removed and fields marked by single quotations. Since this argument won't contain more complex characters, you don't need to do further encoding.
For example, to set who can post messages, use the
who_can_post field inside your
Inside your stringified JSON for
who_can_post, you can specify who the permission applies to in a few different ways.
One is by
type: you can set posting permissions to include all
admin users, or just all
users in general.
Another way to specify who the permission applies to is with a group: for example,
Finally, you can specifically list users who have the permission:
can_thread field works exactly the same inside the
prefs object, only it determines who can respond in threads. You can pass both
can_thread to the
prefs argument in this method at the same time.
Next up: an overview of setting (and getting) the connected workspaces to a given channel.
admin.conversations.setTeamsmethod. Any previously-connected workspaces you do not include will be disconnected. In other words, this method can be used to disconnect workspaces as well as connect them.
At this point, you probably already know that the reference pages linked above are the best way to determine exactly how to call these methods and what to expect in response.
One quick note: you can connect workspaces to a channel using the
admin.conversations.setTeams method. But you can also set a channel to be available across an entire Grid org with the same method, just by setting the
org_channel parameter to