Just when I thought it couldn't get any worse, it did.

TL;DR – lots of Dynamics and Power Platform exams are being retired. I don't care about Dynamics, but Power Platform is a different story:

• PL-200 is being retired. In my opinion, this is one of the few exams that should have actually been retired a while ago. But it's odd that PL-400 is staying around when PL-200 is leaving
• PL-500 is being retired. I dislike this decision, but admittedly RPA is no longer the bee's knees, and Power Automate isn't that great (as I talk about in this article). Similar to the last point, it's odd that PL-300 gets to stick around when PL-500 is leaving, especially since most of PL-300's exam content is covered in DP-600
• PL-600 is being retired, which is the worst decision in this latest batch of exam retirements. Retiring a solution architect exam is crazy work. Sorry to everyone who busted their ass to get this one.

I'll just copy-paste some grumblings from my LinkedIn post I wrote about this, and move on to a different topic (hopefully something positive).

I think this is the last straw for me, to the point where I can officially recommend that if you are thinking of taking a Microsoft exam, just don't. Do AWS or GCP for cloud, Databricks for data engineering, GitLab for DevSecOps, or anything else besides Microsoft. At least these companies (hopefully) won't toss all their learning and certs to the curb when the next new shiny thing enters their view.

ORIGINAL POST

Last year I did a lot of work to study for and pass several Microsoft and UiPath certification exams. I enjoy the grind that it takes to do well on exams, so much so that I wrote a post about this last year. At this point I have extensive experience with both of these exam providers.

I've been especially impressed by Microsoft's exam program, which has some unique benefits compared to its competitors:

• Beta exams
• Free renewals
• Very reasonable cost (Fundamentals/GitHub – $99, Associate/Expert – $165), and even cheaper if you register as a student

All of these benefits and more converted me to becoming a voracious Microsoft learner throughout all of 2025.

So what went wrong?

Microsoft made a blog post where they announced several exam additions and changes focused around AI (of course).

New exams include:

• Azure Databricks Data Engineer Associate
• SQL AI Developer Associate
• Cybersecurity Business Professional

But more importantly – and the focus for this blog post – Microsoft is retiring several of their certifications for “new” AI-focused exams:

They are also consolidating their Windows Server Hybrid Administrator exams (AZ‑800 and AZ‑801) into one exam (AZ‑802), which seems like a decent change. But unfortunately that change is the only decent one:

• AI-103 at least makes some sense, but couldn't AI-102 have just been updated to have more agentic questions?
• AI-200 and SC-500 are the most frustrating, more on this later
• AI-300 seems to be an odd combo of DP-100's machine learning topics plus some DevOps-related topics
• AI-901 is the most confusing. Why is AI-900 being replaced with this “new” exam that has the exact same name?

My issue with AI-200 and SC-500 is that their existence suggests that people should prioritize developing and securing AI above all else. In reality though, and hold on to your hats for this one – people develop and secure more than just AI. They also “operationalize” more than just AI. But this current approach sends a subtle message that AI is the only thing worth learning. And if you want to learn something else, it still has to tie back to AI somehow.

I get that AI is important; I really do. Although a part of my soul dies every time a LinkedIn cringe-poster tells me AI is the second coming of Jesus Christ, I can't deny that AI is very powerful, and AI is critical to learn. But Microsoft shoving AI into everyone's face, and injecting it into every trace of their learning platform, at the expense of other kinds of learning, is very disappointing to me.

I will readily admit that part of my disappointment is because I have three of the certifications that are getting retired. Of course I'd be bitter about that. But that frustration will fade soon. The disappointment that will last longer is the gradual blending of Microsoft's learning into an AI-centric homogenized mush.

I plan to take the new AI exams when they're in beta, but if I fail the beta exams, I don't think I'll take the official exams later, unless they're given for free. This is definitely the sentiment for other exam takers as well. I recommend reading the comments left under Microsoft's blog post, if my blog post hasn't bored you to death yet. Some people are asking some great questions about exam renewal, validity, and more. And so far, the answers aren't very encouraging.

And this is especially true in the public sector. Quite often, the only two process automation tools available in the public sector are UiPath and Power Automate, for better or worse. And after extensive time with both of these tools, I think it's hard to deny that UiPath is the better of the two, and Power Automate is worse.

