Triggers

When creating a flow, the first node is always a trigger node that starts the flow. The trigger node provides data to every downstream node in the flow. You can use this data in filters and other nodes.

There are four types of triggers:

Custom schedule

Manual trigger

Webhook trigger

DoiT Cloud Intelligence™ event trigger

One flow can have only one trigger node.

Custom schedule

A Custom schedule is useful when you need a flow to run at specific times or recurring intervals. For example, checking the utilization rates of Google Cloud Compute Engine instances at 9:00 AM every day.

• Configuration options: Time zone, Start date, Time, Frequency.

• Frequency defines how often a flow is triggered. Supported values: Daily, Weekly, Monthly, Custom, and Run once.

  • When choosing Daily, you can trigger flows to run at specific times throughout the day. The minimum interval between runs is one hour, allowing you to schedule up to 24 executions per 24-hour period.

  • Choose Custom if you need the flow to run at recurring intervals. Supported values: Hour, Day, Week, or Month. For example, every two hours or every two weeks.

  • Choose Run once to schedule a single, non-repeating execution that can be run at a custom time. This is useful when performing one-time actions, such as updating the OS kernel on a legacy server or applying a patch during a maintenance window.

Below is an example custom schedule.

Manual trigger

This type of trigger is used when a flow should only run on demand. It helps guarantee human oversight as well as offer flexibility, allowing you to control flow execution as needed.

To start a flow with a manual trigger, select Run in the top bar of the CloudFlow editor after the flow has been published.

Webhook trigger

You can use a webhook trigger to start a flow using data from an API. Consequently, any external system capable of making API calls can trigger a flow. For example, you can use the Run flow action in Zapier to trigger a flow. See also DoiT Integrations.

You must provide a sample of your JSON so that we can detect the structure of your data. Once we have detected the structure, the flow automatically creates the fields required for subsequent actions. With this, your data becomes part of the flow and can be used in any activity nodes, just like other data.

• Webhook URL: Provide the URL to the service that will send data to trigger this flow.

• Sample JSON: Provide a sample of your JSON so that we can detect the structure of your data. Select Detected structure to ensure that we have identified the fields correctly. If you think it is incorrect, amend your JSON sample and paste it again.

• Generate API key: Create a DoiT API key from the trigger node so you do not have to open your Profile in DoiT Cloud Intelligence. If you already have an API key, the panel shows a link to manage your API key on the Profile page. This key is used only for DoiT APIs.

DoiT Cloud Intelligence event trigger

(Applies to AWS events only) You can use a DoiT Cloud Intelligence event trigger to start a flow using an event generated by DoiT Cloud Intelligence. These events are surfaced from AWS CloudTrail, so anything AWS CloudTrail captures, such as an instance being started or terminated can be used to trigger your flow.

Note

You can only trigger flows for cost anomalies if you have configured real-time cost anomalies.

• Select an event: From the list, select a DoiT Cloud Intelligence event for which you want to trigger a flow.

• Event payload details: A list of referenced fields that are available within the selected event are displayed. These are the fields that you can reference in your flow.

Trigger node results

This section lists the fields available in the output of a trigger node that you can reference in downstream nodes.

Note

When configuring a node, you typically choose one upstream node whose output to reference. The Schedule trigger node is an exception: its output can be referenced from any node in the flow, in addition to that chosen node.

The trigger result includes date and time in both legacy and ISO 8601 formats. Use the iso8601 object when an API requires ISO 8601 timestamps. The existing currentDate and startTime fields remain for backward compatibility.

Name	Description	Example value
currentDate	Date of the run in YYYY-MM-DD format	2026-02-09
currentDay	Day of month (1–31)	9
currentMonth	Month (1–12)	2
currentYear	Four-digit year	2026
customerId	DoiT customer or organization identifier	ABCDeFhijKLm1nopQrStUVwx
ownerEmail	Email of the flow owner	[email protected]
startTime	Unix timestamp in milliseconds	1770644776279
startTimeMillis	Unix timestamp in milliseconds	1770644776279
startTimeSeconds	Unix timestamp in seconds	1770644776
userId	DoiT user identifier	aBBCDe1FG2hIJkL34MNO
iso8601	Object with ISO 8601 date and time strings: currentDate (YYYY-MM-DDT00:00:00.000Z) startTime (YYYY-MM-DDTHH:mm:ss.sssZ)	currentDate: "2026-02-09T00:00:00.000Z", startTime: "2026-02-09T15:21:01.760Z"
variables	Global and local flow variables	globalVariables: {}, localVariables: {}
billingScopes	Lists of cloud project and account identifiers for the customer. Each key contains an array of objects with id and name: google-cloud — GCP project IDs amazon-web-services — AWS account IDs microsoft-azure — Azure subscription IDs Use these in downstream nodes to iterate over or filter by cloud scope.	google-cloud: [{id: "my-project", name: "My GCP Project"}], amazon-web-services: [...], microsoft-azure: [...]
billingScopesRowCount	Total number of cloud scopes across all three providers (GCP + AWS + Azure).	3

Tip

Use billingScopes when you need to run actions per GCP project, AWS account, or Azure subscription—for example, in loops or filters that reference Variables from the trigger node.