Sign inCreate an account
Create an account

Changelog

Updated

New features and improvements in SpringRoll, what each one does for you, and why we built it. Newest first.

Atom feed

DeploymentAccessWorkspace

Covers 25 October to 4 November 2026

Launch shared team apps with Company Blueprint and security checks

Company Blueprint gives your coding agent published company guidance. Purchase Desk's Team edition brings purchase requests, reviewers and records into a shared app, while Team launch tracks whether people complete the workflow. Optional App Security checks add release evidence before deployment, and new examples and guides make it easier to get started.

Company Blueprint publishes the guidance every build starts from

Administrators can draft and publish company guidance in Workspace settings → Company Blueprint, including brand styles, interface and code patterns, authentication guidance, frameworks, starters and data-product references. Coding agents can retrieve the current publication or a specific version, and releases can record which version they used. Published versions stay available for review. Data references respect the reader's permissions; access grants, security checks and release policies are enforced separately.

Why we built it: Teams should not have to repeat the same company instructions in every build conversation. A published version gives builders a consistent starting point and reviewers a record of the guidance used for a release.

Purchase Desk Team edition, with shared records and assigned reviewers

The new Team edition uses SpringRoll accounts and a managed PostgreSQL database for shared purchase requests, private attachments, notifications and decision history. An owner assigns reviewers who already have app access. Requesters can submit, receive a request for changes and resubmit; reviewers cannot approve their own requests. Records survive app restarts and redeployments, and removing a member's access blocks their next protected request, including at the direct hosting address. The app starts private and empty, and requires configured application sign-in and managed database hosting.

Why we built it: A team needs to work on the same request and retain the decision after an update. Shared storage, explicit reviewer assignments and access checks let colleagues complete that workflow with their own accounts.

Team launch follows the work through to an outcome

App owners and administrators can record a department, workflow, participants, intended outcome, acceptance criteria and review date in Team launch. Starting a launch fixes the original participant group for reporting. The report brings together the Company Blueprint version, sign-in, participant access, deployment and release security evidence. A two-person milestone requires one participant to submit and another to approve the same request. Apps that report workflow events also show activation, returning participants and completed workflows. Time saved is labelled as an estimate based on owner-entered before-and-after timings; missing evidence remains Not measured.

Why we built it: Deploying an app is only the beginning of a team trial. Owners need to see whether colleagues can finish the intended work and have enough evidence to decide what to improve at the review.

Optional App Security checks before deployment

Settings → App Security lets administrators choose the apps, environments and checks covered by a versioned policy. Available checks cover source code, dependencies, embedded secrets, built apps and AI behavior, with findings and coverage gaps shown on the app's Security page. The same gate applies to deployment, promotion, rollback and hosting migration. Warn permits deployment with the report after checks finish or reach their deadline; Block stops a release when required evidence fails or is missing. App Security starts off and requires an operator-configured scanning service, with synthetic test profiles for checks that need authenticated access. A release approval cannot override a blocking security result.

Why we built it: Reviewers need evidence tied to the release they are about to run. Explicit coverage gaps and policy choices let a company introduce checks gradually without treating an untested app as a security pass.

Try an example, then create your own copy

Examples now includes Deal Desk, Purchase Desk, Support Room, Campaign Room and Operations Queue. Try their fictional workflows in the browser, download the source or create a private copy in your workspace. Creation follows your workspace's direct or staged deployment workflow and respects its hosting settings. Returning to an example reopens your existing copy without overwriting it. These original examples keep edits in the browser; choose Purchase Desk's Team edition when you need shared purchase records.

Why we built it: A working example makes it easier to explain the app you want and test a first deployment. Clear storage behavior helps you choose a starting point that fits a demonstration or a real team workflow.

Let your AI connection submit a proposal you have approved

You can separately opt in to agent confirmation when authorizing a ChatGPT connection. With that permission, the connection can submit an exact saved proposal after your explicit approval, without another browser confirmation. The submission records the connected member, delegated action and approval note. Existing connections keep their current permissions, changed or expired proposals need a fresh review, and company governance decisions still require a person.

Why we built it: People who choose to delegate the final submission can finish an approved action in the conversation. Separate consent and a recorded proposal keep that convenience tied to the change they actually reviewed.

