Business alignment happens when the API supports the goals of the business, whatever they are. If the goal of the business is to reduce costs, then the API should help automate manual processes. If the goal of the business is to attract partners, then the API should help those partners easily exchange data with the company. If the goal of the business is to attract new customers, then the API should be easy to discover and onboard. Whatever the goals of the business are, to have alignment, the API needs to support them. To say that a workflow embodies alignment is to say that it manifests how the APIs that compose it support the goals of the business. Embodiment, in this context, means that the workflow itself, with all its steps, and the API operations that are part of it, all support the goals of the business. So, how can you make sure that your workflows embody business alignment? Keep reading.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
It doesn’t make sense to run processes that don’t drive the business forward. And yet, this is what happens in many companies. Processes that were once crucial to the growth of businesses have become obsolete. However, the systems that run them haven’t been updated. More sophisticated workflows fall into the same situation, I’m afraid. And, sometimes, it’s even worse because it’s harder to identify which workflow steps need to be updated, or even removed. Outdated workflows not only go against business goals but also contribute to productivity and revenue losses. That’s why having up-to-date workflows running the latest versions of API operations, fully aligned with the goals of the business, is so important. Then, how do you make that happen?
Understanding if a workflow is going against one or several business goals isn’t straightforward. One starting point is getting business-related workflow metrics and seeing which ones degrade over time. “Anything that is related to the objectives of the business can become a workflow metric if there’s a workflow responsible for fulfilling it,” I wrote in Workflow Metrics That Matter. Examples of meaningful business-related workflow metrics include the number of invoices processed per period, the average invoice processing time, the order fulfillment automation rate, and the lead conversion rate. Pick the metrics that matter to your business and start measuring them now. Even better, build processes that update those measurements periodically. If one or more metrics fall below a reasonable threshold, then you know that the workflow stopped contributing to your business goals. So, how do you get those metrics?
One way to get all the business metrics that matter to you is to use your workflow solution’s telemetry capabilities. However, while you can get most operational metrics directly, you might need to do some calculations to obtain those business metrics. The reason is that most business metrics are specific to the reality of each company and have to do with the behavior of the workflow. So, while you can easily get a metric such as the number of workflow executions per hour, translating it into something like the number of processed invoices needs context. The easiest way to get those metrics using n8n is to create a node that you add as the last step of any workflow. The “metrics collector” is an n8n code node that is triggered whenever a workflow ends. The code inside it simply returns the timestamp at the time the workflow ended, the workflow name, and its ID.
return {
json: {
timestamp: new Date(),
name: $workflow.name,
workflowId: $workflow.id
}
};This will make it easy to store each workflow execution as a metric. You can use a Data Table node, or any node that lets you permanently store information that you can later analyze. A slightly more sophisticated approach is to record both the start and end times of the workflow so you can calculate how long the execution took. To do that, you’re going to create a code node and connect it to the very beginning of the workflow, and another one that you’ll connect at the end. The first one has an event attribute with the value start, and the end one—you guessed it—has the same attribute with the value end. You’ll also add another attribute called traceId that will help you identify which entries are part of the same workflow execution.
return {
json: {
event: 'start',
timestamp: new Date(),
name: $workflow.name,
workflowId: $workflow.id,
traceId: $execution.id
}
};
Connect both nodes to a Data Table node, et voilà, you now have a simple metrics storage system. Now, every time your workflow runs, it will store two rows in the Data Table you chose. The first row corresponds to the start event and measures the time when the workflow started. The second row stores the end event, and its data is obtained from the time the workflow ended. This is just the beginning, of course. If you replace the Data Table with, for example, a Google Sheet, you would be able to easily query the metrics. And, you can add more calculations and context to each code node to measure not just execution time but also other business-related metrics.
While this approach sounds interesting, it requires some coding skills. Yes, you’ll be able to measure any metric you can think of. However, you’ll need to maintain the code that does the calculations. Every time you change a workflow, you need to make sure the metrics are still being correctly recorded. In the end, you will have another dependency to maintain. Also, will you really be able to obtain metrics that correlate with the business goals? Calculating the average invoice processing time is one thing. But knowing how to obtain the order fulfillment automation rate, for example, is something else. My point is that business metrics tend to easily become complex and hard to measure.
Knowing how much your workflows contribute to the success of your business is definitely interesting. However, you should decide if the cost of maintaining the code that grabs the metrics is worth the effort. The solution I presented is an example of what is available. Adapt it to your own needs and automate things as much as possible.
