Error Trapping with Slack

We use Slack notifications to move from reacting to client issues to proactively watching for concerns before they require escalation. The following post fleshes out our approach and gives some tech tips as well.

Our clients know their business operations best, but as consultants we are charged with marrying those needs with technology solutions that address workflows, goals, scalability, data structures, security, and more. We usually have to work from a distance: we cannot physically be onsite and depend on immediate feedback from our clients on how the software we deployed works day to day. Sometimes the only feedback we receive are narrowly focused bug reports or perhaps just disconnects on expectations.

We strive to keep our clients immensely happy. Happy clients stick around and tell their friends about us, but most importantly – their happiness shows us we’re making a real impact. The best way we’ve found to ensure client happiness is to be proactive, not reactive. We aim to bridge the gap with immediate insight and fix things before a concern or complaint makes its way back to us.

What’s Really Happening Over There?

Along comes Slack, a popular tool to help communication flow between teams, tools, clients, and partners—wherever and whenever you’re working. We spend more time in Slack here at Codence than any other technology. Real-time communication is a vital tool in our remote, distributed world. Now imagine using Slack to alert team members proactively on behalf of our clients:

• Can we identify issues with automated error trapping?
• Can we provide solutions to potential problems before the client is even aware?
• Can we fix and report to clients before they even have a chance to log a bug?
• Can we provide additional training due to common occurrences?
• Can we improve our code to reflect actual, observed behavior?

Slack to the Rescue

Our situation may be like many of yours. We have a client with many users and several team members working on the project, all of us in different time zones. Email is the primary tool when our client communicates with us, their organization does not use Slack, but that doesn’t mean we cannot take advantage of it for the project.

We have a dedicated Slack channel for this client, our internal team uses it daily to ask questions, post responses and handle all things related to the work. But remember, our client only corresponds with us by email. These emails range widely from meeting invites to bug reports to much more strategic concerns, all delivered to our respective inboxes at any time of the day.

When an email prompts a task or problem, our secondary action is to create a ticket (a task or issue in our project management system). Of course, we also reply to the client that we have received their email and will get back to them as soon as we have determined the solution. Someone on our team works towards the solution and then communicates back to the client that all is well with the world again.

We are reacting to a problem, not preventing it. Worse yet, the client is involved in the process of reporting an issue. Third, there’s time involved for all this back-and-forth. They must take time out of their day to report a problem, wait for a response, and re-test at the end.

Our goal was to get in front of these emails. We knew we could do better and be more efficient with our time, so we leveraged Charlie Bailey’s FileMaker + Slack: A Simple API Integration to help us improve.

Constructing the Error Message

Once the initial integration is set up – the rest is easy. We simply construct the message we want our Slack private channel to receive and pass that as a parameter to our dedicated Slack notification script within Claris FileMaker. Here is a simple implementation we built to test our communication.

1. Create a script with the following script steps.
2. Construct the message
3. Execute the script
4. View the Slack channel’s notification
   

We’ve used this simple approach to give us information on performance lags, error messages within scripted routines, results from automated tests, and more.

Endless Options

The options for Slack notifications are endless. As Claris FileMaker developers, every system we develop should trap for errors. Even after a system has been tested and deployed, it is inevitable that other issues will come up. If you bake in a modular approach, you can adopt increasingly useful and specific Slack notifications as time goes on.

1. Create a script that executes the Slack Notification
   Script Name Example: Send Slack Notification
2. Determine where (what scripts) and when (what script steps) Slack notifications will be used in your application.
3. When you want to send an error trap notification, set a $variable with a meaningful message
4. Call the Slack Notification script you created in Step 1 above.
   Pass the message $variable to the script.

Make sure to provide enough context in your message that you and your team can react quickly to the notification. Remember, as you are writing the message it may make perfect sense to you, but you are not the only team member who will be notified. If you are on vacation or not available to quickly respond, someone else will have to interpret the message for you.

Use Claris FileMaker’s native Get Functions to assist your team in troubleshooting.

Here is an example of some information that can be passed as your $message.

One Life-Saving Example

We built an inventory system for a client, where orders would come in from a wide array of systems, some of which we did not control. Inventory counts would go up and down, and, again, the solution we built only handled some of those transactions, not all.

Our collective team discovered that inventory counts were out of sync. While in a perfect world, we’d root out all the reasons why and build new systems to handle every use case, that simply wasn’t an option for a multi-departmental, very large company. It will take our combined teams many months, if not years, to rework their systems in that manner.

Faced with an immediate concern, we created a routine that reconciled inventory counts with what our system predicted it should be at the end of each shift. We then created a routine that calculated the possible standard deviation of error based on the uncertainty in the overall collection of systems. If our analysis showed that inventory could potentially be off by a count of one or two items, we’d accept that as a manageable possible variance. If, on the other hand, that delta was greater than 25% of overall inventory, we’d immediately get a Slack alert. Our team would investigate and, if unable to resolve, inform our client accordingly.

We immediately shifted the tone of our relationship with our clients. Instead of strained, urgent messages in email, our system helped them stay ahead of problems and trouble-shoot individual cases in their workflows. We saved their team countless hours, stress, and real costs. Their customers were happier because they faced fewer delays from lack of materials.

Further, we have a means to measure future impact: as we work on their overall ordering systems, we reference these error statistics and measure as cases go down in volume. Rather than wait for one big future day where their systems are perfect, we can tackle one issue at a time and measure incremental value and improvement.

Watch the Road, Honk when Necessary

We create all kinds of notifications of user activity in our systems. We will warn you, over time this practice can create a lot of noise in an already heavy-duty environment like Slack. The key is creating meaningful messages at the right time and making sure their urgency is rightly communicated.

Integrate this practice wisely in your solutions and keep your clients happy they partnered with you.