Also improved

  • The changelog now has an Atom feed, so you can follow new entries in a feed reader using /changelog/feed.xml.
  • Expanded deployment guides, example walkthroughs and security guidance explain setup, storage, access checks and the handoff from a coding agent to a working team app.
  • Public pages now include clearer navigation, breadcrumbs, content dates and sharing previews to help you find and share the right guide.

Explore example apps

DeploymentAccessWorkspace

See the decision, the evidence and who acts next

Apps now brings the work that needs you above your app list. Approval briefs, data requests and release records explain what changes, what has been checked and who can take the next step, with the same facts on desktop and phone.

The work that needs you, above your apps

Everyone starts on Apps. Needs you shows the requests and app actions you can act on, while Your requests keeps track of work waiting on someone else. App cards and Overview name the next person and action. Reported problems and planned withdrawals appear before you open an affected app, and app managers can resolve reports with a recorded outcome.

Why we built it: People should be able to find their next useful action without checking several registers or mistaking somebody else's queue for their own. Keeping problems beside the app also makes them easier to report and follow through.

Approval briefs with current evidence

Each brief brings together the proposed change, requester, current app risk, warnings and named reviewers. Release reviews distinguish a UAT deployment from business sign-off. Data reviews name the requested fields and their sensitivity, and audience changes show who would be added or removed. No decision is selected in advance; rejection and requests for changes require a note.

Why we built it: A decision needs more than a status or a technical identifier. Reviewers can now compare the request with the recorded evidence and explain their choice, while requesters can see who still needs to act.

Release records that separate approval from going live

An approved release names who can deploy it and continues to say when it is not live yet. Apps, Overview and environment pages share the same next step. Deployment records distinguish queued, running and completed work, and keep the hosting candidates, limits and cost information available. Audit summaries reduce repeated bookkeeping while preserving the underlying events and uncertain outcomes.

Why we built it: Approval is one step in a release, not evidence that users can already open it. Clear handoffs and recorded outcomes help builders and owners know when to act, when to wait and what to investigate.

Data access with a clear scope and owner

Data products show their owner, source health and the apps with access alongside exploration and publishing. Access requests explain the chosen fields, purpose, environment and expiry in days. After a request is recorded, the form gives way to its outcome and a link to follow it. Existing requests and partial grants remain visible so another request does not hide what is already waiting or allowed.

Why we built it: An app builder should know what data they are asking for and where the request goes. Owners need the same scope when granting all, granting some or rejecting access, without exposing credentials or relying on technical field names.

Readable records and reachable actions on phones

Approval history, Members and Audit trail use compact rows on narrow screens. The navigation drawer scrolls to account actions and Sign out, while decision forms keep their choices and submit action reachable. Invitations name who invited you, the role and the expiry, and unknown workspace paths keep signed-in members inside their workspace with a way back to Apps.

Why we built it: Following a request or making a decision should remain practical away from a large screen. Consistent names, dates and recovery links help people understand where they are and finish the task they came for.

Also improved

  • Recertification tasks, notifications and audit records are saved together, including overdue transitions, so concurrent checks do not create duplicate work.
  • Public pages, Connect entry links and starter downloads remain reachable while unknown public addresses return a real not-found response.
  • Page titles, named contacts and shared reviewer names are clearer across connected accounts, invitations and approval routing.

Open your workspace

AgentsDataWorkspace

Covers 5 to 18 October 2026

Work with your apps from ChatGPT, explore data and see what happens next

SpringRoll now has a connection for working with your apps from ChatGPT, a data explorer for checking what an app can read, and more ways to connect company systems. Action reviews explain the exact change before you confirm it, approvals show who still needs to decide, and your first successful deployment email takes you straight to the app.

Work with your apps from ChatGPT

The new SpringRoll connection for ChatGPT lets you find the apps you can use, check deployments and backing services, and prepare a deployment, promotion, restore or other app change. Each change comes back as a saved proposal to review in SpringRoll. Apps built with SpringRoll's record integration can also let you read, create and update their records through the connection, within your existing app access and the permissions you gave it. There is no separate collection approval, including after a new release, and every record change still needs its own confirmation. Availability depends on your client's connection settings and your workspace's hosting setup.

Why we built it: Asking about an app and acting on the answer should fit into the same conversation. The connection brings that work together while keeping each change tied to your identity, your current access and a proposal you can inspect before anything happens.

Action reviews that explain the change before you confirm

