Azure Landing Zone Vending — Part 2

Published in

SpareBank 1 Utvikling

8 min readDec 11, 2023

Introduction

In part 2 of this 3-part series, we will provide a comprehensive guide on how we harnessed the power of the Power Platform to automate the creation of Azure Landing Zones. Our primary goal is to streamline and automate the whole process and eliminate the need for manual configuration.

As mentioned in part 1, Microsoft have done a very good job in documenting all that needs to be considered when setting up a vending machine. This is now included in the Cloud Adoption Framework. In this blog post we will focus primarily on the following areas highlighted here:

Business Logic

The MVP solution we first implemented was a Form which then populated a SPO List. We knew we wanted a better solution eventually but had to prioritize this work earlier than expected because there were so many issues with a simple order form. One of the biggest issues was that we had no input validation, which meant that some other flows failed (email notification and budgets containing decimal points for example!). We also experienced that Forms in a multi-tenant environment had a number of limitations as well, specifically around security. We decided then to go all in and pursue the subscription vending concept.

We knew then that we needed input validation and support for users from multiple tenants. As well as this, because of the distributed support model we currently have in the alliance, there is currently no shared ITSM tool we could use as a portal. For these reasons we soon came to the conclusion that a dedicated Power App was the way to go, together with Power Automate for supporting functions.

Approval process

We have thought about this but considering the complex structure we have, including the differing banks and their own processes, we decided that we would not include much in the way of an approval process. There are two ways in which this can be limited though. There is a Entra ID group per bank (the bank decides who can have access) that gives the necessary permissions to use the Power App and order a landing zone, and we have a basic check that hinders sending in a request that we deem to be unreasonable (public landing zone containing customer data without a completed risk analysis for example). Obviously, it is easy to get around this, but it is designed to increase awareness for what is being requested and the potential implications of that.

Make a Subscription Request

Sounds easy, right… just a portal for ordering Landing Zones… well, not so much actually, there is lots to consider!

The vending concept is more than just an order form, because we need to harvest information that can then be directly used as a source for provisioning a Landing Zone.

In a nutshell, what we do with this information is convert it to a JSON file that can then be picked up by the pipelines that provision the landing zone. This means that we must ensure that the data we harvest is correct, both in value, but also in form.

Building the Power App

Our solution encompasses various components, fully native Microsoft technology, ensuring a cohesive integration. The front-end of our application will be developed using Microsoft Power Apps, a low-code tool that combines a user-friendly interface with robust logic and workflow capabilities. Power Automate, another low-code tool, will handle the back-end logic of our application. The synergy between Power Apps and Power Automate is the cornerstone of our approach.

Our application structure may differ from yours, as our guide might include configurations specific to our needs. Notably, our multi-tenant solution for Azure influences certain aspects of our implementation. However, these configurations may not be necessary for your application. We have made trade-offs to maintain our multi-tenant solution, such as sacrificing standardized emails from drop-downs and MS Teams integration.

Step 1: Data Harvesting

The data we decided to gather from users include organizational, technical, financial and compliance information. During runtime, the Power App will run two Power Automate flows. First, a flow “getCompanies” will run to get information on what Bank or Company the active user has access to. This data is used to display the available choices in a drop-down view. A second flow “getInvoiceSections” will run to display the invoice sections available for the user.

Validation

Validation is integral to ensuring the reliability of user input. We have explored various validation methods, including standardized choices, regex validation for email addresses, and other error-handling techniques. This is to make sure that when a user submits the form, we can run the provisioning pipeline automatically without human intervention.

After filling out the form, users will navigate to the review screen, where they can submit their order. Successful submission takes users to a confirmation screen, and the form is reset to prepare for the next order.

Step 2: On form submission

Submitting a form triggers updates in the associated SharePoint list, setting in motion the “main” Power Automate flow. This flow orchestrates various tasks, from API calls to updating files in Azure DevOps and running pipelines. We will dive deeper into the Power Automate flows in this next section.

onFormSubmit

The “onFormSubmit” flow is the central flow in this automation process, serving as the main orchestrator. Its primary responsibility is to collect information from a SharePoint list, create and manage variables, and trigger other Power Automate flows by passing these variables as arguments. Additionally, this flow plays a crucial role in constructing the JSON object for each Landing Zone, relying on output data from other connected flows. The key variables generated within this flow include the Landing Zone name, Landing Zone JSON object, and Repository ID.

getBillingInfo

The “getBillingInfo” flow plays a vital role in acquiring essential information regarding billing profiles and invoice sections, which are essential for successful Landing Zone provisioning. This flow accepts two input arguments: Company Name and Invoice Section Name, both of which are supplied through user input in the Power App. The output of this flow comprises the Invoice Section ID, Billing Profile ID, and Billing Profile Name. To retrieve this information, the flow interfaces with the Microsoft API and retrieves data on all invoice sections associated with a given Company name. You can refer to the Microsoft API documentation for further details: Microsoft API for Invoice Sections.

updateJSON

The “updateJSON” flow is responsible for the task of updating the JSON file for each Landing Zone within Azure DevOps. This flow requires three input arguments: the Landing Zone JSON object, Repository ID, and Landing Zone name. To achieve this, it utilizes a two-step process. First, a “GET” request is made to retrieve information about the target repository using the provided Repository ID. Then, a “POST” request is executed to append the new Landing Zone JSON object to the designated folder within the repository.

JSON object sent to Azure DevOps Repository

runPipelines

The “runPipelines” flow serves as the final stage in the process, responsible for initiating the execution of two critical pipelines essential for provisioning a Landing Zone. These pipelines need to know which Landing Zone they should set up. So, the only argument we need to pass is the name of the Landing Zone.

The operation starts with the initiation of a “POST” request to trigger the first pipeline. The target subscription for this pipeline is set as the Landing Zone name. Then, the flow is paused, and it awaits the completion of the pipeline run. To monitor and control this waiting period, a “do until” loop is implemented. Within this loop, the flow periodically makes “GET” requests to Azure DevOps to fetch information about the ongoing pipeline run. This continuous loop persists until the pipeline run has successfully completed.

Stages of Landing Zone Creation

Once the first pipeline run has finished, the flow proceeds to replicate this process for the second pipeline, ensuring the sequential execution of both pipelines. This ensures a step-by-step provisioning of the Landing Zone, with precise control over the progress and completion of each stage.

Throughout the entire Landing Zone creation process, both the requester and the platform team is notified with updates. As illustrated in the image below the requester, the Landing Zone owner and team azure are notified when the order is submitted through the Power App. When the Landing Zone is ready for use, the requester and owner will receive a final email.

Requirements

Licenses are necessary for Azure DevOps, Power Automate, PowerApps, SharePoint, and Azure Active Directory.

Keep in mind that not all users may have premium Power Platform access, which could impact the functionality available to them.

In Summary

By harnessing the strengths of Microsoft’s low-code tools, specifically Power Apps and Power Automate, we’ve seamlessly integrated front-end development with robust back-end logic. This guide offers a clear roadmap for automating Azure Landing Zone creation through the Power Platform.

While we provide implementation specifics tailored to our requirements, it’s crucial to recognize the potential necessity for customization in diverse application scenarios.