Power Automate: The Early Years
This post isn’t a “what is Power Automate” writeup – I have to assume you understand (or at least have heard about) Power Automate to some degree. That being said, if you feel like you could use a little more background or information about Power Automate, use the inline links I’m supplying and References and Resources section at the bottom of this post to investigate further.
Long story short, Power Automate is a member of Microsoft’s Power Platform collection of tools. The goal of the Power Platform is to make business solution capabilities that were previously available only to software developers available to the masses. These “citizen developers” can use Power Platform tools to build low-code or no-code business solutions and address needs without necessarily involving their organization’s formal IT group/department.
Power Automate, in particular, is of particular significance to those of us who consider ourselves SharePoint practitioners. Power Automate has been fashioned and endorsed by Microsoft as the replacement for SharePoint workflows – including those that may have been created previously in SharePoint Designer. This is an important fact to know, especially since SharePoint 2010 Workflows are no longer available for use in SharePoint Online (SPO), and SharePoint 2013 workflows are slated for the chopping block at some point in the not-so-distant future.
Given that Power Automate was first released in 2016, it has been very successful in a relatively short time – both as a workflow replacement and as a highly effective way to enable citizen developers (and others) to address their own business process needs without needing to involve format IT.
Power Automate (and the Power Platform in general) represents a tremendous amount of potential value for average users consuming Microsoft 365 services in some form or fashion. Power Automate’s reach and applications go well beyond SharePoint alone. Assuming you have a Microsoft 365 subscription, just look at your Power Automate home/launch page to get an idea of what you can do with it. Here’s a screenshot of my Power Automate home page.
Looking at the top-four Power Automate email templates, we can see that the tool goes beyond mere SharePoint workflows:
Checking out the Files and Documents prebuilt templates, we find:
The list of prebuilt templates go on for miles. There are literally thousands of them that can be used as-is or as a starting point for the process you are trying to build and/or automate.
And to further drive home the value proposition, Power Automate can connect to nearly any system with a web service. Microsoft also maintains a list of pre-built connectors that can be used to tie-in data from other (non-Microsoft) systems into Power Automate. Just a few examples of useful connectors:
Power Automate is typically thought of as being a cloud-only tool, but that’s really not true. The lesser-known reality is that Power Automate can be used with on-premises environments and data provided the right hybrid data gateway is setup between the on-premises environment and the cloud.
But Such a Rebellious Streak!
Like all children, Power Automate started out representing so much promise and goodness, and that really hasn’t changed at all. But as PowerAutomate has grown in adoption and gained widespread usage, we have been seeing signs of “teen rebellion” and the frustration that comes with it. Sure, Power Automate has demonstrated ample potential … but it has some valuable lessons to learn and needs to mature in several areas before it will be recognized and accepted as an adult.
Put another way: in terms of providing business process modeling and execution capabilities that are accessible to a wide audience, Power Automate is a resounding success. Where PowerAutomate needs help growing (or obtaining support) is with a number of ALM (application lifecycle management) concerns.
These concerns – things like source (code) management, documentation, governance, deployment support, and more – are the areas that formalized IT organizations typically consider “part of the job” and have processes/solutions to address. The average citizen developer, likely not having been a member of an IT organization, is oftentimes blissfully unaware of these concerns until something goes wrong.
Previous workflow and business process tools (like SharePoint Designer) struggled with these IT-centric non-functional requirements. This is one of the reasons SharePoint Designer was “lovingly” called SharePoint Destroyer by those of us who worked with and (more importantly) had to support what had been created with it. Microsoft was aware of this perceived deficit, and so Power Automate (and the rest of the Power Platform) was handled differently.
A Growth Plan
Microsoft is in a challenging position with Power Automate and the overall Power Platform. One of Power Automate’s most compelling aspirations is enabling the creation of low- and no-code solutions by average users (citizen developers). Prior to the Power Platform, these solutions typically had to be constructed by developers and other formalized IT groups. And since IT departments were typically juggling many of these requests and other demands like them, the involvement of IT oftentimes introduced unexpected delays, costs, bureaucracy, etc., into the solutioning process.
But by (potentially) taking formalized IT out of the solutioning loop, how do these non-functional requirements and project needs get addressed? In the past, many of these needs would only get addressed if someone had the foresight, motivation, and training to address them – if they were even recognized as requirements in the first place.
With the Power Platform, Microsoft has acknowledged the need to educate and assist citizen developers with non-functional requirements. It has released a number of tools, posts, and other materials to help organizations and their citizen developers who are trying to do the right thing. Here are a handful of resources I found particularly helpful:
- Microsoft Power Platform Guidance documentation
- Power Platform adoption maturity model: Goals and opportunities
- Admin and governance best practices
- Introduction: Planning a Power Automate project
- Application lifecycle management (ALM) with Microsoft Power Platform
- Create packages for the Package Deployer tool
- SolutionPackager tool
- Source control with solution files
Some Guidance Counseling
When I was in high school (many, many years ago), I was introduced to the concept of a guidance counselor. A guidance counselor is someone who can provide assistance and advice to high school students and their parents. Since high school students are oftentimes caught between two worlds (childhood and adulthood), a guidance counselor can help students figure out their next steps and act as supportive and objective sounding boards for the questions and decisions teenagers commonly face.
High school guidance counseling isn’t really accurate in the case of Power Automate, but the analogy makes more sense if we swap-out “high school” and insert “technical.” After all, citizen developers understand their business needs and the problems they’re trying to solve. Oftentimes, though, they could use some advice and assistance in the end-to-end solutioning process – especially with non-functional requirements. They need help to ensure that they don’t sabotage their own self-interests by building something that can’t be maintained, isn’t documented, can’t be deployed, or will run afoul of their IT partners and overarching IT policies/governance.
The aim of the links in the A Growth Plan section (above) is to provide some basis and a starting point for the non-functional concerns we’ve discussed a bit thus far. Generally speaking, Microsoft has done a solid job covering many technical and non-technical non-functional requirements surrounding Power Automate and solutions built from Power Automate.
I give my “solid job” thumbs-up on the basis of what I know and have focused on over the years. If I review the supplied links and the material that they share through the eyes of a citizen developer, though, I find myself getting confused quickly – especially as we get into the last few links and the content they contain. I suspect some citizen developers may have heard of Git, GitHub, Azure DevOps, Visual Studio Code, and the various other acronyms and products frequently mentioned in the linked resources. But is it realistic to expect citizen developers to understand how to use (or even recognize) a CLI takes or be well-versed in properly formed JSON? In my frank opinion: “no.”
The Microsoft docs and articles I’ve perused (and shared links above) have been built with a slant towards the IT crowd and their domain knowledge set, and that’s not particularly helpful for who I envision citizen developers to be. The documents and technical guides tend to assume a little too much knowledge to be helpful to those trying to build no-code and low-code business solutions.
Thankfully, citizen developers have additional allies and tools becoming available to them on an ever-increasing basis.
Pulling The Trigr
One of the most useful tools I’ve been introduced to more recently doesn’t come from Microsoft. It comes from Encodian, a Microsoft Partner building tools and solutions for the Microsoft 365 platform and various Azure workloads. The specific Encodian tool that is of interest to me (a self-described SharePoint practitioner) is called Trigr, and in Encodian’s words Trigr can “Make Power Automate Flows available across multiple and targeted SharePoint Online sites. Possible via a SharePoint Framework (SPFx) Extension, users can access Flows from within SharePoint Online libraries and lists.”
A common challenge with SharePoint-based Power Automate flows is that they are built in situ and attached to the list they are intended to operate against. This makes them hard to repurpose, and if you want to re-use a Power Automate flow on one or more other lists, there’s a fair bit of manual recreation/manipulation necessary to adjust steps, change flow parameter values, etc.
Trigr allows Power Automate flow creators to design a flow one time and then re-use that flow wherever they’d like. Trigr takes care of handling and passing parameters, attaching new instances of the Power Automate flow to additional lists, and handling a lot of the grunt work that takes the sparkle away from Power Automate.
Have a look at the following video for a more concrete demonstration.
As I see it, Trigr is part of a new breed of tools that tries (and successfully manages) to walk the fine line between citizen developers’ limited technical knowledge/capabilities and organizational IT’s needs/requirements that are geared towards keeping PowerAutomate-based solutions documented, controlled, repeatably deployable, operating reliably/consistently, and generally “under control.”
Trigr is a SaaS application/service that has its own web-based administrative console that provides you with installation resources, “how to” guidance, the mechanism for parameterizing your Power Automate flows, deployment support, and other service functionality. A one-time installation and setup within the target SPO tenant is necessary, but after that, subsequent Trigr functionality is in the hands of the citizen developer(s) tasked with responsibility for the business process(es) modeled in Power Automate. And Trigr’s documentation, guidance, and general product language reflect this (largely) non-technical or minimally technical orientation possessed by the majority of citizen developers.
I have faith that Power Automate is going to continue to grow, gain greater adoption, and mature. Microsoft has given us some solid guidance and tools to address non-functional requirements, and interested third-parties (like Encodian) are also meeting citizen developers where they currently operate – rather than trying to “drag them” someplace they might not want to be.
At the end of the day, though, one key piece of Power Automate (Power Platform) usage and the role citizen developers occupy is best summed-up by this quote from rabbi and author Joshua L. Liebman:
Maturity is achieved when a person postpones immediate pleasures for long-term values.
Helping Power Automate and citizen developers mature responsibly requires patience and guidance from those of us in formalized IT. We need to aid and guide citizen developers as they are exposed to and try to understand the value and purpose that non-functional requirements serve in the solutions they’re creating. We can’t just assume they’ll inherently know. The reason we do the things we do isn’t necessarily obvious – at times, even to many of us.
Those of us in IT also need to see Power Automate and the larger Power Platform as another enabling tool in the organizational chest that can be used to address business process needs. Rather than an “us versus them” mentality, everyone would benefit from us embracing the role of guidance counselor rather than adversarial sibling or disapproving parent.
References and Resources
- Microsoft: Power Automate
- Microsoft: Power Platform
- Gartner: Citizen Developer Definition
- Microsoft Support: Overview of workflows included with SharePoint
- Microsoft Support: Introducing SharePoint Designer
- Microsoft Support: SharePoint 2010 workflow retirement
- Microsoft Learn: All about the product retirement plan (workflows, designer etc.)
- Microsoft Learn: Plan and prepare for Power Automate in 2022 release wave 2
- Microsoft: Office is becoming Microsoft 365
- Link: Power Automate home/launch page
- Microsoft Power Automate: Save Outlook.com email attachments to your OneDrive
- Microsoft Power Automate: Save Gmail attachments to your Google Drive
- Microsoft Power Automate: Notify me on Teams when I receive an email with negative sentiment
- Microsoft Power Automate: Analyze incoming emails and route them to the right person
- Microsoft Power Automate: Start an approval for new file to move it to a different folder
- Microsoft Power Automate: Read information from invoices
- Microsoft Power Automate: Start approval for new documents and notify via Teams
- Microsoft Power Automate: Track emails in an Excel Online (Business) spreadsheet
- Microsoft Power Automate: Templates
- Microsoft Learn: List of all Power Automate connectors
- Microsoft Learn: Adobe PDF Services
- Microsoft Learn: DocuSign
- Microsoft Learn: Google Calendar
- Microsoft Learn: JIRA
- Microsoft Learn: MySQL
- Microsoft Learn: Pinterest
- Microsoft Learn: Salesforce
- Microsoft Learn: YouTube
- Microsoft Learn: What is an on-premises data gateway?
- Red Hat: What is application lifecycle management (ALM)?
- Splunk: What Is Source Code Management?
- CIO: What is IT governance? A formal way to align IT & business strategy
- Wikipedia: Non-functional requirement
- TechNet: SharePoint 2010 Best Practices: Is SharePoint Designer really pure evil?
- Microsoft Learn: Microsoft Power Platform guidance documentation
- Microsoft Learn: Power Platform adoption maturity model: Goals and opportunities
- Microsoft Learn: Admin and governance best practices
- Microsoft Learn: Introduction: Planning a Power Automate project
- Microsoft Learn: Application lifecycle management (ALM) with Microsoft Power Platform
- Microsoft Learn: Create packages for the Package Deployer tool
- Microsoft Learn: SolutionPackager tool
- Microsoft Learn: Source control with solution files
- Betterteam: Guidance Counselor Job Description
- Atlassian Bitbucket: What is Git
- TechCrunch: What Exactly Is GitHub Anyway?
- Microsoft Learn: What is Azure DevOps?
- Wikipedia: Visual Studio Code
- TechTarget: command-line interface (CLI)
- JSON.org: Introducing JSON
- Nintex: What is a citizen developer and where do they come from?
- Encodian: An award-winning Microsoft partner
- Microsoft Power Automate Community Forums: Reuse flow
- YouTube: ‘When a user runs a Trigr’ Deep Dive
- Encodian: Encodian Trigr App Deployment and Installation
- Encodian: (Trigr) General Guidance
- Encodian: ‘When a user runs a Trigr’ overview
- Wikipedia: Joshua L. Liebman