## What is measurably new in Make's version control Make's pages state few figures, one being the 60-day retention of saved versions, so what's new is mostly a set of capabilities, not measurements. Make claims two: a recorded history of scenario changes (version control page) and an improved scenario toolbar (toolbar page). Both were checked on 2026-10-16, and the version control page states a 60-day retention for saved versions. For an admin, a recorded history of changes means you can trace a change after it breaks something. The version control page describes it, and states that each saved version is kept for 60 days, except the latest, which is kept until you save a newer one. Judge the toolbar by whether your editors save time. The toolbar page describes an improved toolbar in the scenario editor. It changes how people work inside a scenario, not what Make records about it. The page gives no speed or efficiency measure, so any such claim would be yours to test. ### What Make's version control pages leave unstated The pages give a 60-day retention period for saved versions and say the descriptions feature is available on all plans; they give no version cap. They also say nothing about who can restore a version, or whether AI-assisted edits are labelled separately in the history. Until Make addresses these, treat the history as a record of changes, not as proof of who or what made them. Check the admin settings in your own account before relying on it for audit. ## Connecting Make scenarios to other apps in Activepieces today Nothing specific to Make scenario versions has shipped in Activepieces that this article could confirm. So the audit trail stays inside Make.  Match the job to the machinery: **three general building blocks exist**. The table orders them by setup effort and shows what each can reach, so you can match the one with the least machinery to the job you actually have. | | Setup effort | What it can reach | When to choose it | |---|---|---|---| | HTTP request step | Lowest: a URL, a method and credentials | Any endpoint Make or another app exposes over HTTP | You need one defined call, such as fetching a scenario's details | | AI step with custom or OpenAI-compatible provider | Moderate: a provider endpoint and key | A model you point it at, working on data you pass in | You want a summary or review of a change | | MCP server | Highest: a server to run or find, then connect | Whatever tools that server exposes | An agent must pick among several actions itself | _Prices and plan limits checked against [help.make.com](https://help.make.com/scenario-version-control) and [help.make.com](https://help.make.com/improved-scenario-toolbar-and-version-control) on October 16, 2026._ Read the table this way: more setup buys flexibility, and also more to watch. Start at the top. When you know the exact call, the HTTP request step is the fit. You supply the address, method and authentication, and the step returns the response. It reaches only what that endpoint exposes, so confirm in Make's documentation that the data you want is available there before building around it. The AI step with a custom provider takes an OpenAI-compatible endpoint and text you have already fetched, for instance a change description. It can't see Make by itself, so it's only as complete as the input you pass it. Treat its output as a draft, not a record. When an agent should decide which action to take, an MCP server fits. Reach depends entirely on the tools the server offers, and an agent that can call tools can also change things. Check what each tool permits before connecting it to anything that edits scenarios. ## What version control does for recovery With built-in scenario versions, recovery changes from hunting for the right copy to choosing a recorded state. Make's pages publish no price or restore-time figure for it, so any claim of savings is unproven. Read the table as reporting only what Make's pages confirm, with the rest marked. Read the speed column as a description of the workflow, not a measurement. Each row shows who has to do the work of finding the last good state. | Approach | Cost stated on Make's pricing and help pages | Speed of recovery | |---|---|---| | Built-in scenario versions | No figure published | Recovery starts from the tool's own recorded history; no timing published | | Manual copies or exports | No figure published | Depends on someone having exported before the change; no timing published | | Naming conventions | No figure published | Depends on everyone following the convention; no timing published | | Notes | No figure published | Depends on the note being accurate and findable; no timing published | **All three manual methods fail the same way**: they only work if a person remembered to act before the edit. An AI-assisted change or a colleague's quick fix won't reliably trigger that habit. **Built-in history removes that dependency**, which is its real advantage.  Before you rely on it, confirm on Make's current pricing and help pages which plans include versions and what the history retains. **Make states 60-day retention for saved versions, so keep one manual export of any scenario you can't afford to lose.** ## What to watch next in Make scenario versions Keep one manual export, and recheck two Make help pages and the changelog on a schedule, because the recorded history is only as reliable as what those pages currently state. Nothing here is a prediction; it's a list of things to verify as of 2026-10-16. ### Make version control help pages to recheck On its help page on the improved scenario toolbar and version control, Make says you can add descriptions to scenario versions, so you can iterate safely without creating clone scenarios. That means the description field is your audit trail: if a team leaves it blank, the history shows that something changed but not why. Recheck the page for any change to how Make names, lists or restores versions, since each of those alters what a reviewer can rely on. Watch the toolbar page second: it covers where the version controls sit in the editor. Any move there changes what you tell new editors to click. Also watch the changelog for changes to the 60-day retention of saved versions. 1. Read the version control page and the toolbar page in full, and write down what each says about descriptions, restoring and listing versions. 2. Check plan availability for your organization's plan, so you know whether your scenarios have version history at all before anyone depends on it. 3. Decide how scenario changes are reviewed: who must write a version description, who reads it, and who may restore an older version. Version history records changes; it doesn't review them for you. 4. Note the date you checked the changelog, and set the next check. That dated note tells the next person how stale your assumptions are. ## Frequently asked questions Because several open questions turn on staleness too, each answer says whether Make's pages settle it or stay silent. Is Make scenario version control available on every plan? Make's toolbar and version control page states the feature is available on all plans. Check your organization's plan against Make's pricing page and the feature's help page before building a review process around it. If the feature is missing on your plan, your change log is still the dated note. Does Activepieces support Make scenario versions natively? No native support is documented on Make's pages. Connecting the two today means general building blocks: webhooks and HTTP requests on each side. **Activepieces allows unlimited flows on every plan**, including free, so a custom flow for this doesn't count against a flow limit. You would be moving data you already have access to, not reading version history through a dedicated integration, so treat any such flow as custom work you maintain. ### Can an AI step read a Make scenario's history? Make's pages don't say. They don't describe version history as something an AI step can query, and they don't say whether AI-assisted edits are labeled as such in that history. Until they do, assume attribution shows the account that saved the change, not whether a person or an assistant wrote it. Record that distinction in your own change note. Where should I check for updates to this feature? Start with Make's help center page for scenario versions, then its product release notes and pricing page. Those are the places where plan availability, restore behavior and attribution would be stated first. Date what you find, because that record goes stale like any other. ## Related reading - [Zap vs Scenario vs Workflow: Choosing the Right Automation Format](https://www.activepieces.com/blog/zap-vs-scenario-vs-workflow-choosing-the-right-automation) - [Agentic AI Security: Why Our Control Model Must Evolve](https://www.activepieces.com/blog/agentic-ai-security-why-our-control-model-must-evolve) - [Best Data Automation Tools of 2026 for Analytics Teams](https://www.activepieces.com/blog/best-data-automation-tools-of-2026-for-analytics-teams)What it buys is a fixed point to compare against, so the question shifts from "what did we break?" to "which change introduced this?"