Introduction to Advanced Incident Routing Rules in All Quiet

Hi everyone and thanks for joining. My name is Peer and today I'd like to introduce you to our advanced incident routing. To me personally, this is one of the most exciting and powerful features we have at All Quiet because it allows you to automate and customize your incident response in so many different ways. But before we jump in and create our first routing rule, let's have a look at how All Quiet already handles incident flows without adding the extra layer of a routing rule on top. Now, in All Quiet incidents are created via inbound integrations. This can be emails or calls from your customers, messages from your customer support teams in Slack, or alerts from your monitoring stack. These alerts are then evaluated in our payload mapping engine. The payload mapping engine allows you to classify an incident by setting a title, a severity, and different other attributes based on the payload you receive. If you haven't set up payload mapping yet, make sure to check out the other series on this vlog because for routing, we assume everything is already in place. After an incident is created, it is sent to the team that is connected to your inbound integration. Within this team, you can set up your on-call escalations and ensure that your on-call users are notified until an incident is resolved or acknowledged. In parallel to these escalations, your outbound integrations will receive the incidents based on your specific integration settings. For some integrations, you might want to set up that each and every incident update is sent to your outbound integrations, such as your select channels. For others, you might only want to forward incidents on manual actions from your team. Now, when do we need routing rules? It is if we want to change something from the standard flow or if we want to make additions. Let's look at some examples. One really, really good way of setting up routing routes is if you want to automize certain workflows. For example, you might want to auto-forward an incident in a certain condition. This is something we will look into in more detail later. Also, you might want to assign an incident from one integration to different teams based on certain attributes. Or you might want to reduce noise and only send incidents to a certain outbound integration if they are, for example, of critical severity. Now, before we look into the All Quiet UI and set up a real world incident routing rule example, let's check how a rule is actually set up and how it works. Now, each incident rule in All Quiet has three parts. The first part is the "conditions". The conditions defend when the rule is triggered. It is a combination of different filters you can set and all these filters must match. So it's an "and" condition. An example for filters that you can set is incident severity. For example, you might want to apply this rule only to critical incidents, but you can also decide to select certain incident intents and actions or only apply the rule to certain integrations. Remember that if you don't set a field, it basically it means "match all". So if you don't set the severity in your conditions, it means apply it to all incident severities. Now the second one is "actions". That is the actual automation that is happening. What you want to do with that routing rule. For example, you might want to forward an incident to a certain outbound integration or you might want to change the severity based on specific conditions. Actions decide what to do. Last but not least, you can set specific "channels" for routing rule. Channels decide whom to notify. Basically, they override your standard setups and allow you to mute notification channels under certain conditions or mute certain outbound integrations under certain conditions. Now each of the rules we just looked at is part of a larger routing in All Quiet and one routing can have several rules included which are then executed top to bottom means there is a certain order you can define in your routing of the rules. Rule 1 is executed before rule 2 before rule 3 and so on. Now, if you don't like the current order and want to change it, you can simply drag and drop the rules to change the order in the UI or if you set up everything via code, you can of course change the code of your Terraform provider to reorder the rules. What is also important to remember is that each rule is only triggered once per incident. So for example, if we had a condition saying I want to trigger rule 1 for the escalated intent and we already had rule 1 being triggered once in this incident. If there is a second time an escalated intent, rule one does not run twice but only once because it already got executed. Now this is the mental model. Let's jump into the UI and see how it actually works on All Quiet. In the All Quiet web app, open the advanced routings tab. Here you will find a list of all your routings showing their name, their rules, and of course the connected teams. To create a new routing, click "+ create". Give your routing a nice display name like "new routing" in this case. and also select your routing's root team. Now the root team is the team that the routing is attached to and only incidents of the root team will be evaluated against the routing. You can later - if you're on pro or enterprise - add additional teams to that routing. Click create advanced routing to finish off. Now at the top of the tab you will see edit rules, team connections and history. The edit tab is just for basic information where you can, for example, change the display name of the the routing or delete it. The rules tab is where you will build your automations and add the rules that we just had a look at. The team connections tab is only visible for pro users and enterprise users and it lets you share one routing across multiple teams in your organization. Last but not least, there's the history tab that shows every time a rule matched and this is great for debugging and we will have a little peek at it after the demo. Now it's time for our first rule. We want to make sure that when someone resolves an incident, it is automatically logged in Google Sheets. So, we want to build an automation that doesn't need any manual export, no copy paste of at the end of an outage. I've already set up a Google Sheets integration that triggers only on forwarding, meaning somebody needs to trigger the forward bottom manually to send an incident to Google Sheets. We want to automate this step. So getting back to the rules tab in our routing, let's click add rule. As you can see, the modal view features the three parts of a rule that we discussed earlier on. The "conditions", the "actions", and the "channels". You can select from a vast range of different conditions to trigger a routing rule for an incident like the incident status, incident severity, different inbound integrations or also attribute conditions of an incident and specific time restrictions. In this case, we keep it simple. We just want to make sure that once an incident is resolved, this should trigger the export to Google Sheets. So if the incident intent is "resolved", this is the sufficient condition for us today. Now the second step we need to define the action. So what we need is we need to automate is the "forwarding" intent, the forward action right. So what we do here is we click on "add interaction", select "forwarded" and then we will receive an extra field saying "forward to" and this is the integration that we described earlier on - the Google Sheets integration - which we have to select in this step. The result is that every resolved incident now gets a new Google sheet entry, Google sheets page. The channels are skipped for now because we focus only on automation and not on noise reduction. Click save to add your rule to the routing. And after saving it, you can also give it a name. For this, it makes sense to call it, let's say, auto forward to Google Sheets on resolve or on resolution. save. So you can see if you add further rules, you can then start to drag and drop to reorder them and decide which order they should be run. Now let's move on with an example to see how this rule plays out in an extra scenario. Now for the purpose of this video I've earlier on created an incident that - and that is important - matches the team of the routing. Now let's resolve it. As you can see, the routing rule is evaluated immediately as the incident is resolved. The condition matches and the forward action to Google sheet runs. And as you can also see, the Google sheet is already attached to the incident and I can open it and see the incident with all its events and timeline being exported automatically to my new Google sheet. If you want the proof in the product, you can open the routings history tab or you can also open the routing rule executions for this specific incident. You should see the rule with outcome executed and the effect showing it forwarded to your Google Sheets integration. That is advanced routing in one sentence: "Define when something happens to an incident, then automate what happens next." In this video, we already covered what All Quiet does without routing rules and the mental model plus the UI of routing combined with one real automation. In the following videos of this series, we will dig a bit deeper and show more advanced routings. Make sure to subscribe to our YouTube channel to not miss out on them. And also make sure to check out https://allquiet.app for more info on our product. Thank you so much for watching.