From a recurring task to a controlled workflow.

Starters, steps and one unambiguous task

Workspace Studio describes flows as starters followed by steps. A schedule or event begins the flow; subsequent steps process the input. For planning, use one bounded sentence: summarise internal open tasks from a specified source each weekday and present them to the owner. That is easier to verify than “organise my business”.

Example: a daily overview of open items

The flow reads approved status data, assembles open items with sources and responsible roles, and prepares an internal overview. An empty source produces “No verifiable data”, not invented reassurance. Binding commitments and customer communication stay outside this initial scope. This allows the value of the summary to be assessed before adding further actions.

Enable the new extensions deliberately

Custom steps, integrations and webhooks announced September 17 are off by default. Administrators can enable them in Workspace Studio and configure human approval requirements. Custom steps and integrations have separate settings; webhooks follow sensitive-step approval rules. This does not establish universal approval for every flow. Specify which effects need approval and what happens after rejection. The new Gemini Workspace MCP connectors have different defaults and must not be confused with these controls.

Understand custom starters, Apps Script and webhooks

The September update adds custom starters, custom steps, third-party integrations in beta and webhooks. External events can trigger flows, custom logic such as Apps Script can be included, and HTTP requests can reach other services. Admin settings begin rollout September 17; user features start September 21 for Rapid Release and September 30 for Scheduled Release. A webhook URL allowlist is available only on selected editions. Verify tenant, edition, approvals and destination fields rather than assuming the integration is already available everywhere.

Working template: a flow record

Keep a short operating record alongside the flow: purpose, starter, source scope, destination, allowed recipients, approval step and shutdown route. Add expected behaviour for an empty input, duplicate event and missing connection. The record should also explain who handles pending approvals when the owner is unavailable. Test that coverage before a time-critical workflow depends on it.

• Test evidence: record the input, actual output and assessment.
• Change: review added fields as new data transfers.

Real tests, visible failures and a shutdown route

Google makes clear that test runs cause real changes. Use controlled test data and inspect the output in the destination system. Activity history and switching a flow off support operations; shared flows are copies with separate responsibility. Document the owner, review interval and failure route before colleagues adopt the flow. A green run status alone does not prove a correct hand-off.