Specifically, I'm referring to Power Automate's cloud flows. Power Automate has seen improvements in recent years with the addition of AI Builder, work queues, and of course Power Automate Desktop. But in all these years (at least six since Microsoft Flow was renamed to Power Automate), the cloud flow experience still has the same janky issues that were there on day one. In 2025 alone, I have seen

• Connections breaking for no clear reason, without notification emails sent to anyone on our team
• Error messages for failed actions sometimes being completely unhelpful when trying to fix a flow
• Functionality that simply does not work as advertised, unless you sacrifice all your sanity to find a workaround

Even right now as I'm writing this, I created a flow to see if I could edit it in the new designer view. But I am not being given the option to open the flow in the new designer, and there is no clear reason why. Issues like this are what make Power Automate the weakest link in the Power Platform ecosystem to this day.

But as it happens, there is an alternative to Power Automate that not only fixes all these issues, but is cheaper and has more features. This alternative is Azure Logic Apps.

When you create an Azure Logic App and edit it in the visual designer, it may look similar to Power Automate's connector/workflow framework. And that's because it is. Power Automate is actually built on top of Azure Logic Apps. As I see it, Power Automate cloud flows are essentially an extension of Azure Logic Apps that can use Power Automate specific features, and integrate with other Power Platform solutions.

But Azure Logic Apps offers unique benefits of its own. It integrates with Azure services much better than Power Automate. It supports custom JavaScript code. And most importantly, it solves one of Power Automate's larger issues: licensing.

Often there is a certain trigger or action that is either really helpful, or required to build a flow. Naturally, these particular triggers/actions are often locked in the premium tier, requiring a paid license to use it. If anyone needs to modify or run a flow that uses a premium trigger/action, they need a paid license as well.

I will give Power Automate props for being quite affordable compared to other API integration services out there. But I've been amazed at how many clients are hesitant to pay even $15 a month for Power Automate Premium, despite how many benefits it offers. More than once, I've had to build bloated workflows to do something in several actions that could have been done with one premium HTTP action. And sometimes I've had to report that one or more use cases are unfortunately not possible because we don't have a premium license.

This is where Logic Apps shines. There is no licensing in Logic Apps. Instead, it offers consumption and standard hosting plans. The standard plans are intended for very high complexity/volume workflows, but the consumption plan lines up with a typical Power Automate use case. The consumption plan charges for each time the logic app runs. Azure's site has a full cost breakdown (make sure to click on the consumption plan instead of the standard plan), but just as a simple example, if you had a logic app with 5 standard actions that ran once per day, this specific app would cost $0.02 per month.

And this logic app can be modified by anyone on the team, with full access to every trigger and action. Seems like a pretty good deal compared to paying $15 per month for a license that might use only 1-2 premium actions in 1-2 flows.

If your Power Automate use cases do not require integrating other parts of the Power Platform (apps, pages, etc), then migrating your Power Automate cloud flows to Azure Logic Apps is a no-brainer. If you have Azure-specific processes to automate, even better!

Whether you want to try Azure Logic Apps out for yourself, or you would rather stick to Power Automate, Logic Apps is an option that more people should know is out there. At least for me, if I knew Logic Apps existed 1-2 years ago, I could have developed much better automations.

I've been working to get a few certifications throughout the past year and a half. I find the cycle of studying and passing each exam to be fun and satisfying. I like how paying for exams ensures I have some skin in the game, so that I'm not just taking and retaking exams mindlessly, but rather putting in effort to ensure that I only have to take each exam once. But I will admit that the “reward” of passing these exams up to this point has pretty much been bragging rights on LinkedIn, and more confidence when talking about software development topics outside my day-to-day RPA work.

While this is a perfectly fine reward for me, I think most people do not see any immediate benefit in their current jobs (promotions, raises, etc) when they pass IT exams. Grinding certifications is far from a cure-all for career dissatisfaction and stagnation. The bigger benefits lie in the future. For the worriers out there, certifications can mean remaining competitive in what is currently the worst job market my generation has seen. Or, more optimistically, certifications can help people stand out in job applications when they are ready to make a change.

In my view, there is a spectrum of what hiring managers value more: projects on one side, and IT certifications on the other. I think it's a fairly safe guess that the average hiring manager would be more compelled by an interesting project, rather than one or two certifications. Although I think hiring managers/teams tend to undervalue certifications, I can understand the opinion that on-hands experience could be a better indicator and predictor of future success.