A ChatGPT action review now leads with the app, workspace, environment, connected account and what will happen. Deployment proposals explain the hosting plan, backing services, runtime limits and estimated cost, including when the estimate is incomplete. Record proposals show the fields to change, and the confirmation button names the action. You can confirm for yourself, or explicitly instruct your agent to submit that exact proposal through the same page. An agent submission must declare your current approval and include a short note, recorded in the audit trail. Changed or expired proposals need a fresh review, and existing governance approvals still need a person to decide them.

Why we built it: A confirmation should tell you what you are agreeing to and what happens next. Plain descriptions, a clear status and a record of who submitted the confirmation make it easier to delegate the work while keeping the decision yours.

Explore data before putting it in an app

Each data product now has Overview, Explore and Use in an app views. In Explore, choose fields, filters, sorting and a row limit, with totals and grouping where the source supports them. Structured queries work without an AI key, and Explain query checks a query without reading the source. Owners can preview a small sample, while app managers can choose an app and environment to see exactly what its current grant allows, including field restrictions, masking and row filters. Use in an app takes you to the access request and gives you copyable integration examples for the fields already approved.

Why we built it: A connection is only useful when you can check what comes back. Seeing a sample under the same rules the app will use helps owners publish the right fields and helps builders find access problems before they reach a working app.

More sources for approved company data

Data products now support MySQL, MariaDB, Oracle and SQL Server alongside PostgreSQL. Database connections check that their source account has read-only permissions. You can also publish selected fields from explicitly mapped JSON GET resources in a REST API, starting with an OpenAPI document or a manual mapping. You review the resources and fields before publishing, and newly discovered or changed fields stay unavailable until an owner reviews and saves them. Source credentials stay in SpringRoll.

Why we built it: Company data rarely lives in one database. Supporting more sources lets an app use the systems your team already runs, while the owner still chooses what to expose and the app receives only the access it was granted.

Use company APIs with approval for the exact endpoints

The Native APIs view in Data now lets an app request specific methods and paths in Notion, Salesforce, SAP, ServiceNow, Microsoft 365 and configured API gateways. The connection owner or an administrator reviews the endpoints, app environment, purpose, expiry and request budget. Your app keeps the platform's normal request and response format, and SpringRoll checks the grant before sending each request. Notion, Salesforce and SAP now use this route exclusively. If you previously used a data product for one of them, request native endpoints before moving the app over; an old field grant does not authorize API access. Native endpoint grants rely on the source account's permissions and do not apply data product field masking or row filters.

Why we built it: An existing API client should not need a new query language to work through SpringRoll. Approving the exact endpoints keeps that integration familiar and gives the data owner a concrete decision about what the app may do in each environment.

Connect your own Notion and Salesforce accounts

The Your accounts view in Data lets members connect Notion and Salesforce through their organization's registered integration. Administrators set up that registration in Connectors, and each member links their own account separately. ChatGPT can then use the supported Notion item and Salesforce Task actions within the approved sources and fields, with confirmation for every change. If you connected an account before it was linked to an organization registration, reconnect it through Your accounts. Changing or disabling the registration also requires reconnection.

Why we built it: A shared connection for an app should not quietly become permission to change someone's business records. Separate member accounts keep each action tied to the person asking for it and let the organization control which integration those accounts use.

Approvals that show who still needs to decide

Approval routing now names the people who can decide each request type, shows the Production and high-risk rules that apply, and warns when a reviewer role has nobody in it. Submitting a request tells you who it went to. When a request needs different reviewer groups, each group must be satisfied; two approvals from one group cannot fill another group's place. The inbox, navigation badge and waiting data requests now use the same rule for what still needs your decision. Data requests show who asked, why, the environment and each field's sensitivity before you grant access, and a direct data decision resolves its linked request too.

Why we built it: A request should never look finished while a required reviewer is still missing, or keep asking for a decision that has already been made. Showing the remaining people and keeping the counts consistent tells both the requester and the reviewer what needs to happen next.

Your first deployment email takes you to the app

The one-time email after your first successful deployment now names the app, workspace, environment, version and hosting provider. Open app takes you to the deployed app when a direct link is available, and View deployment takes you to its details and logs. The email also links to app access so you can review who may open it before sharing, with inviting a teammate as an optional next step. The deployment and your access are checked again before the email is sent.

