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

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