Extending Backstage with Flows

What Is Backstage?

Backstage is an open source framework for building developer portals. It features:

• A Software Catalog that keeps track of metadata and ownership of the software (services, websites, libraries, etc.) in a system.
• Software Templates that define actions the developers can trigger from the UI.
• TechDocs, a docs-like-code approach that keeps documentation next to the code and renders a doc site on Backstage.
• A Plugin Architecture with an ecosystem of open source plugins to customize Backstage’s functionality.

In this guide we’ll focus on how Flows can extend Backstage’s Software Templates as a self-service tool for developers.

The Gap Between Portal and Engine

Software Templates — also known as the Scaffolder — are designed to perform self-service actions, with a primary focus on Day-0 creation: scaffolding a new service, registering a catalog entity, sending a notification, etc. To go beyond these basics and implement workflows that capture the organization’s processes, teams extend the Scaffolder with community plugins or custom actions.

However, extending the Scaffolder has an operational cost. The development loop for custom actions adds friction — they are built and tested against a local Backstage instance, published to npm, and imported into the real project, in hopes that production behavior matches. Community plugins carry their own risk, as quality varies and ongoing maintenance isn’t guaranteed. Either way, every new extension requires rebuilding and redeploying the entire application and, as Backstage evolves, version conflicts across all of them become a recurring pain point.

Even with extensions, the Scaffolder’s design limits what Day-2 workflows can look like. Templates are a sequential list of steps, without any conditional branching, parallel execution, or way to incorporate external input once the workflow starts. The Scaffolder can’t pause and wait for a Slack approval, then route based on the response. And its task log, while useful for debugging, can’t answer compliance questions like who requested or approved access to a resource on a given date.

Flows as a Backstage Execution Backend

The Backstage App on Flows (shipped as part of its Core Registry) is the simplest way to leverage Flows’ capabilities to fill these gaps. The integration is very simple: installing the app requires a one-time update in Backstage’s configuration; then, each Flow with a Backstage Entrypoint block will be registered automatically in Backstage as a Software Template. The entrypoint block fully defines the template’s interface on Backstage (its form fields, metadata, and descriptions) and, on submission, propagates the request to subsequent blocks that carry out the workflow.

From there, workflows can branch based on runtime data using Condition blocks, run actions in parallel (with Explode and Collect for dynamic fan-out over lists), pause for human input — for example, through Slack interactive messages — and introduce timed delays with Sleep. These composable building blocks can model workflows that would otherwise require custom TypeScript actions in the Backstage backend. If a step fails mid-execution, you can replay from the failed block without re-running the entire workflow or re-requesting approvals that already happened. New integrations with services like AWS, Slack, or PagerDuty are available as pre-built apps in the App Catalog, and the Apps SDK lets you build custom ones for internal APIs not covered by the catalog.

See it in action

The self-service provisioning template combines some of these blocks into a complete workflow with Slack approval.

Every Flow execution produces a structured log of what was received, what each block produced, and what was sent, making the workflow observable. Flows also provides organization-level audit logs that track who did what and when. And, because a Flow’s visual representation on the canvas is the thing that actually runs, it doubles as documentation. This is particularly useful for processes that need to be understood beyond the team that built them, like incident runbooks or access request procedures.

Backstage remains the portal — the place where developers discover services, find documentation, and trigger workflows. What Flows does is reduce the complexity of implementing workflows while adding a layer of observability, recoverability, and confidence.

Step-by-Step: Self-Service Database Provisioning with Approval

In this guide, we’ll build a self-service workflow that lets developers deploy Spacelift Templates from Backstage with a Slack approval step. The request is submitted through a form on Backstage, approved on Slack, and deployed by Spacelift. The developer receives a DM with the deployment details once it completes.

We’ll use a database provisioning template as the concrete example, but the same pattern works for any template — or, more broadly, for any operation that benefits from approval workflows and audit trails, such as infrastructure provisioning, developer onboarding, or incident response.

Prerequisites

• A running Backstage instance.
• A Flows project and a Slack workspace you can install apps to.
• A Spacelift account with a template configured for Aurora database provisioning.

Install the Apps

Install the Backstage, Slack, and Spacelift apps from the App Catalog in your Flows project. See the app installation guide for general instructions — each app displays precise setup instructions after installation.

• The Slack app walks you through creating a bot with the required permissions using a pre-configured manifest.
• The Spacelift app connects to your Spacelift account and enables template deployments from within Flows.
• The Backstage app requires adding a proxy endpoint and a new catalog location in the Backstage configuration. Once connected, templates defined by Backstage Entrypoint blocks appear on Backstage’s Create page automatically — no further Backstage changes or redeployments are needed.

Build the Flow

The following Flow automates the provisioning workflow, adding a Slack approval layer. On approval, Spacelift deploys the database using a pre-configured template, and the developer receives a DM with the deployment details once it completes.

Copy this flow definition into your project, attach the Slack, Backstage, and Spacelift blocks to your app installations, and confirm the Backstage Entrypoint block:

Trigger

BackstageBackstage Entrypoint

Software Template Entrypoint

SlackLookup User by Email

Lookup User by Email

SlackSend Message With Interactions

Request Approval

Business logic (built-in)Condition

Approved

SlackSend Text Message

DM Deployment Finished

SlackSend Text Message

DM Rejected

SpaceliftDeploy Template

Provision Aurora Database

SlackUpdate Message Blocks

Prevent Extra Interactions

SlackSend Text Message

DM Approval Confirmed

Copy

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

To customize this flow for your setup, define the following secrets in your Flows project:

Secret	Value
SLACK_CHANNEL_ID	Slack channel where approval requests are posted
SPACELIFT_SPACE	Spacelift space for the deployment
SPACELIFT_AURORA_TEMPLATE_ID	Template version ID for the Aurora database template

Test the Integration

1. Open your Backstage instance and go to the Create page.
2. Select Self-Service Aurora DB request.
3. Fill in your email (which must exist on your Slack workspace), a project identifier, choose an engine and instance class, and enter a database name.
4. Click Create — Backstage will submit the form to Flows and display the success message.
5. In the configured Slack channel, the approval request will appear with Approve and Reject buttons showing the request details.
6. Click Approve. The approval message will be updated to reflect the decision, you’ll receive a DM confirming the approval, and Spacelift will start deploying the database.
7. Once the deployment completes, you’ll receive a second DM with the connection details (endpoints, credentials secret, etc.).

Inspect the blocks’ events on the canvas to see who triggered the request, who approved it, what the Spacelift deployment produced, and when each step completed.