Improve Clarity and Automation with Variables | All Quiet Payload Mapping Guide

Hi there, I'm Peer from All Quiet. Sometimes the information that your monitoring tools provide is fragmented. This means you will have to combine information from several objects to give your teams context or to route incidents based on certain criteria. For this reason, we are providing "Variables" at All Quiet. Variables allow you to take information from several attributes and put them into one new field. Now, in order to demonstrate some of our variables' functionality, let's look at this example. The latest payload we received from our monitoring tool includes the "service_name" and an "error_code" in the JSON body. If we only map the "service_name" to the incident's "Title", the notification our engineers receive will simply be "Payment-Gateway", which is far too vague. We rather want something specific that combines "Payment-Gateway" with the type of error that was found. So in order to do this, we need the variables. But first, we need to map the JSON body objects against All Quiet attributes because for all attributes, All Quiet automatically creates a variable we can use in the mapping. For demonstration purposes, we've already added "Service Name" and "Error Code" to the incident mapping. Now, in the mapping pane, the order of your attributes matters. All Quiet processes these from top to bottom. For the "Title", to use variables from "Service Name" and "Error Code", you must place the "Title" below those two fields. You can easily drag and drop them to fix the order if necessary. Now to add the variables, we need to change the mapping for the "Title". From "JSONPath", we switch to "Static". And now we type in our variables by using double curly brackets. These variables, if they should refer to the current incident, will always start with "currentIncident" with a large "I" - this is important - "dot" and then the name of the attribute in your All Quiet incident. So for example here it's "Service Name". This part is not case sensitive. This is also important to mention: before and after the variable expression, there should be a space. Now we have the service name. What we want to add is "Error Code:" as text and then we want, of course, to extract the "Error Code" which follows the same logic. So it's "currentIncident" but not "Service Name", it's "Error Code", the name we've given our attribute. Save. And as you can see we extract the new title "Payment-Gateway Error Code: 504" which we can use for any future incidents. Now that we've showcased how you can extract information from different objects in the payload and merge them into one incident attribute using our variables, we will also show you how you can use variables to define your incident workflow logic. Imagine that you need to route alerts to different teams based on the region and the environment of the alert. Your tool sends these as two separate fields: the Region and the Environment. Now, just like for the "Title", you can map the information from both fields to a new custom attribute that we called "Routing Key". That extracts information from the region and from the environment. Again, make sure this custom attribute sits below both - region and environment - so you can use the variables. So if the payload says "EU" and "Production", this variable becomes "EU - Production", as you can also see in the incident preview below. You can now create a routing rule in All Quiet that looks specifically for "EU - Production" to ensure the right team gets the call. Now before we create the routing rule, make sure that we know which integration belongs to which team because routing rules always have to be created in the team where the incident is created. Now the webhook integration that we've created here is part of the "Root Team" as we can see in the "Edit" tab. Knowing this, we can now navigate to the Advanced Routings tab and click "+ Create". Add a new Advanced Routing called, for example, "Routing to Teams" and as the root team select the "Root Team" as I just explained. Now it's time to add the rule. As a "Condition" we want to make sure that we only look into incidents from the specific integration we just looked at - the "Webhook". Additionally, we want to add attribute conditions, and now we can use the value that we just saw from our variable mapping - the "Routing Key" - to route incidents based on certain values. So for example, if the attribute called "Routing Key", which we can select here, equals the value "EU - Production", we want to make sure that as an action the incident is assigned from the "Root Team" to the "Europe Production" team. Click save. Now to test our rule, we can go back to our inbound integration and the mapping tab and resend the payload that we used to set up our payload mapping. We look into the incident. We can see that the routing rule was successful and that the incident that was created in the "Root Team" was assigned to our "Europe Production" team based on the "Routing Key". Of course, if the "Routing Key" changes, you can add more routing rules to make sure that the incident is moved to the correct team based on the "Routing Key". All in all, our variables are a great way to turn scattered data not only into better communication, but also into automation. Thank you so much for watching. Make sure to check out the other videos on our YouTube channel and read our documentation under docs.allquiet.app. See you next time.