Making sure your Logic App deployments are traceable for audit purposes

Recently we have been working with our audit team and we have had a lot of success demonstrating the process we use for managing the ALM side of the interfaces we have built with Logic Apps. In this article I wanted to talk a little about what we do to share with other teams and also generate conversation around good practices.

This is a bigger topic really and ill probably talk more in future posts about things outside of a specific deployment but today ill focus more on the actual deployment of a Logic App.

First off we use tags in the ARM template for consumption Logic Apps. You can see below a snippet from the template showing some of the common tags we use.

 "resources": [
    {
      "name": "LA-Name",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('arm_logicAppLocation')]",
      "tags": {
        "displayName": "LA-Name",
        "logicalResource": "LA-Name",
        "description": "what does this resource do",
        "devOps:BuildNumber": "__BUILD_BUILDNUMBER__",
        "devOps:BuildDefinition": "__BUILD_DEFINITIONNAME__",
        "devOps:Repo": "__BUILD_REPOSITORY_NAME__",
        "devops:ReleaseDefinition": "__RELEASE_DEFINITIONNAME__",
        "devops:ReleaseName": "__RELEASE_RELEASENAME__",
        "Project Name": "[The name of the project that delivered the interface]",
        "Environment": "[parameters('arm_environmentname')]",
        "costCentre": "[Who pays for this]",
        "dataProfile": "Internal",
        "documentationLink": "[url goes here]",
        "managedBy": "[email protected]",
        "ownedBy": "[Team who own interface]",
        "scope": "[parameters('arm_scope')]",
        "interfaceCatalog:WorkItemID": "43585"
      },

A list of the key tags we care about for deployment audit are:


Tag	Use
logicalResource	This represents a name for the resource which is not environment specific. Sometimes you need to include the environment name in a resource which means you cant easily see which is the same 2 versions of a resource in 2 different environments. For Logic Apps this isnt so much of an issue except we have had some challenges with this when setting up a managed identity in the past where the name needed to be unique but this tag helps us relate resources across environment
description	This tag is used to give a short text overview of what the logic app does
documentationLink	This would be a link to a page in our Azure DevOps wiki or an md file in a repo which would be an overview of what the logic app does and how it works.
devOps:BuildNumber	This contains the build number from the pipeline that created the deployment artefact
devOps:BuildDefinition	This contains the name of the build pipeline that the artefact being deployed came from
devOps:Repo	This contains the name of the repo where the code is for this logic app
devops:ReleaseDefinition	This contains the name of the release pipeline
devops:ReleaseName	This contains the release name which is the run of the release pipeline. EG Release-24
interfaceCatalog:WorkItemID	This is populated with the id which matches a work item in Azure DevOps which is a unique id for the interface in our interface catalog. Note – Ill talk about this in a future blog post but this gives us tracability from the logic app back to a central interface catalog and then tracability to requirements which change the interface over its lifecycle.
managedBy	This is the name of the team who managed the support of this resource
dataProfile	This is the profile of data classification for data going through this logic app
costCentre	This is the cost centre for the bill payer for this resource
ownedBy	This is the business owner for the interface that this Logic App implements

Some of the values for the tags can be hard coded and others are injected at deployment time. You might notice above on some of the tags in the code snippet we have the __[variable]__ format which we can inject items in using the Replace Tokens task in a devops pipeline as shown below.

The next thing we do for the Logic App deployment via the ARM task is to set the deployment name to this variable

$(RELEASE.DEFINITIONNAME)-$(RELEASE.RELEASENAME)

Doing this means that when we do a deployment then the Azure Deployments list will show the ARM deployment and it will use the name of the release pipeline and its run name in the deployment list. This means that we can easily trace a deployment to a pipeline run. You can see the updated release names in the Azure Deployments below.

Within a consumption Logic App I also have the versions feature which shows me each time a Logic App has changed and I can see the version history.

Having an auditable process is about being able to demonstrate traceability within your process. From a Logic App a diagram representing how our tracability from a deployment through to devops pipelines etc would look something like below.