The March 2026 Make Grid updates add customizable layouts, live teammate presence, access to supported connected objects, and improved navigation. Together, they make Grid more useful for reviewing an automation landscape before a shared field, table, endpoint, or team name changes.
Make published its announcement on March 24, 2026. The related Help Center release is dated March 18, 2026. This guide focuses on operational change reviews, not scenario construction. It shows where Grid helps with discovery and where a team must continue in the scenario editor, execution history, source application, or its own change record.
What changed in Make Grid, and what did not?
The update adds four capabilities:
- Customizable layouts: move items and resize folders and teams to reflect how a group thinks about its automation landscape.
- Live collaboration: see teammate cursors and active users while navigating Grid.
- Connected objects: open supported objects from the canvas, with view-and-edit or view-only access depending on the object.
- Improved navigation: use right-click panning and pinch-to-zoom, alongside Make’s reported loading improvements.
Make describes Grid as a visual dependency map of scenarios, apps, data stores, and Make AI Agents. It can help a reviewer find references, inspect which scenarios read from or write to a dependency, and identify scenarios that need attention. It does not by itself approve a change, prove that a particular record was processed, or replace execution validation.
Use Grid to find and understand dependencies; validate the change in the relevant scenario and source system.
Make describes Grid as automatically updating as changes occur, but the reviewed documentation does not promise a refresh interval or propagation time. Likewise, Make says loading performance improved without publishing a benchmark. See the Help Center release notes for the documented update categories.
What Make Grid shows and who can see it
Grid automatically maps relationships among Make scenarios and connected dependencies. The usage guide describes searching scenario content, inspecting dependency relationships, reviewing errors, and viewing selected usage information. Search can include module field values, scenario notes, and AI Agent system prompts. It is useful for locating stored configuration references, but it is not a guarantee that every dynamically generated runtime value will be found.
Visibility follows Make permissions. The current Make Grid product page says Grid is available on paid Make plans, while users can see only scenarios they are authorized to view. A reviewer should therefore confirm access to the relevant organization, team, and scenarios before treating search results as a complete inventory.
Grid provides dependency-level visibility. It can help answer which scenarios use an object, but it does not answer whether a specific record was processed successfully. Use scenario execution history for run evidence and the connected application for the external object’s current state.
The four updates in daily work
Customizable layouts
In Edit Layout, users can move items and resize folders and teams. A review group might organize the map by business unit, workflow stage, owner, or another structure that makes affected scenarios easier to locate. This changes the map’s presentation, not the scenarios’ execution logic.
Live teammate presence
Teammate cursors and a presence widget support a live walkthrough or troubleshooting session. They show who is navigating Grid, but they are not an approval log, a record of every edit, or a documented conflict-resolution mechanism. Capture decisions in the organization’s chosen change record.
Connected objects in the workspace
Grid lets users open supported connected objects from the canvas. The access label describes the documented Grid interaction, not every native operation available in the underlying service. A user’s permission in that service still matters.
Improved navigation and loading
Right-click panning and pinch-to-zoom make large landscapes easier to inspect. Make also reports improved loading performance and automatic updating. Because no benchmark or synchronization guarantee is published, treat those statements as product descriptions rather than service-level commitments.
Which connected objects can you view or edit?
Make’s Grid usage guide separates connected objects into two groups. Access also depends on the user’s permission in the underlying service.
Supported workspace access
Google Sheets, Google Docs, Google Slides, Google Calendar, and JotForm. Confirm the user’s permission in the underlying service before changing anything.
Preview access
Google Forms, Tally, and Typeform. Use the preview to inspect configuration; do not treat these objects as editable from Grid.
Make says it plans to add more connected objects, but has not specified a release schedule. Before editing, confirm the object’s access category, the user’s service-level permission, and whether the proposed change needs separate business approval.
Use Grid for a dependency-impact review
Consider a proposed rename from Legacy Team to Customer Operations. The requester defines the change, a Grid reviewer investigates references, the scenario owner updates and tests configuration, and a change-record owner retains the decision and evidence. This is a human-led operating process, not a documented Grid-triggered automation.
Use exact search for known field names, URLs, table names, team names, and module values. AI is unnecessary for deterministic matching. If a team later uses AI to summarize ambiguous notes, restrict it to that bounded task and require human verification before changing a shared dependency.
Search results should be checked against runtime-generated values and configuration locations that may not be searchable. Review formulas, filters, routers, HTTP payloads, prompts, and external application fields separately rather than assuming one search result is complete.
For the review record, one row should represent one change request and one affected scenario. A proposed illustrative record could contain the following fields:
{
"change_request_id": "CR-2026-014",
"dependency_native_id": "customer_accounts.department",
"old_value": "Legacy Team",
"proposed_new_value": "Customer Operations",
"affected_scenario_id": "scn_4821",
"reviewer": "operations-owner",
"test_execution_reference": "execution-reference",
"completed_at": "2026-03-26T14:30:00Z"
}This is illustrative implementation guidance, not an export format published by Make. For production records, a proposed uniqueness key is organization ID plus change request ID plus scenario ID. If multiple writers can process the same review, enforce that key with a database unique constraint or transactional upsert. A lookup followed by insert can create duplicates under concurrency.
Make’s Wemolo customer story describes using Grid search to find scenarios affected by a department-name change. It is a vendor-published customer example, not an independently audited benchmark, downloadable template, or proof that Grid automatically changed the scenarios.
Know when to leave Grid and investigate elsewhere
Use each system for the question it can answer:
- Grid: Which scenarios and dependencies may be related?
- Scenario history: What happened during a particular run?
- Connected application: What is the external object’s current state?
- Change or audit record: What was approved, by whom, and when?
An error indicator or attention view is a signal to investigate, not a complete root-cause report or proof that a repair worked. Open execution details and determine whether the problem involves configuration, credentials, an external service, data-store capacity, a webhook queue, or another dependency. After a repair, verify the rerun and downstream effects.
Make’s usage guide describes credit, data-transfer, and operations views covering the last 30 days. The documentation also notes that credit figures may exclude some transformer-related consumption, including iterators and aggregators. Treat these as aggregate usage views, not per-record execution evidence.
A cleared visual error is not a successful remediation. Require an execution result and a source-application check when the change can affect external data.
A practical adoption decision
Grid is a good fit when a team needs a shared view of scenario dependencies, a collaborative review workspace, or a faster route to locate scenarios affected by a known change. Keep a separate approval or audit process when changes require named owners, sign-off, rollback references, or test evidence.
Start with one bounded dependency, such as a shared department field or database column. Learn which layout and search terms help the team, then decide whether a broader landscape reorganization is worthwhile.
- Can the reviewer see every relevant scenario and dependency?
- Are the old value, proposed value, and stable identifiers recorded?
- Is the connected object’s access category and service permission confirmed?
- Does the scenario owner have a defined test and downstream verification step?
- Where will the decision, execution reference, and completion time be retained?
Adopt Grid as a discovery and collaboration surface, while retaining deliberate change control and execution validation around it. Teams that need help designing or maintaining Make scenarios can explore ConsultEvoMake automation servicesSupport for designing, reviewing, and maintaining Make automation workflows.
