receptionist-bot-rs

Slack bot for self-servicing automation of common or predictable tasks.

Receptionist bot aims to provide a no-code frontend for technical & non-technical users to easily automate away some of the tedious repetition that can permeate Slack as companies grow larger. Its scope is narrow: rather than replacing the first-party Slack Workflows system or becoming an entire ecosystem such as SOCless, Receptionist bot bridges the gap between the promise of Slack Workflows and the current state provided to users while also providing workflow automations for free-tier communities.

The app is designed to be highly extensible for new features in your workflows and is unopinionated with regards to its deployment infrastructure.

• Developing the bot in a local environment (with or without docker)
• How to deploy to AWS as a Server using Terraform
• How to deploy to AWS as Serverless Functions using Terraform
• Setting up the Slack App
• Supported Features
• Known Bugs & Limitations
• View UI Examples using Block Kit Builder
• Special Thanks & Shoutouts

Interacting with the Receptionist Bot

The app ships with a slash command /rec-manage that will display a UI for Creating, Editing, and Deleting Receptionist Workflow Responses

Project Structure & Contributing

This project is a monorepo, meaning it contains multiple crates or (packages) in one repository. It consists of of the following crates:

• receptionist - The core library for making a receptionist bot implementation
• rec_server - An implementation of Receptionist Bot as a standalone server or docker container
• rec_lambda_<function> - An implementation of Receptionist Bot as 3 serverless cloud functions on AWS lambda: Slash Commands, Interactions API, and Events API
• xtask - xtask exposes a small Rust CLI for build scripts related to the project, similar to a makefile or npm run.
• terraform_aws - Terraform code for deploying either as a standalone server or serverless functions
• docs - A collection of guides on deployments, project architecture, and development
• CONTRIBUTING.md

Supported Features

Events that can trigger a response

Conditions to check before triggering a response

Actions that a Response can take

Known Bugs & Limitations

Limitations

• App will not scan bot messages, hidden messages, or threaded messages to help prevent infinite loops or negatively impacting the signal-to-noise ratio of the channel.
  • listening for bot messages may be introduced in the future but only if the message condition is scoped to that single bot (user-specific message conditions have not been written yet, which blocks this bot message feature)

Bugs

Listener Validation in Modal

Intent: If listener channel is empty in the Management Modal, we return an errors object response to Slack to display an error and prevent the view closing.

Bug: The view stays open correctly, However the error does not display.

Situation Report: We are confident the http response is being sent correctly to Slack because if anything is incorrect, Slack will display a connection error in the modal. We encountered this previously when the content-type was incorrect or when the errors object contained an invalid Block_ID. Since neither of those are happening now, I am inclined to believe this is either a bug or limitation on Slack's end with the Conversations Select Section Block

• https://api.slack.com/surfaces/modals/using#displaying_errors

View UI Examples with Block Kit Builder

1. Log into Block Kit Builder
2. Select Modal Preview from the dropdown in the top left
3. Copy a json template from ./crates/receptionist/tests/generated_blocks and paste it into the Block Kit json editor

Special Thanks & Shoutouts

• @abdolence for creating the excellent slack-morphism library.
  • slack-morphism strongly types nearly everything you need to work with Slack, including block kit models which are a huge pain point when doing highly reactive & dynamic UIs like the Receptionist Bot. This app would not have been possible without his work!
  • @abdolence also quickly responded to questions with thorough answers and helpful tips
• @davidpdrsn for the Axum web application framework.
  • Axum is easy to use and is built with hyper & tokio, but also uses the Tower ecosystem so that you can share middleware/services/utilities, between any other framework that uses hyper or tonic. You can also often share code between server-side and client side implementations.
  • You can apply middlewares & Layers to only affect certain routes. In this App we use a Slack Verification Middleware from slack-morphism to protect our routes that expect to receive traffic from Slack, but not for other routes.
  • @davidpdrsn also quickly helped out when I struggled to integrate an authentication middleware.
• @yusuphisms for experimenting with the Pagerduty API to enable new bot features, helping incorporate Docker Compose & DynamoDB support, and setting up for integration tests.
• @ubaniabalogun for thoroughly designing an effective DynamoDB model to enable a wide range of queries with a single Table.
• @shadyproject for helping load test and brainstorming deployment & database strategies.
• Everyone who has worked on strum which powers up the already great Rust enums
• @bryanburgers for his work on https://github.com/zenlist/serde_dynamo which makes it easier to use dynamoDB (and the alpha branch supports the brand new aws_rust_sdk!)

Code of Conduct

https://github.com/twilio-labs/.github/blob/master/CODE_OF_CONDUCT.md