But in the year of our Lord 2025, personal and professional achievements must now compete with vibe coded slop. Hard work has to compete with reckless, rushed experiments. If both approaches appear to produce “the same product,” then the one that took less time to make will win out, despite the abundance of issues that come with creators having almost no connection to what they made.

I readily admit that my personal projects (e.g. my Blazor apps) have their issues, but I can tell you exactly what each file does, and I would know exactly where to go if any bugs are found. Someone else could vibe code a similar app that looks better and does more things, but if it breaks, the only option this hypothetical vibe coder has is to cross their fingers that Cursor can identify and fix the issue (without creating new bugs).

I think (or at least hope to God) that most people would easily say that asking AI to generate a picture doesn't make them an artist. But some situations just need cheap and fast art, and if a company accidentally uses an AI-generated picture of a person with six fingers, the worst consequence would be a bit of laughter. But in this same vein, I would say that a vibe coder is not a developer. And if a vibe coder were to deploy the code equivalent of a six-fingered person image, mountains of technical debt would be the least of the company's concerns.

But what does this vibe coding rant have to do with certifications? I believe that the harder it is for hard work to be valued in favor of effortless trash, the more important it is to have some way to verify that someone is still committed to learning things themselves. If someone got certified in DevOps, for instance, chances are much higher that their insights come from personal knowledge, rather than from Copilot prompts that are forgotten within minutes of reading.

I am certainly guilty of letting Copilot compensate for my intellectual laziness every now and then, but I work hard to ensure that these moments are rare, rather than a way of life. I am convinced that the only way we improve as people and as developers is if we continue to pursue lifelong learning, and we resist the temptation to let AI do the “learning” for us.

My means to this end is studying for certification exams. Your approach could be different, but whichever way you learn best, the important thing is that we keep exercising our learning muscle. There are a few studies, like the one in this TIME article that suggest that excessive ChatGPT usage could be weakening our ability to think critically. I'd like to not end up as one of those statistics, and I imagine you also feel the same way.

One very important aspect of automation development that is often overlooked is making automations as lightweight as possible. There's probably a better and more accurate term for this, but I personally say that an automation is lightweight when it uses as few dependencies and external applications as possible.

The more lightweight an automation is, the easier it is to maintain and distribute. One of the best examples from my personal experience is Excel. So many bots use Excel files, and some of them require Excel interaction that isn't possible with low code activities. When I started developing Excel bots, I opened Excel and used the UI for involved Excel steps. Now I shudder at the thought of using Excel's UI, but we all have to start somewhere.

Later on I started to use macros, which were much more reliable than using the UI. This seemed like the ideal solution, until a certain client asked if there was a way to automate Excel in a way where they didn't have to buy more Office licenses. After I thought about this for a bit, I realized the importance of making bots lightweight:

• Every dependency that a bot uses has a small chance of possibly conflicting with other dependencies. Even if there are no conflicts, bots will still be cluttered if there are too many dependencies
• Every external application that a bot uses has to be installed on all machines (both attended & unattended). This is costly if the software is paid (like Excel)

Another way to consider “lightweight” bots is “self-contained.” If a bot can manage to be completely self-contained, using no external applications at all, more options open up for how to run the bot. It could run entirely in the background, in a cloud VM, or even in a serverless environment, depending on the situation.

So how can we go about making our bots lightweight? The typical process I follow is doing some research for whatever platform I'm using to see if any packages can do things that low-code activities can't. We'll use Excel as our example, and see if we can create Excel file automations without Excel.

For Robocorp, this is rather simple. The RPA Framework gives two Excel options: RPA.Excel.Application and RPA.Excel.Files. The latter supports xls and xlsx files without needing to install Excel.

For UiPath, this is a bit more involved. UiPath has Excel activities that fall into two groups: Application group (Excel install required) or Workbook (Excel install not required). The only problem is that the Workbook activities are limited to reading and writing Excel files, but not much else.

Thankfully there is a solution, conveniently included in UiPath.Excel.Activities. Two of its dependencies, ClosedXML and NPOI, can be used directly for advanced Excel interaction. ClosedXML is ideal for modifying modern xlsx files, and NPOI can modify legacy xls files. I recommend first converting xls files to xlsx whenever possible, so that you can add further changes in ClosedXML:

• Use NPOI to read your xls file as an NPOI.HSSF.UserModel.HSSFWorkbook
• Use the HSSFWorkbook to convert your sheet to a datatable using either JSON serialization/deserialization or another approach
• Use ClosedXML and your table to create a ClosedXML.Excel.XLWorkbook

