Logic App Best practices, Tips and Tricks: #1 Logic App Naming Convention

Posted: February 25, 2022  |  Categories: Azure Logic Apps

For the last year and a half, I have frequently talked about Logic App (LA) Best practices, Tips, and Tricks on several community online events. You can see some of them here:

And now that I have already prepared a new set of Best practices, Tips, and Tricks, I thought it would be nice to publish the first set of them individually, adding more details.

In addition, one of the best practices is to make sure your Azure Logic Apps monitoring is in place.

Unlike some of my colleagues who initially addressed more technical topics about Logic Apps in their list of best practices, I think everyone who starts working, or is already working, on Logic App should respect the most essential best practice: naming convention. So, my first Best practices, Tips, and Tricks couldn’t be any other subject than this topic.

#1 Logic App Naming Convention

Later on, in other Best practices, Tips, and Tricks, I’m going to address different types of naming conventions, but to start, I like to address the name you give to your business flows and the importance of having a proper naming convention.

Basic rules about Logic App names:

  • Logic Apps (Consumption) allows you to set a Logic App name until a maximum of 43 characters!
  • And for that, you can use: Alphanumeric, underscore, and hyphen.
  • They are also Case insensitive.

So you can actually set a proper name to define your Logic Apps. And the main reasons you should provide a descriptive and good name to your Logic Apps are:

  • It improves readability.
    • By setting a proper name, you can quickly identify what those business workflows are intended to use for, without the need to enter the design and try to figure it out. So, you provide readability and save future time (not spending time looking for your LA) and frustrations. You may think that this is not important, you have created the LA, you know what is intended to but trust me after 3 months, you will completely forget it!
  • It also transfers knowledge between your team or organization.
    • Sometimes Logic Apps are shared by different teams, different developers o departments, or you are a consultant that is creating LA for your clients. They also need to be aware of them. They also need to understand them. You may leave the project or the company in the future, and they will need to continue the work or make future changes. Having a proper naming convention and providing a good descriptive name is auto-documenting your processes.

I bet if you work on a software house and create a C# project like this:

using System;

namespace mynamespace
{
    public class Class
    {
        void function1(ref string parm1)
        {
            /*
             * Implement the logic
             */
        }
    }
}

you will be fired immediately, so why do the same on Logic Apps?

In the picture below on the left side, you see some examples I have on my previous personal Azure environment:

If I need to do a critical analysis or a good practice assessment of my environment, I probably get to the conclusion that:

  • Almost all my Logic Apps need to be reviewed immediately (luckily for me, all of them are demos, samples, and so on).
  • Only one is actually ok or decent – I know that this is a LA is a POC on how to send emails with the body as an HTML.
    • Nevertheless, I’m not saying that it could be improved to have an even better name.

And as you see, I also have:

  • Some separeted with – and others without it.
  • They all use the Pascal case – programming naming convention that uses a single uppercase letter for each additional word, making it easier to read code and discern the purpose of variable.
    • But in some cases, we see a mix with Pascal’s case, Camel’s case, everything in UPPERCASE, or everything in lowercase.
  • In some cases, a mix of different languages. In my case, Portuguese and English (not seen in the picture above).

Also in the picture, on the right, I’m providing a simple sample of a naming convention structure. Make note that I’m not saying that this is the best naming convention and you should follow! If there is one thing that I learn in all these years as a consultant is that each client has its own naming convention and we need to adapt to them, of course, you can and should always suggest improvements and changes if it makes sense.

The important is to define a good naming convention for the names of your Logic Apps and implement them across all of them. Personally, I normally recommend one of these two naming structures, being the first one, the one I normally use:

  • LA-{BU}-{Dept or Application}-{ProcessName}-{Environment}
  • {Dept or Application}-{BU}-LA-{ProcessName}-{Environment}

Where:

  • LA is the static abbreviation for Logic App (Consumption)
  • BU is the Business Unit
  • Dept or Application can be the company or/and project abbreviation
  • ProcessName is the Logic App Business workflow name/description in Pascal Case
  • Environment is the Environment abbreviation: TEST, DEV, PROD, STG.

Of course, all of them are optional. Here are some examples:

  • LA-EAI-IT-CRMPush-DEV
  • LA-SP-TriggerUsingGETHTTPMethod-POC
  • LA-{BU}-Alarming-FailedJobs-PRD

Unfortunately and contrary to what happens with Power Automate in which, it is easy for us to fix the names of all of them safely because it will not break anything. And there isn’t any easy way to do it – instead, we have to create or re-create a new one.

Of course, we can do it using Visual Studio, DevOps, etc. But that will break in some cases some components like the HTTP Request triggers since we are actually creating a new Logic App, not modifying the existing ones.

And we can also do it using the Azure Portal and for that, you need to:

  • Access the Azure Portal (https://portal.azure.com/)
  • Go to the existing Logic App and then click Clone.
  • Provide a new Name, decide if you want to use an existing Resource Group or create a new one. Decide what the initial Logic App Status of the new Logic App (Encbled or Disabled) and click Create.

Stay tuned for the next Logic Apps Best practices, Tips and Tricks.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

4 thoughts on “Logic App Best practices, Tips and Tricks: #1 Logic App Naming Convention”

  1. Hi Sandro, thank you for all the good information and content you share on the website. 🙂

    Why would you add the environment name (Test, Dev, Pro) to the Logic App Name? If I move may application from Dev to Test, I will have to rename the Logic App by adding the Test.

    1. Hi Lee,

      Adding the environment name (Test, Dev, Pro) to the Logic App Name is optional. However, I like to add it because if I go to the list of LA on the Azure Portal, I can easily distinguish them.

      I don’t move LA from Dev to Test or other environments. Neither you should. Once I develop my LA, I will use DevOps to deploy them to different environments. This is, for me, the only correct way to “move” LA into different environments, and by using DevOps, I can easily configure the variables to rename the environment prefix.

  2. Nice start.
    However the naming convention should be also aligned to the Azure Naming convention you have as a company specially if it will create an actual Azure resource.

    As an example, this is our naming Azure convention

    {application name}-{asset type code}-{number | identifier | descriptive name in Camel case}-{azure region code}-{environment code}

    Reference: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations

    Logic Example:
    – oh-logic-commonSendEmailNotification-we-dev

    Key Vault example:
    – oh-kv-we-dev

    1. There isn’t a unique and proper naming convention, it has always to be aligned with the naming convention of the company.

      But the important is to have a naming convention and follow that naming convention

Leave a Reply

Your email address will not be published.

BizTalk360
BizTalk Server

Over 650+ customers across
30+ countries depend on BizTalk360

Learn More
Serverless360
Azure

Operate efficiently with enterprise-grade Azure monitoring,
tracing, remediation & governance in one platform

Learn More

Back to Top