The RTM API's presence_change event is now only available via presence subscriptions and rtm.start no longer includes user presence status in its response.
We incrementally announced these changes in June and October 2017.
Today, we're also announcing the deprecation of the optional presence parameter in users.list. Beginning September 26th, 2018, the presence parameter and corresponding fields will no longer be available from users.list.
Developers utilizing user presence state in their applications and integrations should review this guide to the many recent and coming changes to presence.
Update: users.setActive is also deprecated due to underlying functionality not being available in our most modern message servers.
The Web API method users.list will no longer accept the optional presence parameter, which instructs the method to return a presence field with every user object.
Until September 26th 2018, you'll find accurate presence reporting capped at 500 results in large workspaces.
To recap everything that has changed recently with presence:
presence_change events without a subscription.presence_sub.rtm.start will no longer include initial presence fields for each user.users.list now caps accurate presence reporting at 500 users per workspace. Use users.getPresence and/or presence subscriptions instead.presence_query write event over RTM to query the current presence status of a list of 500 users.users.setActive no longer prevents users from being marked inactive and will completely cease functioning May 8, 2018.If your app uses presence_change events you must subscribe to them before delivery. If you don't need real time presence for every user, use users.getPresence ad-hoc to look up user presence by ID.
If your app uses the presence parameter on users.list or relies on the presence field in user objects appearing in rtm.start, you'll want to look up presence on demand using users.getPresence or the presence_query instead.
Neither presence_query nor users.getPresence are intended for frequent, bulk usage. We recommend reducing your dependency on a complete picture of user presence and instead look up presence ad hoc only when it's absolutely necessary for operations.
presence_sub write event to establish subscriptions.presence_query write event to report on users' current presence status.If you relied on users.setActive to prevent a user from being set away, you'll need to maintain presence another way like opening a RTM connection or using users.setPresence.
By not receiving the presence_change events your app is looking for, or by not getting the initial state of presence from rtm.start or users.list with the presence parameter, your app won't know whether users are present or not (that is, active or away).
If your app or bot only contacts users it detects as active via presence, your bot may have trouble interacting with users.
If your app tracks presence for some other reason, the tracking might not be accurate.
If your app is already using subscriptions but is not batching presence events, you may receive floods of presence_change events in large workspaces.
If your app only uses users.getPresence to determine presence, nothing changes. users.getPresence functions as usual.
If your app sets presence to true or 1 on users.list, you'll need to adapt to using users.getPresence and/or presence subscriptions by September 26, 2018. By doing nothing now, your presence results are capped at 500 users.
Your requests to users.setActive will appear successful but will not actually prevent a user from being marked away. Eventually, the method calls will return a HTTP 400-series code.
As of January 2018, presence subscriptions are already required and rtm.start no longer returns presence for its list of users.
On May 8, 2018 users.setActivewill completely cease functioning May 8, 2018. Until then, it is a no-op.
On September 26, 2018, the optional presence parameter in users.list will no longer function.
Please contact us with your concerns at feedback@slack.com