Excel is just one example, but there are other external applications that you may be able to replace with packages. If you're working with PDF files, instead of installing and paying for Adobe Acrobat Pro, you could check if PDFsharp or RPA.PDF have what you need. Whatever your use case is, if you create lightweight bots, then you, your clients, and your coworkers will all benefit.

Do you ever think about how your career has progressed over time, from when you started your first job to now? When I think of my career progression, I remember when I was about to graduate. My education was scattered and unfocused due to needing to transfer colleges halfway through. While my peers spent their free time deciding which job offer to accept, I was struggling to get a single job offer.

Even after I did get my first internship and job, imposter syndrome took over and wouldn't let go. I had absolutely zero idea what I was doing in my business analyst internship, and I remember dreading each day that I would be found out as a fraud and fired.

This dread continued in my first job, where it felt like every new hire in my cohort knew what they wanted to do and how to do it. Meanwhile, there I was searching for my first project to work on, with no sense of direction whatsoever. But one day I did the first helpful thing in my career. I sat down and learned something: SAS.

After I studied SAS long enough, I was able to pass the Base and Advanced exams. It was such a fulfilling feeling, and even though I ended up never using SAS again, I'm still very proud of those first certifications.

Eventually I was told to study for and pass the UiPath certification. As I worked to get this certification, I was picking up concepts very fast. Looking back, it's obvious that the reason I found learning UiPath easy was that UiPath's low-code approach is very newcomer-friendly. But another reason I found UiPath easy to learn is that the concept of RPA is extremely simple to grasp, unlike anything from college.

Take the manual process you're given, and use UiPath's low code activities to build the process from A to Z. That's it. No data structures or OOP required. Easy peasy. Even though the world of automation development is much more involved than I thought it was at the time, I finally felt that what I was learning made sense to me.

Learning something is much easier if the context you're learning it in is enjoyable and makes sense. For example, if you like making games, you would find learning C# easy in Unity, or C++ in Unreal Engine. Although you could try to learn C# by making an ASP.NET web app, learning C# this way would be much more involved if you struggle with web development like I did in college.

Once you find that niche you excel in, everything else falls into place. If you've read other articles on this blog, you can probably guess that I ended up learning Node.js through Apify, and Python through Robocorp. Everything I learn is from the same automation perspective. If I wanted to learn Go, I wouldn't try to develop a web service. I'd start learning it by using it in a Pipedream flow.

This concept is even true for non-development topics. Your favorite subject in high school was almost certainly the one you learned the most about. Dedicating a bit of time to the areas you thrive in is a great way to foster lifelong learning. For me, I thrive in automation development, and I don't see this changing anytime soon.

One last thing – it's incredibly unlikely that anyone currently in college is reading this, but if by chance you are, and you're in a situation like I was, consider trying RPA. You might like it 😉

API integration is a great way to automate API-based processes at a far lower cost than using RPA. Although RPA processes can send API requests, if UI automation isn't required, then using an API integration service can prove very beneficial.

Below are a few API integration services I've worked with in the past, ranked from worst to best. This list excludes companies that are strictly focused on enterprises (no free tier, no pricing listed on the website, e.g. Mulesoft and Workato). This list also excludes companies with RPA capabilities (Apify, UiPath Studio Web, etc)

• Zapier – Although this platform is quite popular, and has the most integrations, in my opinion it's overpriced, lacks key features, and has a very stingy free tier
• Make – I consider this platform to be superior to Zapier in every way. It's cheaper, its free tier is much more generous, and it has more features. On top of all these benefits, processes are displayed as flowcharts, making complex scenarios easy to visualize
• Power Automate – Ignoring desktop flows (which in my opinion is not a good RPA solution), cloud flows are the best choice for enterprises. Power Automate offers several unique features, including approval flows, AI Builder, and most importantly the ability to integrate with Power Apps and Power BI
• Pipedream – read on to see why this is the best

If you want the TL;DR version of the rest of this article, the reason Pipedream is the best is that they offer, to quote their site, “code-level control when you need it, and no code when you don't.” They have the same prebuilt components as other integration services, but Pipedream has the advantage of these components being open source. But this isn't the only thing that makes Pipedream stand out.

