Tag Archives: Workflow

Setting up an e-mail Notification System using Logic Apps

One of the new features of the Microsoft’s Azure offering are Logic Apps: these are basically a workflow system, not totally dis-similar to Windows Workflow (WF so as not to get sued by panda bears). I’ve worked with a number of workflow systems in the past, from standard offerings to completely bespoke versions. The problem always seems to be that, once people start using them, they become the first thing you reach for to solve every problem. Not to say that you can’t solve every problem using a workflow (obviously, it depends which workflow and what you’re doing), but they are not always the best solution. In fact, they tend to be at their best when they are small and simple.

With that in mind, I thought I’d start with a very straightforward e-mail alert system. In fact, all this is going to do is to read an service bus queue and send an e-mail. I discussed a similar idea here, but that was using a custom written function.

Create a Logic App

The first step is to create a new Logic App project:

There are three options here: create a blank logic app, choose from a template (for example, process a service bus message), or define your own with a given trigger. We’ll start from a blank app:


Obviously, for a workflow to make sense, it has to start on an event or a schedule. In our case, we are going to run from a service bus entry, so let’s pick that from the menu that appears:

In this case, we’ll choose Peek-Lock, so that we don’t lose our message if something fails. I can now provide the connection details, or simply pick the service bus from a list that it already knows about:

It’s not immediately obvious, but you have to provide a connection name here:

If you choose Peek-Lock, you’ll be presented with an explanation of what that means, and then a screen such as the following:

In addition to picking the queue name, you can also choose the queue type (as well as listening to the queue itself, you can run your workflow from the dead-letter queue – which is very useful in its own right, and may even be a better use case for this type of workflow). Finally, you can choose how frequently to poll the queue.

If you now pick “New step”, you should be faced with an option:

In our case, let’s provide a condition (so that only queue messages with “e-mail” in the message result in an e-mail):

Before progressing to the next stage – let’s have a look at the output of this (you can do this by running the workflow and viewing the “raw output”):

Clearly the content data here is not what was entered. A quick search revealed that the data is Base64 encoded, so we have to make a small tweak in advanced mode:

Okay – finally, we can add the step that actually sends the e-mail. In this instance, I simply picked Outlook.com, and allowed Azure access to my account:

The last step is to complete the message. Because we only took a “peek-lock”, we now need to manually complete the message. In the designer, we just need to add an action:

Then tell it that we want to use the service bus again. As you can see – that’s one of the options in the list:

Finally, it wants the name of the queue, and asks for the lock token – which it helpfully offers from dynamic content:


To test this, we can add a message to our test queue using the Service Bus Explorer:

I won’t bother with a screenshot of the e-mail, but I will show this:

Which provides a detailed overview of exactly what has happened in the run.


Having a workflow system built into Azure seems like a two edged sword. On the one hand, you could potentially use it to easily augment functionality and quickly plug holes; however, on the other hand, you might find very complex workflows popping up all over the system, creating an indecipherable architecture.

Lock a TFS branch through builds

One of the things that is necessary if you subscribe to the feature branching method of source control in TFS is that, once a release is cut, it needs to be locked. There are other reasons that you might want to lock a branch, but this was my specific use case when I came up with this.

There are a dozen ways to do this; you can simply delete the branch, you can remove check-in permissions; however, you could also create a custom build, which prevents check-ins. This isn’t perfect, but it does give you a lot more flexibility that some of the other options.


Create a new build definition:


Then remove all the standard components. As a base level, it probably looks something like this:


Now, set the build as a gated check-in for your branch, and the next time you try and check something into that branch, you’ll end up with a build failure:



The advantage of this method is mainly flexibility. When someone attempts to check into this branch, you execute a custom workflow; so you can send an e-mail, give a custom message, connect to an IoT device that administers a small electric shock, etc. You don’t have to blanket reject check-ins, you can call call the TFS API, interact with services; you could even implement some kind of rudimentary approval system for it.


There are a couple of issues with doing this: firstly, if someone tries to check into two gated branches at the same time, they are given the option of a build – as far as I’m aware, there’s no way around this (obviously this means that this solution is not water-tight). Although, again, one of the advantages of the flexibility, is that you could probably check for this in the build.