[00:00] Let's take a look at the different pipeline blocks and our alarm notification pipelines. The first block is the start block. When an alarm event enters an alarm notification pipeline, the start block is where it will start it's journey. Note that it's not listed up here in our list of pipeline blocks. This is because the start block cannot be added, nor can it be deleted. There always has to be one start block and only one start block. The next block is our notification block. This block will send out a notification to the correct users when the alarm event gets to it. Notice in the block editor in the "Notification" tab, I can select a notification profile. I have an email profile listed here. We can then specify some various properties such as a from address, a subject, and even a custom message. It is possible to use HTML formatting in the message property, to further customize your messages. You simply need to use the HTML tag where appropriate. You can then specify who this notification block is going to contact by going to the "Contacts" tab and selecting a roster type. For example, I can select a direct roster type and then select one of my On-Call Rosters such as "Administrators." We'll go more in depth how all of these roster types work, in a later video. The next type of pipeline block is the delay block. The delay block allows you to add in a delay to your pipeline. This is typically used in between two notification blocks, to wait some amount of time before contacting the next set of users. Here on the block editor, I can specify how long I want the delay to be. Next on our list of blocks, is the splitter block. This allows you to split your alarm event into multiple different instances. Notice, while it only has one input, it has multiple outputs. You can then send each of those outputs to two different notification profile, allowing you to notify two sets of users, or notify users using two methods of notification. In the block editor, I can specify how many outputs I would like. Next is the switch block. The switch block is similar to the splitter block, in that it can have multiple outputs. However the difference is, instead of going out through all of the outputs, it will only select one output to go out of, based on the expression listed here on the block editor. Here in the expression, I can list something like priority, and then for my values, I can specify one of them to be the value of one, and one of them to be the value of two. If my alarm event were to have a value of one, it would go out the one output. Likewise the value of two, it would go out the two output. The catch-all output is a unique output, in that if the expression of a returns a value that's not listed in my list of values, it will instead go out the catch-all output. This insures that there's always an out for the alarm to go through. Next we have the expression block. The expression block allows you to specify an expression that should return either true or false. The return will then determine what output it goes through, either the true, or the false output. This is typically used in a logic loop, where it will go through a notification block a certain number of times, before it goes through the other output of the expression block. Next we have the set property block. The set property block allows us to create, and modify already created properties in our pipeline. Here in the block editor, we can specify a name for our property, and then an expression to create a value for that property, in addition, we can also choose a scope, either local or global. Local would keep it local to this instance of the pipeline, whereas global will make it accessible by any other pipeline that this alarm event may jump to. On that note, the next type of block is the jump block. Notice that this block does not have an output. This is because the jump block is used to push an alarm event to a new alarm notification pipeline. Here in the block editor, I can select which pipeline I want it to go to, such as my Escalation Pipeline. When the alarm event reaches this block, it'll then jump to the start block of my Escalation Pipeline. This is really useful when you have a large, and complex notification system. Instead of using one massive pipeline, with very complex logic, you can break it down into much simpler, smaller pipelines, and have it jump to the appropriate place when needed. Finally, the last type of block is the script block. The script block allows you to script whatever you would like, here within the pipeline. Typically it's used to run through some logic, and then if necessary, call event.cancelNotification, which will stop the alarm event from going any further through the pipeline. Using all of these blocks in tandem, can help you create the pipeline to fit your needs.