Workflows is a fully managed, serverless orchestration service that runs a defined sequence of steps across Google Cloud services and any HTTP-based API.

The problem it solves

Real business processes rarely fit inside a single program. Placing an order might require checking stock in one service, charging a card in another, creating a shipping label in a third and sending a confirmation through a fourth. Each of these calls can be slow, can fail, or can need to be retried. If you chain them by writing glue code inside one of the services, that service becomes tangled with knowledge about all the others. If one step fails halfway, nobody knows where the process stopped, and cleaning up becomes guesswork.

Workflows lifts this coordination out of your code. You describe the process once, as a series of steps, in a simple definition. The service then runs it, remembers where it is, retries failed calls on your instructions, waits for slow operations without costing you idle servers, and records every step of every run. Your individual services stay small and focused, while the process itself is visible and easy to change.

What it is used for

Teams use Workflows to coordinate microservices, to automate data pipelines, to run order and payment processes, to manage infrastructure tasks, to wait for human approvals, to call outside APIs reliably and to tie together serverless functions, containers and managed services.

A small vocabulary makes everything else easy, so learn these eight terms before moving on.

Before choosing Workflows, it helps to understand the two basic ways services can cooperate.

Two styles of cooperation

In orchestration, one central controller tells each service what to do and when. It knows the whole process. In choreography, there is no controller. Each service reacts to events published by others, and the overall process emerges from many independent reactions. Think of a conductor directing an orchestra versus dancers in a crowd each responding to the music and the dancers around them.

Workflows is an orchestrator. Its strength is that the whole process is written in one place, so you can read it, test it, change it and see exactly where any run stands. Its weakness is that the controller becomes a central piece you depend on. Choreography with messaging services scales loosely and avoids a central piece, but the process becomes scattered and harder to understand and debug. Many real systems use both, with events kicking off workflows and workflows publishing events.

Several services sound similar, and choosing the right one saves a lot of rework.

The neighbors

Cloud Scheduler runs a job at a set time, like an alarm clock, but it does not manage a multi-step process. Pub/Sub delivers messages between services, but it does not know about order or progress. Eventarc routes events from Google Cloud services to destinations, but it does not hold state. Cloud Composer, based on Apache Airflow, is a heavy-duty platform for scheduled data pipelines with a rich ecosystem and a larger operational footprint. Cloud Run functions and Cloud Run run your own code, which is the place for complex logic, while Workflows is the place for sequencing calls between such pieces.

Workflows is made of a few clearly separated pieces, each with one job.

The big picture

On the left are the triggers: schedules, events, direct requests and messages. They start an execution through the Workflows service. The service reads the workflow definition and runs each step in turn, keeping the state of the execution, including variables and the current position, safely stored. On the right are the targets: Google Cloud services reached through connectors, your own services running on Cloud Run or functions, and any outside API reached by plain web requests. Around the whole system sit identity, which decides what the workflow may do, and logging, which records what it did.

flowchart LR
  T1["Cloud Scheduler"] --> WF["Workflows Service"]
  T2["Eventarc Events"] --> WF
  T3["API or Console Call"] --> WF
  WF --> DEF["Workflow Definition"]
  WF --> ST["Execution State"]
  WF --> C1["Connectors to Google Cloud"]
  WF --> C2["Your Services on Cloud Run"]
  WF --> C3["External HTTP APIs"]
  WF --> IAM["Service Account Identity"]
  WF --> LOG["Cloud Logging and History"]
        

Each piece in one line

The definition says what should happen. The service engine makes it happen and tracks progress. Connectors make calling Google Cloud simple and safe. Plain web requests reach everything else. The service account decides permissions. Logs and execution history let you see and debug every run.

A workflow is written as a list of named steps, and a small set of step types covers almost every need.

Writing the definition

A workflow definition is written in a structured text format, using either of two common styles, and is stored with the workflow resource. It begins with optional input parameters, followed by a list of steps. Each step has a name, which must be unique, and does exactly one kind of thing. The next step is normally the one listed after it, unless a step says otherwise.

Expressions and built-in helpers