Out of the box they offer support for Node.js, Python, Go, and Bash. All options (except Bash for now) allow you to import packages. This adds functionality not found in any other API integration service. For example, if you wanted to convert markdown to HTML, Zapier can't currently do that, but in Pipedream all you need to do is import the marked package and use marked.parse(). If you have complex data rules, it's very cumbersome to add these rules in Make or in Power Automate, but all you need to do in Pipedream is add those rules in your language of choice.

I know I bashed Zapier earlier, but to their credit, they offer JavaScript & Python code steps, which can help with complex data rules like the ones mentioned above. But Zapier's code steps have a major limitation – they do not support npm or pip packages, meaning you can't use Node.js or Python to their full potential.

From my personal experience, there's also a hidden benefit of using a code-focused API integration service: you learn more as you do it. For example, instead of using a prebuilt email integration to send an SMTP email, I researched and realized that I could just use nodemailer. And now that I know that this package exists, I can use it in any Node.js scenario, even outside of Pipedream.

Ultimately, deciding which API integration service to use comes down to personal preference and research. You may decide you want a more user-friendly, no-code option, and Make certainly fits those requirements. Maybe 80% of your processes use Office 365, so Power Automate would be the obvious choice. I've made my case for why I think Pipedream is the best, but whichever platform you choose, be sure it's one you have complete confidence in, and are ready to use for the long haul.

For no reason in particular, I decided to revisit this framework three years later. Since then, UiPath has come out with several improvements to Studio, and I figured that this old framework could use a bit of a facelift. So to that end I did the following:

• Migrated the framework from VB to C#, and from Windows to cross-platform
• Refactored several bloated xaml workflows into C# coded workflows
• Delisted the old version from the UiPath Marketplace. If this framework is of any interest to you, feel free to reach out and I'll send you a copy

Originally written November 3, 2022

Imagine this: one of your coworkers makes a massive UiPath project with tens of workflows and hundreds of activities. This automation goes live, but later on the business informs you that they received an error email, and you've been asked to debug this automation. Unless your coworker was incredibly diligent and thorough with their exception messages, odds are that you'll need to search through tens of workflows and hundreds of activities to find the failed activity.

In my experience debugging UiPath automations, finding the activity that failed is easily the most time-consuming part. After I identify the failed activity, finding the problem and developing the fix usually isn't too involved. But hunting down failed activities can be quite the tedious, draining chore. Thankfully there is a way to get rid of this chore and make debugging much quicker: using the Global Exception Handler in your project.

What is the Global Exception Handler? To quote UiPath's documentation:

The Global Exception Handler is a type of workflow designed to determine the project’s behavior when encountering an execution error. Only one Global Exception Handler can be set per automation project.

This article describes the Global Exception Handler well and is worth reading, but I don't think this article emphasizes enough just how powerful this feature is.

The documentation mentions the errorInfo and result arguments. I don't have too much to say about result; the documentation covers it all. But I would personally recommend not modifying result, because if you modify it, some activities could be aborted, ignored, or retried when you don't want them to.

errorInfo on the other hand is much more interesting. It has several worthwhile properties, some that the documentation doesn't even mention:

• ActivityInfo: the ID, name, and type of the failed activity
• Arguments: the names and values of all the activity's arguments
• Exception: the exception object
• RetryCount: how many times the activity was retried using ErrorAction.Retry
• Variables: the names and values of all the workflow's variables
• WorkflowArguments: the names and values of all the workflow's arguments

At an absolute minimum, the Global Exception Handler should log the ID, name, and type of the failed activity. With this, developers can look in Orchestrator logs to find which activity failed right away, eliminating the chore of tracking it down manually. This log message alone makes a big difference in any project.

But to really make the most of the Global Exception Handler, listing Arguments, Variables, and WorkflowArguments will give debuggers every bit of information they could possibly need. Maybe the cause of the failure was simply that a value was wrong, possibly due to a typo or an incorrect .NET expression. If this info is immediately available to debuggers, they may be able to immediately identify the issue without even testing the bot.

If it wasn't clear by this point, exception handling and reporting is something I'm passionate about, because debugging is the only thing I dislike about automation development. And anything I can do to lessen the time I have to spend debugging results in more time spent developing new things.

For this reason, I decided to make some UiPath frameworks that make heavy use of the Global Exception Handler. In these frameworks, any exceptions that occur are caught by the Global Exception Handler. The extra execption information is archived in emails and Excel reports, so that debuggers have several ways to find every bit of exception info possible.