Why we built it: When your first app is ready, the next thing you want is to open it. A useful receipt gets you there immediately and keeps the details and sharing controls close by, without making you find the deployment again.

Guides that follow the work you came to do

The public SpringRoll site now walks through deployment, the App Portal and governed data access with product views and examples. Learn brings together the docs, deployment and approval guides, managed hosting guidance, an operations dashboard example and comparisons with other approaches. Agent setup instructions and starter downloads are easier to find, and the public menu groups the same destinations on a phone.

Why we built it: Before connecting a coding agent or deploying an app, you need to know how the pieces fit together. Task-based guides and concrete examples let you follow the part that matters to you and see what using SpringRoll will involve.

Also improved

  • Workspace navigation now shows Approvals and Agent connections when they are relevant to your role or existing work, with the same names on pages, menus and back links.
  • App statuses, environments and approval decisions now use consistent plain words, so the same state reads the same way wherever you see it.
  • Pages you cannot access explain the restriction inside your workspace and, where appropriate, name the administrators who can help.
  • Related-app tag links and app tag filters now work without an error.
  • All five app tabs fit on a narrow phone screen, and the workspace phone menu scrolls all the way to Sign out.
  • ChatGPT action status now distinguishes a queued request, work in progress and an outcome that needs checking, with links to the app or deployment when available.
  • If a self-hosted upgrade is missing required database updates, the ChatGPT connection now gives a setup explanation instead of a generic failure.

Read the SpringRoll docs

DeploymentAccessWorkspace

Covers 1 to 4 October 2026

One home for your apps, clearer approvals and passwordless sign-in

SpringRoll now gives every member one place to find the apps they build and use, puts everything a reviewer needs on the approval itself, and signs everyone in with an email link or single sign-on. Sharing, data connections and build logs are easier to work with too, and you can now send us feedback without leaving SpringRoll.

One home for every app

Apps now brings every app together in one place, with three views: My apps, Available to me and All apps. You see only the apps your role allows. Each one shows its status in plain words, when it last updated successfully, and a warning when the latest update failed. Adding a new app takes just a name and a repository URL.

Why we built it: Finding an app should not depend on knowing which page it lives on. One home, with a status you can read at a glance, tells you whether an app is working before you open it, and makes registering the next app quick enough that nobody puts it off.

Approvals you can decide with the facts in front of you

Each request in Approvals now shows what it is for, the environment and release it covers, the data fields it asks for, who submitted it, when it expires and which checks are blocking it, with failing checks listed first. You decide on the request itself: approve in one click with an optional note, or reject or request changes with a reason the requester can read. Bulk approval from the list has been removed, and a request assigned to a named person stays with that person.

Why we built it: An approval is only as good as what the reviewer could see when they gave it. Deciding each request with its full context makes every decision one you can stand behind, and a written reason tells the requester exactly what to fix.

Passwordless sign-in and safer sessions

SpringRoll no longer uses passwords. You sign in with a one-time email link, valid for 15 minutes, or with your organization's single sign-on where it is set up. Sessions now end 12 hours after you sign in, and signing out signs you out of every open tab. Invitations work the same way: sign in with the invited email address, then choose Join workspace. There is nothing to set up. Next time you sign in, ask for an email link.

Why we built it: Passwords are the easiest credential to steal and the most tedious to look after. Email links and single sign-on remove them entirely, and a fixed session length means no browser stays signed in indefinitely.

Send feedback from wherever you work

Choose Feedback under Help to send us a bug report, an idea or anything else, or ask your coding agent to send it for you through its SpringRoll connection. Your feedback goes straight to the SpringRoll team. Inside your workspace it stays private: your feedback list shows only what you sent, and other members, including administrators, cannot see it.

Why we built it: The best ideas for SpringRoll come from the moment something gets in your way. Being able to tell us right there, from SpringRoll or from your coding agent, means we hear about it while it still matters.

App pages that lead with what matters

Every app now opens on an overview that answers the first questions people ask: is it working, who can open it, and what happens next. Open app and Copy app link sit at the top, next to the app's status and who can open it. While an update builds, or if it fails, the overview makes clear that your current version is still running. Each app is organized into five tabs: Overview, Deployments, Access, Data and Settings.

Why we built it: Whether you built the app or are about to share it, you should not have to read deployment details to learn whether it works. Keeping the working version separate from the latest attempt means a failed update never looks like a broken app.