Values can be calculated with expressions that combine variables, text and numbers. A standard library provides helpers for common jobs such as working with text, lists, dates and times, encoding and decoding data, generating unique identifiers and pausing for a set time. The workflow can also read secrets from Secret Manager, so passwords and keys never need to be written into the definition.

The heart of Workflows is calling other services, and there are two ways to do it.

Connectors for Google Cloud

Connectors are ready-made building blocks for many Google Cloud services, such as data warehouses, storage, messaging, batch processing and machine learning. They provide several benefits. They sign in automatically using the workflow’s service account, so you handle no tokens. They apply sensible retry behavior for temporary failures. And for operations that take a long time, such as starting a large data job, they wait for the operation to finish automatically, so the workflow does not need a hand-built polling loop.

Plain HTTP calls

For your own services and any outside API, the workflow makes ordinary web requests. It can choose the method, add headers, send a body and read the response. Authentication is configured on the call. For services inside Google Cloud such as Cloud Run, the workflow can attach an identity token that proves who is calling. For other Google Cloud APIs it can attach an access token. For outside APIs it can send keys retrieved from Secret Manager.

A workflow does nothing until something starts it, and there are several ways to do that.

Synchronous and asynchronous starts

When an execution is started, the caller can either receive an execution identifier immediately and check later, which is the usual choice, or wait for a direct result for short workflows. Long processes should always be treated as asynchronous, and callers should look up the outcome using the identifier or have the workflow notify them at the end.

flowchart LR
  S["Cloud Scheduler: every night"] --> W["Workflow Execution"]
  E["Eventarc: file uploaded"] --> W
  A["Application: user placed order"] --> W
  P["Another Workflow"] --> W
  W --> R["Result or Notification"]
        

Follow a single execution from start to finish to see what the service does for you.

sequenceDiagram
  participant T as Trigger
  participant W as Workflows Engine
  participant S1 as Service One
  participant S2 as Service Two
  T->>W: Start execution with input
  W->>S1: Step 1 call
  S1-->>W: Response
  W->>W: Save state and decide next step
  W->>S2: Step 2 call
  S2-->>W: Response
  W->>W: Save state
  W-->>T: Return result
        

Real processes are not straight lines, and these tools handle the turns.

Decisions with switch

A switch step checks conditions in order and sends the execution to the first matching branch, with an optional default if none match. This is how a workflow chooses between paths, such as handling a small payment differently from a large one that needs review.

Loops with for

A for step repeats steps for each item in a list or each number in a range. It is how a workflow processes a batch, such as sending a notification to each customer in a list. A loop can also stop early or skip items based on conditions.

Subworkflows for reuse

A subworkflow is a named mini-workflow inside the same definition. It accepts parameters and returns a value, just like a function. Subworkflows keep long definitions readable, avoid copying the same steps in many places and let you test pieces separately in your mind. A subworkflow can even call itself, which is useful for patterns such as walking through pages of results.

Doing independent things at the same time can turn a slow process into a fast one.

Parallel branches

A parallel step starts several branches at once, each a list of steps, and waits until all of them finish. Imagine checking inventory, verifying a customer and calculating shipping at the same time instead of one after another. The total time becomes the time of the slowest branch rather than the sum of all of them.

Parallel loops

A for loop can also run its iterations in parallel, which is ideal for applying the same action to many independent items, such as processing a hundred files. There is a limit on how many branches run at once, so very large batches are processed in waves.

Shared variables and care

Parallel branches may share variables, but branches that change the same variable can create confusing results. Branches should mostly work independently, and shared variables should be declared and updated carefully. Errors in one branch can be handled inside that branch, or can stop the whole step, depending on the policy you choose.

flowchart TD
  START["Order Received"] --> PAR["Parallel Step"]
  PAR --> B1["Check Inventory"]
  PAR --> B2["Verify Customer"]
  PAR --> B3["Calculate Shipping"]
  B1 --> JOIN["All Branches Complete"]
  B2 --> JOIN
  B3 --> JOIN
  JOIN --> NEXT["Continue to Payment"]
        

In distributed systems, failure is normal, and a good workflow plans for it.

Types of failure

