Slack-based internal tool · Multi-city · Excel backend
Confidentiality note
This case study is anonymized. No customer data, internal workbook paths, Slack IDs, credentials, private workflow exports, or company-sensitive identifiers are published.
Overview
I designed and built a Slack-based reclamation management system that turns Slack into an internal operations interface for handling reclamation cases across multiple cities.
The system combines Slack App Home, Slack modals, n8n, Microsoft Graph, and Excel into one workflow-driven case management tool.
Instead of manually opening Excel files for every action, users can create new reclamation cases, search existing cases, update records, generate reports, and receive confirmation messages directly inside Slack.
The workflow uses Slack App Home as the user interface, n8n as the automation backend, and Excel as the operational data layer.
The challenge
Reclamation cases had to be tracked across multiple operational locations, with different statuses, priorities, responsible people, customer details, financial values, risk levels, and follow-up notes.
The challenge was to create a simple internal interface that allowed the team to manage reclamations directly from Slack without manually navigating city-specific Excel sheets for every action.
The system needed to support creating new cases, searching existing cases, updating case information, generating city-based reports, and giving users immediate feedback after their actions.
What I did
I designed, built, tested, and maintained the automation layer that turns Slack into an internal reclamation management interface.
My work included building the Slack App Home dashboard, handling Slack interactions, parsing button clicks and modal submissions, opening structured modals, reading and writing Excel data through Microsoft Graph, generating city-based reports, sending confirmation messages, and routing user actions through n8n.
System flow
Core modules
Slack App Home Dashboard
The Slack App Home acts as the main user interface. It displays a reclamation dashboard with status counts across multiple cities and provides action buttons for creating, updating, searching, reporting, and emailing reclamation cases. The dashboard reads city-specific Excel worksheets and calculates case counts by status, including active, completed, on-hold, cancelled, and total cases.
Interaction Router
A central interaction workflow receives Slack button clicks and modal submissions. It parses the Slack payload, checks the action type, detects the selected city, validates the user, and routes the request into the correct workflow branch. This allows one backend workflow to handle multiple actions: new, update, search, report, and email.
New Reclamation Modal
New reclamation cases are created through a structured Slack modal. The modal captures project company, customer name, phone, address, priority, responsible person, report date, status, risk level, reclamation value, restage value, damage description, current status notes, info initials, and assigned collaborator.
Excel Operational Data Layer
The system uses Excel as the operational data layer. Each city has its own worksheet, and the workflows read, search, append, and update rows through Microsoft Graph. The usedRange endpoint returns the active worksheet range used by the workflow logic.
Search and Update Flow
Users can search reclamation cases by company, customer name, or address. Matching results are returned through Slack, allowing the user to identify the correct case and continue into an update flow without manually opening the Excel workbook.
Reporting and Summary Flow
The reporting workflow calculates summaries for one city or all cities. Users select a date range and receive a Slack report showing total cases, cases in progress, completed, on-hold, cancelled, reclamation value, paid value, open value, and city-specific or all-city summaries.
Confirmation Messages
After a new case is written to Excel, the user receives a structured Slack confirmation including city, row reference, company, customer, phone, address, priority, status, risk, value, responsible person, and notes. This gives immediate feedback that the case was saved successfully.
Technical decisions
Slack as the internal user interface
Slack was used as the front-end because the team already worked there. Instead of creating a separate web application, the workflow brings the operational interface into an existing communication tool.
n8n as the backend orchestration layer
n8n handles the automation backend: webhooks, routing, modal preparation, Excel operations, report calculations, and Slack responses.
Excel as the operational data layer
Excel remained the backend data store because it was already part of the operational process and was understandable for non-technical users.
City-based worksheet structure
The system separates records by city, allowing each operational location to keep its own data while still supporting all-city summaries.
Structured Slack modals
Instead of free-text messages, structured modals are used to collect consistent input and reduce ambiguity.
User feedback after every action
Confirmation DMs and Slack responses help users know when a case was created, updated, searched, or reported successfully.
Reliability patterns
The architecture separates the dashboard workflow from the interaction workflow, making the system easier to understand and maintain.
The outcome
The automation made the reclamation process more structured and easier to manage directly from Slack.
It reduced the need to manually navigate Excel files for everyday actions and gave the team a central place to create, search, update, and report reclamation cases.
The most important impact was operational visibility: users could see reclamation status across cities, create structured records, search existing cases, generate reports, and receive immediate confirmation after actions.
Tech stack
Proof / Evidence
This case study is based on a real Slack-based internal case management workflow. The architecture is documented openly. The full workflow JSON is kept private to protect customer data, Slack workspace identifiers, and internal workbook references.
Anonymized architecture diagram
An anonymized flow showing the Slack-based reclamation case management system: users interact through App Home and modals, actions are routed through n8n, data is stored in Excel via Microsoft Graph, and confirmations are sent back through Slack.
Public code & documentation
Slack-based internal case management pattern with App Home dashboard, structured modals, Microsoft 365 backend, and an LLM email-drafting assistant. Architecture docs and sanitized code snippets extracted from this production system.
Code excerpt — Slack payload parser with allow-list
The first node of the interaction-handling workflow. Parses the URL-encoded Slack interaction payload, then checks the requesting user against a hard-coded allow-list before any downstream branch executes — appropriate for a closed team, documented as the right shape to replace for broader use.
Full version, with action and city extraction, in snippets/slack-payload-parser.js. Four other snippets in the same repository cover Block Kit modal building, Slack thread context extraction, LLM agent prompt construction, and date-range summary aggregation.
Confidentiality & Publication Note
This case study describes a real Slack-based internal case management workflow in an anonymized form. The public repository documents the system architecture, Slack interaction logic, modal structure, Excel/Microsoft Graph data layer, and reporting flow. Customer data, phone numbers, addresses, Slack user IDs, Slack channel IDs, internal workbook paths, credentials, webhook URLs, and raw workflow exports are kept private.