Sharing that respects who can open each app

Copy app link now gives you a SpringRoll link for Production or for UAT (user acceptance testing). Whoever opens it signs in if they need to, lands back on the same app, and gets the version that is live in that environment, never a fallback build or a rejected or archived release. People without access see a clear explanation instead of an error. The access editor now asks one question, who can open this app, and switching an app to Everyone keeps the exclusions you already set.

Why we built it: A hosting address skips your access rules and can change when a new version ships. A SpringRoll link checks access every time it is opened, so sharing an app is safe by default, and widening access never quietly removes a restriction.

Data, formerly Connect: faster connections and precise requests

Adding a data connection now starts with just the source, a name and the required fields, and everything else waits under Connection options. SpringRoll creates names for you, keeps saved credentials unless you choose to replace them, and can save and test a connection in one step. SAP connections can use a technical user or a BTP OAuth client. When an app needs data, its managers can search for the exact fields they need, and data owners can grant the request, reject it with a reason, or add a note.

Why we built it: Connecting an app to real company data is where it becomes useful, and also where the most careful decisions are made. Less setup gets you there sooner, while the data owner still decides which fields each app may use, and saved credentials are never shown again.

Build logs that explain what went wrong

When SpringRoll cannot fetch an app's source from Git, the deployment log now shows the error that stopped it, with web addresses and access tokens removed. Long build output stays in order, and an unusually long line is replaced with a short notice instead of being cut off mid-message. We also fixed a Git ownership check that could stop managed builds before they started.

Why we built it: A failed build with an empty log is a dead end. Showing the real reason, safely, tells you what to fix the first time instead of the third.

Navigation that responds the moment you click

Every workspace page now shares one layout. Apps, Approvals and Data come first. Members, Hosting, Approval routing and Audit trail sit under Workspace settings, and Getting started and Feedback sit under Help. Your account, Security and Agent connections are in your profile menu, and the mobile menu offers the same destinations. Every click responds immediately, with a loading view while the page arrives, and existing links keep working.

Why we built it: You should always know where you are, where to go next and whether your click registered. One consistent layout and instant feedback make SpringRoll quicker to find your way around, at a desk or on a phone.

Also improved

  • Optional sections of the New app form stay closed until you need them, open by themselves when something needs fixing, and keep what you typed.
  • App showcase is now the Public app page, an optional introduction to your app that previews exactly what will be published, and the Download card option has been removed.
  • App Settings brings the name, data classification, details and build settings together in one form.
  • Updating an app through the SpringRoll API no longer resets the settings you leave out, such as its visibility, data classification, tags and build settings.
  • Long approval inboxes are split into pages, so older requests stay easy to reach.
  • Open workspace on the SpringRoll home page takes you straight to your workspace, or asks which one you want if you belong to more than one.
  • Accepting an invitation no longer creates an extra personal workspace.
  • Hosting now shows just your deployment workflow, your public app page policy and your hosting status.
  • The setup checklist stays in Getting started instead of appearing above every page.
  • Analytics are sent after an action completes, so they never slow you down, and each app tab loads only the data it shows.
  • On a deployment record, the assumptions behind SpringRoll's hosting recommendation now display correctly.
  • The SpringRoll docs are now organized by task, from connecting your coding agent to sharing an app and requesting data, with the API and MCP reference at the end.

Read the SpringRoll docs

Workspace

Making SpringRoll better every day

The SpringRoll changelog is where we share what we improve, how each change helps you, and why we built it. We work on SpringRoll every day, and this is the record of that work.

SpringRoll is where an app built with a coding agent such as Claude Code, Codex or Cursor becomes a company app: deployed safely, reviewed when your organization asks for it, connected to approved company data, and listed in the App Portal for the people allowed to use it.

We want SpringRoll to be the easiest part of your day. So we keep improving it: we fix what gets in your way, remove steps that do not help, and make every screen answer the question you came with. Some days that is a new feature, and some days it is a clearer sentence on a page you use every morning. Both count.

Every entry here names what changed, explains how it helps the people who build, review and use apps, and says why we built it. When a change affects how your apps are deployed, reviewed or shared, we say so plainly, along with anything you need to do.

Your feedback decides what we improve next. Signed-in members can send it from Feedback in SpringRoll, or ask their coding agent to send it for them. Everyone else can reach us through the contact page.

Contact SpringRoll