Turn a rough sketch into a testable Make automation with Maia

A sketch of an automation can be simple: a row arrives, one condition is checked, selected fields go somewhere else. Building it requires more decisions—where to look, which column to test and what to do with the rows that fail. Make’s 20 October Maia update adds a useful place to settle those details: Plan mode, which presents the approach before building begins.[1]

This walkthrough follows Make’s current documentation; we have not executed the workflow. It uses an invented stationery-request sheet, with two expected output rows, so there is a concrete result to inspect.

You need a Make account with Maia access and a Google account containing a workbook you can edit. Maia is in public beta. Free accounts receive a 30-day trial from signup with 45 messages; continuing after either limit requires a paid plan. Paid plans currently include a temporary allowance of 70 messages for 30 days after the first Maia interaction, then use credits. Building conversations and scenario runs draw on the same credit pool.[3][4]

Make the small decision visible

Create a practice workbook with a Requests tab containing four headers: Request ID, Item, Quantity and Status. Create an Approved tab with Request ID, Item and Quantity. Put the three fictional requests below into Requests. Keep the output tab empty apart from its headers.

Draw three connected boxes: new Requests row; Status equals Ready; copy Request ID, Item and Quantity to Approved. Add an “otherwise end” branch to the decision. The diagram specifies what should happen when a row is first collected; it is not a later approval process.

Ask for the plan before the build

Choose + Create scenario in Make and select Plan in Maia. Attach the sketch using the chat’s paperclip, or paste or drag it into the chat. Supported images are PNG, JPEG and WebP, up to 1.5 MB each, with a maximum of three per session.[2][1]

In Plan mode, Maia asks its questions up front and presents the modules, assumptions and approach for approval. Read the proposed destination carefully: Requests is the input, Approved is the output. If it proposes updating the original row or copying every status, correct that plan before approving it.[1]

When the Google Sheets module requires a connection, choose Create a connection, then Sign in with Google and complete the account authorisation. Maia’s description of an account does not itself connect that account.[4]

Inspect the route and run the example

The route should contain Google Sheets > Watch New Rows, a filter, then Google Sheets > Add a Row. Select the practice workbook and the correct tab in each module. Set Table contains headers to Yes; use A1:D1 for the Requests header range. Map Request ID, Item and Quantity into the matching Approved columns. In Add a Row, choose Insert rows for the Insert data option.[5]

Open the filter between the modules. Its condition should use the incoming Status field, Text Operators > Equal to, and Ready as the comparison value. Give it a useful label, such as Ready requests.[6]

Set the trigger’s row limit to at least three. For this first run, right-click Watch New Rows, choose Choose where to start and select All so it includes the existing examples. Save the module and the whole scenario.[7]

Open Schedule settings from the toolbar and select On demand. This removes the periodic schedule; Run once can then start the exercise. Click Run once and open the output bubbles to inspect the rows each module processed.[8][9]

The intended Approved output contains R-101 with three notebooks and R-103 with two pens. R-102 should be absent. Compare the values in the sheet itself as well as the module output. If all three rows arrive, inspect the filter; if quantities land under item names, correct the field mappings.

A blank row inside Requests can stop Watch New Rows from processing the rows below it. Another easily missed detail is the trigger’s memory: after a run, it fetches rows it has not previously processed. Changing R-102 from Pending to Ready later does not make it a new row.[5][7]

For a second check, append a new Ready request and run once again. It should add that request while leaving the two earlier outputs alone. Avoid resetting the trigger to All unless you intend to process the old rows again; in this simple append-only route, that can create duplicate output rows.[9]

If the actual job requires revisiting requests when their status changes, return to Maia with that requirement and revise the trigger design. Make documents a separate Watch Changes module for user edits, with its own webhook setup; script or API updates do not trigger it. Settling that distinction gives the original three-box sketch a precise meaning.[5]

Report an error or suggest a correction