In real workflows, cloud APIs often return before the resource is actually usable. For example, your flow might create an instance and immediately try to attach storage or run a configuration step, only to fail because the instance is still booting or the resource state has not converged.

AWS has native waiters for some APIs, but they cover only a small subset of services and operations. In Google Cloud, you generally don’t get an equivalent out of the box, which pushes teams toward brittle sleep steps and custom retry loops.

You can now add a “waiter” to cloud API actions so CloudFlow pauses until the resource reaches the state you need, then continues automatically. This reduces fragile retry logic and makes multi-step automations behave consistently across AWS and Google Cloud.

A waiter is tied to the specific action you’re running and waits on a defined target state before the next step runs. You enable the waiter on the action, choose what to wait for, and optionally tune the polling behavior for faster or more conservative checks. If the waiter needs extra inputs to verify readiness, you provide those parameters as part of the waiter configuration.

To get started, review the "Add a Waiter" article.

If you have a Microsoft Azure Consumption Commitment (MACC), you can track drawdown progress directly in DoiT Cloud Intelligence with the same daily-updated visualizations, service-level breakdowns, and forecasting already available for AWS EDPs and Google Cloud spend commitments.

After adding your Azure MACC in Commitment Manager, you’ll be able to:

• See your spend-to-date, remaining balance, and a forward forecast against your MACC commitment value, updated daily.
• Understand which Azure services are generating eligible spend and contributing to MACC decrement, with month-by-month totals across your full contract period.
• Track Marketplace spend against your contract limit with a month-by-month breakdown and drill down into which Marketplace services contributed.
• View all your cloud commitments in one place if you also have active AWS or Google Cloud spend commitments.

To get started, open Commitment Manager in DoiT Cloud Intelligence. For configuration guidance, see the docs.

Cost anomalies do not always stop after the first notification. In real environments, an anomaly can persist across hours or days, get buried in Slack or Teams, or grow significantly after initial detection. FinOps and CloudOps teams need a follow-up signal when cost risk remains unresolved or escalates.

In DoiT Cloud Intelligence, cost anomaly notifications are no longer limited the initial detection.

You can now configure re-notifications so you’re notified again when:

• An anomaly remains active after a specified period of time (similar to a reminder or snooze), or
• The anomaly impact increases, either by a fixed dollar amount, a percentage, or a combination of amount and percentage.

Previously, notifications were triggered only when a threshold was first crossed. Now, notifications can continue if cost risk persists or escalates, helping teams stay aware of ongoing or worsening spend issues.

Re-notifications can be configured within your existing anomaly notification settings and works with current Slack, Teams, and email delivery options. To learn more about it, consult our Help docs or raise a support ticket to speak to a DoiT expert.

Cloud automations rarely live in isolation. One flow detects an issue, another enriches context, a third notifies the right team. Without a shared source of truth, you end up duplicating logic or hardcoding mappings that drift over time.

The Datastore node provides your CloudFlow automations with a shared, managed place to store and query structured data, enabling multiple flows to reference the same tables for enrichment, routing, and state. Think of Datastore as a lightweight database you can use directly from flows.

A common pattern is a tag ownership table:

• You maintain a table that maps tags (or tag patterns) to an owner, team, cost center, escalation channel, and metadata.
• Any flow can query it to resolve “who owns this?” consistently.

Example: an anomaly flow spots a sudden spike on an untagged workload. It looks up the resource’s tags, queries the ownership table, and then routes the alert to the correct Slack channel. A separate remediation flow uses the same table to decide who can approve a change and where to open a ticket.

In the Datastore node, you can:

• Get records using filters (including values from previous nodes)
• Insert records for new rows, including batch inserts
• Upsert records to keep a table current without duplicates by using a unique key column

Supported column types include Text, Integer, Numeric, Boolean, Date, Timestamp, and JSON.

How to get started

Create a Datastore table for shared mappings (for example, tag-to-owner), then reference it from any flow via a Datastore node query. Use Upsert when you want scheduled flows to keep the table continuously in sync from an authoritative source. 

Some workflows need a deliberate delay to avoid API throttling or to wait for changes to propagate. For example, if you’re looping through cloud resources or applying IAM updates, a short pause can prevent rate-limit errors and reduce noisy retries.

A common operational pattern is also dev environment scheduling: start in the morning, run all day, then shut down in the evening. Sleep lets you build this into a single flow without external schedulers.

What’s new

You can add a Sleep node to pause a CloudFlow run for a configurable duration, then automatically resume execution. This helps you:

• Space out provider API calls to reduce throttling risk
• Add cooldown periods before re-checking or notifying
• Wait for eventual consistency (for example, new resources or IAM changes becoming effective)
• Orchestrate time-based actions in one flow, like dev environment start and end-of-day shutdown

How it works

When a run reaches the Sleep node, CloudFlow marks the run as Sleeping and pauses execution until the configured time elapses. After the duration completes, CloudFlow wakes the run and continues to the next node.

