Skip to main content

admin.conversations.setConversationPrefs method

Welcome to the new home of Slack developer docs!

We're still building and not all features are available quite yet. Enjoy this peek into the future!

Not ready for the future? Return to the past at api.slack.com.

Usage info​

This Admin API method sets the posting permissions for a channel.

This method allows you to adjust several conversation settings. To set any of these permissions, 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.

Calling this method requires that you — the user associated with your app's token — have permission to change conversation preferences.

You can see or change the users who have permission in your Org’s Channel Management settings dashboard.

Posting permissions​

To adjust who's allowed to post in a channel, use the who_can_post field inside your prefs argument:

"prefs": "{'who_can_post':'type:admin,user:U1234'}"

Inside your stringified JSON for who_can_post, you can specify who the permission applies to in a couple different ways:

  • By type: you can set posting permissions to include all admin users, or just any user in general. The user type is only honored when admin or org_admin is also provided.

  • By list of specific users who have the permission: user:U1234 for a single user or user:U1234,user:U5678 for multiple users. If you're specifying specific people, you can select up to 100 per channel. If you exceed that maximum, you may receive the could_not_set_channel_pref error.

org_admin can only be used if the channel is an Org-Wide Channel, otherwise you may receive the invalid_value error.

The can_thread field works exactly the same inside the prefs object, except that it determines who can respond in threads. You can pass both who_can_post and can_thread to the prefs argument in this method at the same time.

Example:

"prefs": "{'who_can_post':'type:admin,user:U1234','can_thread':'type:user'}"

In addition, while you cannot return to the original "empty" state of each of these fields when the channel is first created, you can always reset the channel to allow everyone to post by using the value ra:

"prefs": "{'who_can_post':'type:ra','can_thread':'type:ra'}"

Slack Connect​

In Slack Connect channels, the same fields and values are used by the channel owner (home workspace) to control who can post in a given channel, but they have slightly different meanings:

  • type:ra means that all home and away workspace members and guests can post.
  • type:regular means that only home workspace members can post, but away workspace members and home/away workspace guests cannot.
  • type:admin means that only home admins can post, but home/away workspace members or guests cannot.
  • type:org_admin means that only home org admins can post, but home/away workspace members or guests cannot.

When listing individual users who can post in the channel, you are free to include user IDs of both home and away users.

Huddles​

The can_huddle field determines if a huddle can be started in the channel.

For example:

"prefs": "{'can_huddle':'false'}"

Channel mentions​

Channel mention restriction prefs enable_at_channel and enable_at_here can be used to place channel, here, and everyone mention restrictions in a channel.

The enable_at_channel field determines if channel mentions can be used in a channel. The enable_at_here field determines if here mentions can be used in a channel. If these channel prefs have never been set before for a channel, then the relevant mention can be used in a channel. We require that both of these prefs remain synced so if you would like to set one of these prefs, you must also update the other pref, and they must be the same value. We do this because the everyone mention restriction in general channels is also controlled by these prefs.

For example:

"prefs": "{'enable_at_channel':'false', 'enable_at_here':'false'}"

This admin scope is obtained through version two of the OAuth V2 flow, but there are a few additional requirements. The app requesting this scope must be installed by an admin or Owner of an Enterprise Grid organization. Also, the app must be installed on the entire org, not on an individual workspace. See below for more details.

If the app is installed by an Org Admin or Owner, ensure the Channel Management settings provide the appropriate permissions. The Org Admin or Owner installing the app must have the Channel Management role, and must also be granted access to Public channels and Private channels within this role. If these criteria aren't met, the Org Admin or Owner will receive a not_allowed error when attempting to install an app.

Admin API endpoints reach across an entire Enterprise Grid organization, not individual workspaces.

For a token to be imbued with Admin scopes, it must be obtained from installing an app on the entire Grid org, not just a workspace within the organization.

To configure and install an app supporting Admin API endpoints on your Enterprise Grid organization:

  1. Create a new Slack app. Your app will need to be able to handle a standard OAuth 2 flow.
  2. In the app's settings, select OAuth & Permissions from the left navigation. Scroll down to the section titled Scopes and add the admin.* scope you want. Click the Save Changes button.
  3. In the app's settings, select Manage Distribution from the left navigation. Under the section titled Share Your App with Other Workspaces, make sure all four sections have the green check. Then click the green Activate Public Distribution button.
  4. Under the Share Your App with Your Workspace section, copy the Sharable URL and paste it into a browser to initiate the OAuth handshake that will install the app on your organization. You must be logged in as an admin or Owner of your Enterprise Grid organization to install the app.
  5. Check the dropdown in the upper right of the installation screen to make sure you are installing the app on the organization, not an individual workspace within the organization. See the image below for a visual.
  6. Once your app completes the OAuth flow, you will be granted an OAuth token that can be used for calling Admin API methods for your organization.

When installing an app to use an Admin API endpoint, be sure to install it on your Grid organization, not a workspace within the organization.

Response​