Some failures are temporary: a service is briefly busy, a network connection drops or a limit is hit for a moment. Retrying a moment later often succeeds. Others are permanent: the data is invalid, the permission is missing or the target does not exist. Retrying will never help. A good design retries the first kind and handles the second kind with a different path.

The try, except and retry tools

Steps can be wrapped so that errors are caught. An except block receives details of the error, which can be inspected to decide what to do. A retry policy says which errors to retry, how many attempts to allow, how long to wait between attempts and how quickly the wait grows, which is known as exponential backoff. Predefined policies exist for common cases, and you can also write custom ones. When retries run out, the error moves to the except block or ends the execution.

Custom errors and timeouts

A workflow can raise its own errors, for example when a business rule is broken, so that callers see a clear reason. HTTP calls have timeouts, so a slow service does not hold the process forever. Whole executions also have an overall time limit, which is long enough to support very slow processes but is still finite.

Some processes take hours or days because they wait for the outside world, and Workflows is built for that.

Waiting without cost

A workflow can sleep for a set time, or wait for a long operation to finish through a connector, and during that time no servers of yours are running. You pay only for the steps, not for waiting. This makes patterns such as “wait three days and send a reminder” cheap and simple.

Callbacks

A callback lets a workflow pause until an outside party reports back. The workflow creates a callback endpoint, which is a unique address, and then passes that address to another system or sends it to a person, for example inside an approval email. The workflow waits on that endpoint. When someone sends a request to the address, the workflow wakes up and receives the data, such as “approved” or “rejected”. A timeout can be set so the workflow does not wait forever.

Human in the loop

Callbacks make human approvals easy. An expense workflow can email a manager a link, wait for the click, and then either pay the expense or reject it. Because waiting costs nothing, the manager can respond in a minute or in a week.

sequenceDiagram
  participant W as Workflow
  participant M as Manager
  participant X as Callback Endpoint
  W->>X: Create callback address
  W->>M: Send approval link containing address
  W->>X: Wait for response with timeout
  M->>X: Click approve or reject
  X-->>W: Deliver decision
  W->>W: Continue based on decision
        

When a process spans several services and one step fails late, earlier steps may need to be undone.

The problem

In a single database, a transaction can roll back all changes at once. Across several independent services, no such global rollback exists. If a workflow has reserved stock and charged a card, and then the shipping step fails, the system is left in an inconsistent state unless someone undoes the earlier steps.

The saga idea

A saga is a sequence of steps where each step that changes something has a matching compensating step that undoes it. If a later step fails, the workflow runs the compensating steps for everything that already succeeded, in reverse order. Workflows suits this pattern well, because the order of steps, the error handling and the compensating actions all live in one readable place.

Idempotency matters

Because retries and compensations can repeat calls, each action should be idempotent, meaning that doing it twice has the same effect as doing it once. Passing a unique request identifier on calls is a common way to achieve that, so a repeated charge request is recognized and not applied twice.

A workflow can call many services, so who it acts as, and who may change it, matters greatly.

The workflow’s own identity

Every workflow runs as a service account, and every call it makes uses that identity. The permissions of that service account decide what the workflow can do. Give each workflow its own dedicated account with only the permissions that its steps truly need. A shared, all-powerful account turns every workflow into a potential path to everything.

Who can do what with workflows

Separate permissions exist for people who deploy or edit workflows, people who may start executions and people who may only view results. The person who edits a workflow can change what it does with the service account’s powers, so editing rights are effectively as sensitive as those powers. Keep them limited and reviewed.

Secrets, encryption and network

Secrets should be read from Secret Manager at run time. Workflow data is encrypted at rest by default, with the option of customer-managed keys for organizations that need them. Calls to private services can be restricted using network controls, and workflows can be placed within a security perimeter to limit data exfiltration.

Protecting what goes into logs

Variables and responses may appear in execution history and logs. Avoid placing sensitive data such as card numbers or personal details into variables you will log, and filter what you write into logs deliberately.

A process you cannot see is a process you cannot fix, and Workflows makes visibility a built-in feature.

Execution history

Every execution records its steps, including which ran, what each returned and where any error occurred. In the console you can open an execution and see it step by step, like replaying a recording. This is often the fastest way to understand a failure.