How to get started: https://help.doit.com/docs/operate/cloudflow/nodes/sleep

As CloudFlows grow, the same steps often get copied into multiple workflows. That makes fixes slower and outcomes inconsistent, because you end up updating the same logic in several places.

Use-case example: you run a daily workflow that detects cost anomalies, then triggers CloudOps remediation. Instead of duplicating “ownership resolution” and “notification formatting” steps across every anomaly flow, rightsizing flow, and incident flow, you put that logic in a single subflow and call it from each parent workflow, so updates propagate everywhere.

What’s new

• You can now use the Sub Flow node to run one CloudFlow from inside another, so shared logic lives in a single reusable flow.
• Parent flows can pass inputs as parameters (mapped to the sub flow’s local variables), so the same sub flow works across multiple use cases.
• Each invocation creates a child run you can open from the run history, making troubleshooting and auditing easier.

You build a reusable flow (the sub flow) and publish it. In your main workflow, add a Sub Flow node, select the flow you want to call, and provide the parameter values for that run. When the parent reaches that node, CloudFlow runs the selected flow as a child run and returns its output back to the parent so the workflow can continue.

Getting started

• Create the reusable flow you want to call and define the local variables it should accept.
• In the parent flow, add a Sub Flow node and select the flow to call from the Flow drop-down.
• Map parameters, then use the Sub Flow node output in downstream nodes.

Read more about subflows in CloudFlow Help Center.

CloudFlow notification nodes now support threaded Slack messages — post a summary to the channel and automatically follow up with detailed information in the thread.

What's new

When configuring a Slack notification node, you'll see a new Thread Message field below the main message. If you add content there, CloudFlow will:

1. Post your main message to the Slack channel
2. Automatically reply in a thread with the detailed follow-up

If you leave the thread message empty, notifications work exactly as before — just a single message to the channel.

Why use threads?

• Keep channels clean — post a brief alert to the channel, then put the full breakdown (cost tables, resource lists, detailed findings) in the thread where those who need the details can find them
• Organize related data — separate the "what happened" summary from the "here's everything you need to know" details
• Reduce noise — team members see the headline without being overwhelmed by data-heavy content

Full message formatting support

Both the main message and the thread message support all of CloudFlow's rich formatting options:

• Tables — rendered as native Slack tables with bold headers
• Lists — bullet points with nested indentation
• Buttons — clickable action buttons with URLs
• Images — embedded image blocks
• Links — inline clickable links

How to get started

1. Open any Slack notification node in your CloudFlow
2. Write your main channel message as usual
3. Add your detailed content in the new Thread Message field
4. Save and test — you'll see both messages appear in Slack, neatly organized

This is a fully backward-compatible addition. Your existing notification nodes continue to work without any changes.

Metrics is one of the most powerful tools in your FinOps toolkit. This latest release brings substantial usability improvements that make building, understanding, and acting on your data faster and easier than ever.

New Allocation previews give you clear visibility into the individual building blocks that make up your Metric, so you can understand exactly what's contributing to your data, not just the end result. This means no more jumping back and forth between Allocations and Metrics to piece together the full picture; everything you need is right there in context.

AI-powered allocation creation takes the manual effort out of the process. Instead of building allocations from scratch, you can now express your intent and let AI generate them for you; a meaningful step toward a more intelligent, streamlined workflow.

We've also made it easier to manage Metric variables. You can now remove variables you no longer need, and the experience for adding new ones has been streamlined so it gets out of your way.

Rounding out the update: direct links to use a metric in reports mean fewer clicks between insight and action, and improved interactions around generating previews make the whole experience feel more responsive and fluid.

As your CloudFlow flows grow in complexity, keeping context about why a flow was built, what it monitors, and how to modify it becomes essential. Instructions live alongside the workflow itself — so the documentation is always where your team needs it, not in a separate wiki or document.

You can now write rich-text instructions directly inside your CloudFlow flows — making it easy for your team to understand what a flow does, how to configure it, and what to expect.

What's new

Every CloudFlow now has a dedicated README node visible at the top of the editor canvas. Click it to open a side panel that displays your flow's documentation, or click Edit to open a full markdown editor where you can write and format your instructions.

The instructions editor supports full Markdown, so you can structure your documentation with headings, bullet points, code snippets, bold/italic text, and more — everything you need to clearly explain your workflow's purpose and logic.

Link directly to nodes

Use the special $nodes["Node Name"] syntax to create clickable references to specific nodes in your workflow. When someone reads your instructions and clicks a node reference, the editor automatically navigates to and highlights that node on the canvas. You'll also get autocomplete suggestions as you type, so you don't need to remember exact node names.

Always accessible

• README node on the canvas — a dedicated node is always visible at the top of your workflow, giving you one-click access to the instructions panel
• Top bar menu — you can also open the instructions editor from the workflow's top bar
• Side panel — read your instructions without leaving the graph view, in a convenient slide-out drawer