Overview (V2)
Introduction
Slack is a versatile solution for workforce communication, bringing together instant messaging, file sharing, and third-party application integrations.
We've created a custom Admin By Request app for Slack which enables users to handle (i.e., approve, deny, and view) requests for administrative access from within a dedicated Slack channel. This guide provides a step-by-step guide on how to configure Version 2 of the application and integrate it into your Slack workspace.
Version 2 of the Slack integration introduces several significant improvements over V1:
-
Sub Settings Name scoping - channels can be configured to receive only requests that match a specific Sub Settings Name, enabling targeted routing across multiple channels within the same workspace.
-
Multi-channel synchronization - when a request is handled in any channel (or in the Admin By Request portal), all other channels that received the same request automatically update their messages to reflect the outcome and where it was handled.
-
Portal-handled notification - if a request is approved or denied in the Admin By Request portal or through any other integration rather than through Slack, all Slack channels are updated to indicate it was handled outside of Slack.
-
Run As Admin program details - Run As Admin request messages now include the program version, program path, and scan result alongside the standard request information.
-
Deny reason - when denying a request from Slack, a deny reason can be entered; it is recorded in the audit log.
-
Approver identity - the Slack message now shows who approved or denied the request. If it was handled in Slack, the approver's Slack display name is shown. If it was handled in the portal, the portal admin's username is shown.
-
Auditlog attribution - if the Slack user's email matches a portal admin's email, the portal admin's name is written to the auditlog. If no match is found, the "Approved by" field is omitted from the auditlog entry.
-
User notification - optionally, the requesting user receives a direct message in Slack when their request is handled, provided their endpoint email address matches their Slack account email.
Assumptions / Limitations
The tasks described in this guide assume that the user has access to Slack, the Admin By Request User Portal, and some familiarity with both environments.
The access provided to users through our integrations overrides User Portal settings.
Once the Slack integration described in this guide is configured, all users with access to the Slack channel(s) created in Task A will have the ability to approve or deny requests via Slack, regardless of whether they have been granted these abilities in your Admin By Request User Portal Sub-Settings.
Prerequisites
Before setting up the integration, the following need to be in place:
-
A Slack workspace that the organization uses for internal communication. The integration is installed into a specific workspace, and the channel(s) created for requests must belong to that workspace.
-
An ABR API key. API keys are generated in the ABR portal under Settings > Tenant Settings > Data > API KEYS. Create a new key, give it a descriptive name ("Slack" is fine), and click the Save button to activate it.
Each integration should have its own dedicated API key - this makes it easier to revoke a specific connection without affecting others.
Existing API Keys for your tenant can be found in the portal under Settings > Tenant Settings > Data > API KEYS. Your API prefix (data center) is shown at the bottom of that page under About API Keys.
-
Access to the ABR portal with sufficient permissions to configure integrations (the Settings permission for a user in Logins > User Logins > [User]).
-
A Channel plan for your environment. Decide whether to start with a single global channel (which will receive all requests from all endpoints) or multiple channels with sub-setting scoping (V2 only). This decision affects how you structure the setup.
V1 and V2 of the Slack integration are independent and cannot be updated in place. To use V2, you must remove the existing V1 integration and complete the V2 installation described in this guide.
V1 will continue to function until it is removed. You can run both integrations in parallel during a transition period if needed.
Something Missing?
If you’ve identified a bug or have a suggestion for this integration, or another SIEM integration you’d like us to add, contact us here and we’ll see what we can do.
The task descriptions in this guide (and screenshots in particular) cover the state of Slack V2 at the time of writing. While every effort is made to ensure currency, the screens you see during setup may look a little different, especially color schemes and the placement of buttons and links.
Related Articles
This guide may refer to, and should be read in conjunction with, the following:
-
Commitments and responsibilities in ABR's Data Processing Agreement
-
Support provisions in ABR's Terms and Conditions and Customer Support Services
-
Collection, use and disclosure of personal data in ABR's Privacy Policy and Data Privacy Settings
Refer also to ABR's Trust Center documents.
This guide is available in PDF format:

