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

In my last blog post, I talked about the most essential best practices you should have while working with Logic App: Logic App naming convention. Today I will continue to talk about naming convention because I think this is so important and critical to implement since day one, and people tend to forget.

#2 Actions Naming Convention

So, why is it essential to implement a good naming convention in our actions?

Almost for the same reasons we describe in the previous Best practices, Tips, and Tricks:

  • It improves readability.
    • By setting a proper name in your actions, you can quickly identify what action is intended for and what is doing, without the need to enter inside of each action to try to figure it out. So, you not only provide readability but you also save future time (not spending time looking to the details and configurations inside your actions) and frustrations. You may think that this is not important. You have created the flow, and you know the logic inside and what shapes represent or are used for, but, once again, trust me, after 3 months or a week, 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.

Basic rules about Action names:

  • Logic App allows you to set a flow name between a minimum of 1 and a maximum of 80 characters!
  • Contrary to what happens in Power Automates were you can now use all types of characters. In Logic app the name of the actions (or triggers) cannot contain any control characters or any of the following symbols: ‘
    • <
    • >
    • %
    • &
    • \
    • ?
    • /

Basic rules about Trigger names:

  • Unfortunately, not all triggers allow you to modify the name, this is a big limitation in my opinion and this behavior should be modified in the future but for now, we need to deal with it.

Once again, 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 I present to you a sample that unfortunately, we see sometimes on several Azure environments:

If we need to do a critical analysis or a good practice assessment of these types of business workflow. We will probably get to the conclusion that:

  • All the shapes have the default name and based on this picture no one can understand what the LA is doing without going inside each shape to investigate.
  • Unfortunately, as I told you previously most of the triggers (first shape) don’t allow you to modify the name, When a HTTP request is received is one of them.
  • The branch If true and If false is also one of those cases that don´t allow you to rename the branch “title”, once again, in my opinion, and this behavior should be modified in the future.

By setting descriptive names, like the picture below, you will see that it would be quite easier to identify what action is doing. Of course, in some cases, you need to go inside to get more details about it.

Once again, you can always go into your existing Logic Apps and fix all the bad best practices implementations and change the names of your actions even the ones that have dependencies directly without any impact. You just need to be aware of one important trick:

  • Never rename action without fixing all the connectors broken inside your LA. If for example, you rename an action that is being used inside an upcoming action with a broken connector as you see in the picture below. The LA designer will not complain and allow you to modify the action, in this sample, if we change the name of “Parse JSON” to “Parse JSON A”. Once you fix the connection on the “Add row to a dataset” action that was been used on what was the previously broken connector it will still have a reference to the previous name: “Parse JSON”.
  • If you first fix the broken connection and then rename the action, everything will work fine.

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.

Leave a Reply

Your email address will not be published.

BizTalk360
BizTalk Server

Over 500+ customers across
30+ countries depend on BizTalk360

Learn More
Serverless360
Azure

Manage and monitor serverless
components effortlessly

Learn More
cerebrata
Azur Developers

Cross platform desktop tool
for managing your Azure Resources

Learn More

Back to Top