Ascentra Integrations
A visual automation platform for connected workflows
A visual automation platform exploring connected workflows: graph-based execution, scheduled jobs, workers, credential handling, approvals, hooks, and execution monitoring over a Supabase backend.
- Status
- In Development
- Category
- AUTOMATION
- Year
- 2025
- Primary stack
- Next.jsTypeScriptSupabase
- Demo
- ENTER THE BUILD
Project visualization — a designed representation, not a literal screenshot
01Overview
What this is
A visual automation platform exploring connected workflows: graph-based execution, scheduled jobs, workers, credential handling, approvals, hooks, and execution monitoring over a Supabase backend.
Explores
- Visual automation builder
- Graph-based execution
- Connections
- Credential handling
- Scheduling
- Workers
- Executions with run history
- Approval gates
- Hooks
- Retry behavior
- Security controls
- Supabase backend
02Explore the build
The demo and the build insight
The demo
External application
ENTER THE BUILD
The public Ascentra build — the visual automation / Atom Builder experience, live on Vercel.
ENTER THE BUILDBuild insight
- Current build
- In Development
- Architecture and features below are the real build.
- Demo
- External
- Launch control above opens the verified public build.
Build insight — real project data, not a live application.
Workflows are stored as typed graphs. An execution engine resolves the graph, dispatches work to workers, and records every transition. Credentials are referenced from a dedicated store so secrets never embed themselves inside workflow definitions.
03Problem · opportunity
What it sets out to solve
Automation tools often force a choice between point-and-click limits and writing code from scratch. Teams want the control of code with the legibility of a visual builder — and they need to see what their automations actually did.
04Concept
The core idea
A visual automation builder where workflows are modeled as executable graphs. Each node is a step or connection, the graph is the source of truth, and execution produces a transparent, inspectable run history.
05What I built
What's actually in the code
In-progress development. The execution model, credential design, scheduling, and worker architecture are being built against Supabase. The current focus is making graph execution unambiguous before expanding surface area.
Approach
Designing the execution model around typed nodes and edges stored in Supabase. Workers execute graphs, scheduling triggers runs, credentials are stored and referenced securely, and every run is recorded with hooks, retries, and approval gates modeled explicitly.
06Key features
What's implemented today
- Graph-first workflow model: nodes and edges are the definition of an automation
- Executable node types for steps, connections, and control flow
- Worker abstraction where graph runs are executed and observed
- Schedule definitions that trigger runs
- Approval gates that pause a run until authorized
- Explicit retry policy per node rather than a blanket default
- Hook surface for reacting to run lifecycle events
07Architecture
How it's structured
Workflows are stored as typed graphs. An execution engine resolves the graph, dispatches work to workers, and records every transition. Credentials are referenced from a dedicated store so secrets never embed themselves inside workflow definitions.
Design notes
Retry behavior and approvals are modeled as first-class graph concerns. The design favors explicit, inspectable policies over hidden defaults so a failed run is always diagnosable.
08Technology
The stack
- Next.js
- TypeScript
- Supabase
- PostgreSQL
- Node.js
- Tailwind CSS
09Challenges · lessons
Where it got hard, and what it taught me
Challenges
- Defining graph semantics that are powerful but still predictable for non-experts
- Securing credentials without scattering them through workflow payloads
- Making execution state replayable enough to debug after the fact
Learnings
- Execution visibility is the product: teams trust automation when they can trace exactly what ran and why
- Graph semantics need rigorous definition before the visual builder is worth building
- Approvals and retries shape trust more than raw feature count
10Current status
Where this project sits today
Architecture is established and modules are actively being built. Parts exist; the whole is not finished.
Demonstrated
- Execution model, worker, scheduling, and credential architecture under development against Supabase
11What comes next
Where this goes from here
- 01Complete graph execution end to end across worker processes
- 02Build the visual builder surface over the execution model
- 03Exercise the hook and approval paths with integration tests