Logging

Workflows can send execution logs to Cloud Logging at different levels of detail, from errors only to every call. A built-in logging function lets your workflow write its own messages, such as “order accepted” along with the order number, which makes searching easy. Logs link to executions through identifiers, so one search can show everything about a single run.

Metrics and alerts

Metrics report how many executions started, succeeded and failed, and how long they ran. Alerts can fire when failures rise, when executions take unusually long or when nothing runs at all, which is a good way to notice that a scheduler or trigger has quietly broken.

Experienced teams reuse a few well-tested layouts.

flowchart TD
  EV["Event: new order"] --> ORCH["Orchestrator Workflow"]
  ORCH --> VAL["Validate Order"]
  VAL --> PAY["Charge Payment"]
  PAY --> SHIP["Create Shipment"]
  SHIP --> NOTE["Notify Customer"]
  SHIP -. "on failure" .-> COMP1["Refund Payment"]
  COMP1 -. "then" .-> COMP2["Release Stock"]
        

Anti-patterns to avoid

Workflows is billed by what runs, so cost control is about writing efficient definitions.

What you pay for

At the time of writing, the service charges per step executed, with a lower rate for internal steps, such as assignments and decisions, and a higher rate for external steps, such as calls to web addresses and connectors. There is a monthly free allowance of each kind. Waiting itself, such as sleeping or waiting on a callback, does not bill for compute in the way a server would, though steps around it still count. Exact prices and free allowances change, so always check the official pricing page before budgeting.

Ways to spend wisely

A short checklist of habits that separate calm teams from those fighting fires.

Best practices

Common mistakes

Stories show how the pieces combine in real organizations.

No service is perfect, and a mature team knows both sides before committing.

Choosing your approach

Quick answers to the questions beginners ask most often.

No. Workflows coordinates calls between services and handles decisions, loops and errors. Your actual computation runs in services such as Cloud Run or functions, which the workflow calls.

Workflows is lightweight, serverless and ideal for service orchestration and business processes. Composer is a heavier platform based on Apache Airflow, aimed at complex scheduled data pipelines with a large ecosystem of operators.

Yes. Executions can sleep or wait on callbacks and long operations for long periods without consuming compute of yours, up to the service’s maximum execution time.

It acts as its configured service account. Connectors use that identity automatically, and HTTP calls can attach identity or access tokens. Always grant that account only the permissions it needs.

A connector is a ready-made block for calling a Google Cloud service. It handles sign-in, retries on temporary errors and waiting for long operations, so you write less and make fewer mistakes.

Yes. Parallel steps and parallel loops run branches simultaneously, finishing when all branches finish. Remember concurrency limits and the capacity of the services you call.

Create a callback, send its address to the approver, and make the workflow wait on it with a timeout. When the approver responds, the workflow resumes with the decision.

If it is wrapped in error handling, the retry policy may try again, and the except block may respond. If nothing handles it, the execution ends with an error that you can see in the history.

Yes. A workflow can start another workflow as a child, and a single definition can also hold reusable subworkflows that behave like functions.

In Secret Manager. The workflow reads them at run time, so they never appear in the definition or in source control.

Open the execution in the console to see each step and its result, search Cloud Logging for the execution identifier or your own business key, and use metrics and alerts for patterns across runs.

Avoid tight polling, reduce unnecessary external calls, batch work inside services, put limits on loops and alert on unexpected jumps in execution volume.

Google Cloud Workflows is the head chef of your cloud kitchen. It does not cook, but it directs every service in the right order, keeps track of progress, handles failures and waits patiently for slow work. You describe a process once as steps, with decisions, loops, parallel branches, subworkflows, retries and compensation, and the service runs it reliably as a serverless, stateful execution. Connectors make calling Google Cloud simple, plain web calls reach everything else, and callbacks bring people and outside systems into the process. Identity, secrets and logging keep it secure and visible. The best designs share common habits: focused workflows, clear step names, careful error handling, idempotent actions, least-privilege identity, definitions kept in version control and honest monitoring. Teams that orchestrate with intention build processes that are easy to read, safe to change and quick to debug.